It works like a charm.
I did forget to add the execute permission to both scripts though 
, but now it works and I’m amazed.
Thank you very much for this !
EDIT: I wasn’t familiar with the GUI above, but I never ran KDE on a laptop before. This can be found in Settings > Energy Saving. Don’t forget to set a run condition for each profile/tab.
Why not use adaptive sync directly?
I have adaptive sync set to auto, but I don’t want to pay the 1W cost while I’m on battery for 165hz, so that’s why I disable it.
Got it; thanks for clarifying.
Unfortunately, I know of no way to see what adapive sync is doing. Does it go lower than 60hz when not doing anything? Does it ramp all the way up to 165hz and waste more power when moving the mouse?
This is a sure way to reduce a little power usage.
KDE Plasma/Kwin doesn’t dynamically drop to 60Hz yet, it’s only for applications that support it
It actually seems to do so since KDE Plasma 5.22 according to Nate’s blog.
Check This week in KDE: Support for GPU hot-plug and FreeSync, and so much more – Adventures in Linux and KDE
With adaptive sync on I can tell you that the desktop environment (i.e. while not in a game) is definitely being kept at 165hz, which imo is the desirable behavior. I would only want the refresh rate being changed for fullscreen content with a dynamic frame rate.
Plasma/Kwin always renders at ( with my FW16 ) 165Hz, that’s with Adaptive Sync set to automatic or always. Plasma/Kwin is not is not dynamically adjusting it’s own frame rate yet. it’s static, based on panel’s configured refresh rate. I read somewhere it’s on their plan/todo list
I would prefer Plasma/Kwin to drop to 60Hz when very little or nothing is changing on the screen, bigger power savings. Using 60Hz compared to 165hz drops discharge rate by 1W~
It’s when an application that goes full screen ( game from steam for example ), that’s when the panel refresh rate dynamically changes.
I’m using KDE Plasma 6.0.5
If the desktop environment itself could adjust framerate, that would be amazing. I spend a lot of time staring at a text editor with 0 pixels changing (other than the clock). Having the display automatically drop to a low refresh rate when this happens, e.g. 1-10hz (idk if it’s supported by the panel) would be awesome. I would guess it’s even more battery efficient than what I’m doing now.
Android does it ( Pixel 7 Pro ), I believe Microsoft Windows too and it’s something I’m looking forward too with KDE.
The panel with FW16 can dynamically go between 60-165Hz
edid-decode (hex):
00 ff ff ff ff ff ff 00 09 e5 c9 0b 00 00 00 00
30 20 01 04 a5 22 16 78 03 3d 35 ae 50 43 b1 25
0e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 34 70 00 a0 a0 40 a0 60 30 20
f6 0c 59 d7 10 00 00 1a 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 fe 00 42
4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
00 4e 45 31 36 30 51 44 4d 2d 4e 5a 36 0a 01 0a70 20 79 02 00 22 00 14 7f 0d 0c 85 ff 09 9f 00
2f 00 1f 00 3f 06 9f 00 3e 00 05 00 25 00 09 7f
0d 0c 7f 0d 0c 3c a5 80 81 00 13 72 1a 00 00 03
c1 3c a5 00 00 6a 42 6a 42 a5 00 2f aa 0c 21 01
1d 77 0d 6a 08 00 0a 40 06 88 e1 aa 50 3d 24 b1
51 d2 0e 02 35 54 b0 5c b0 5c cc 34 12 78 26 00
09 02 00 00 00 00 00 10 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 f7 90
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: BOE
Model: 3017
Made in: week 48 of 2022
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 8
DisplayPort interface
Maximum image size: 34 cm x 22 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
First detailed timing includes the native pixel format and preferred refresh rate
Display supports continuous frequencies
Color Characteristics:
Red : 0.6796, 0.3154
Green: 0.2646, 0.6923
Blue : 0.1445, 0.0576
White: 0.3134, 0.3291
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 2560x1600 60.001671 Hz 16:10 105.603 kHz 287.240000 MHz (345 mm x 215 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 63 Vsync 6 Vback 91 Vpol N
Empty Descriptor
Alphanumeric Data String: ‘BOE CQ’
Alphanumeric Data String: ‘NE160QDM-NZ6’
Extension blocks: 1
Checksum: 0x0a
Block 1, DisplayID Extension Block:
Version: 2.0
Extension Count: 0
Display Product Primary Use Case: None of the listed primary use cases; generic display
Video Timing Modes Type 7 - Detailed Timings Data Block:
DTD: 2560x1600 165.000000 Hz 16:10 290.400 kHz 789.888000 MHz (aspect 16:10, no 3D stereo, preferred)
Hfront 48 Hsync 32 Hback 80 Hpol N
Vfront 63 Vsync 6 Vback 91 Vpol N
Dynamic Video Timing Range Limits Data Block:
Minimum Pixel Clock: 789888 kHz
Maximum Pixel Clock: 789888 kHz
Minimum Vertical Refresh Rate: 60 Hz
Maximum Vertical Refresh Rate: 165 Hz
Seamless Dynamic Video Timing Support: Yes
CTA-861 DisplayID Data Block:
Vendor-Specific Data Block (AMD), OUI 00-00-1A:
Version: 3.193
Minimum Refresh Rate: 60 Hz
Maximum Refresh Rate: 165 Hz
Flags 1.x: 0x00
Flags 2.x: 0x00
Maximum luminance: 106 (496.743 cd/m^2)
Minimum luminance: 66 (0.333 cd/m^2)
Unknown: 0x6a 0x42
Display Parameters Data Block (0x21):
Image size: 344.7 mm x 215.4 mm
Display native pixel format: 2560x1600
Scan Orientation: Left to Right, Top to Bottom
Luminance Information: Guidance for the Source device
Color Information: CIE 1931
Audio Speaker Information: not integrated
Native Color Chromaticity:
Primary #1: (0.679932, 0.314941)
Primary #2: (0.264893, 0.691895)
Primary #3: (0.144775, 0.057861)
White Point: (0.312988, 0.328857)
Native Maximum Luminance (Full Coverage): 300.000000 cd/m^2
Native Maximum Luminance (10% Rectangular Coverage): 300.000000 cd/m^2
Native Minimum Luminance: 0.299805 cd/m^2
Native Color Depth: 10 bpc
Display Device Technology: Active Matrix LCD
Display Device Theme Preference: No Preference
Native Gamma EOTF: 2.20
Display Interface Features Data Block:
Supported bpc for RGB encoding: 8
Supported color space and EOTF standard combination 1: DCI-P3
Checksum: 0xf7
Checksum: 0x90
Darn, it’s less exciting if it doesn’t go below 60. Still an improvement though.
Panel self refresh (assuming it’s working) should help there, under 60fps cursors start looking really sluggish so not sure going lower with stuff actually going on is worth it.
Agreed, I don’t want sub-60 for cursor movement. I’ve seen cursors at 30hz and I do not like it. My sub-60 interest is mostly for when the display is showing relatively static content (and no cursor movement), similar to the use case for PSR like you mention.
Working psr should pretty much entirely handle that, no load on the gpu/display interface while nothing is going on. I don’t know how much power if any the display would save by running itself at sub 60 fps but the bulk of the savings is likely in the gpu and interface.
How well it works is a bit hard to tell though.
I actually wasn’t familiar with PSR before you brought it up. Anecdotally and assuming the FW16 supports it, it would explain some behavior I’ve seen while running battery tests. If I had to guess, I’d say it’s working as intended. I’ll have to look into it more to see if/how it may impact my understanding of the FW 16’s power draw.
There is a lot of arcane magic going on when nothing is going on on the laptop.
Turns out moving the cursor takes like 3W, but that may have been fixed, or at least there is a kernel patch for it.
Hopefully AMD can fix the “Panel Replay” feature they temporarily disabled in Linux 6.9 as it was causing some issues with some people, this will get rid of the cursor hitch when PSR is being used
That sounds like you can still manually enable it, may be worth a test.
Yeah, kernel patch required for it ( it’s how I’m interpreting that )
some users are also reporting PSR issues too ( I’m one of them )