If anyone running KDE Plasma is interested in having their Framework 16 automatically switch between 60hz and 165hz when they’re on off battery, you can use the following commands to do so. Tracking these commands down was kind of difficult, so I figured I would share. Technically the numbers in the command are supposed to change depending on the device’s configuration, however I’m guessing they’re the same for each FW 16 (without external monitor plugged in).
Switch to 60hz: kscreen-doctor output.1.mode.1
Switch to 165hz: kscreen-doctor output.1.mode.0
I have put these commands in simple scripts that Plasma can call automatically on plugin/unplug from AC.
Example for switching to 60hz on battery
#!/bin/sh
kscreen-doctor output.1.mode.1
8 Likes
This is a cool idea. Thanks for sharing.
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.
1 Like
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.
1 Like
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
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 0a
70 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.
1 Like
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
