That’s exactly what i did… !?
Your theory is approved! Changing resolution after setting the panel_power_savings value did the trick.
Would you mind informing the developers?
Thank you very much spending your time on this!
That’s exactly what i did… !?
Your theory is approved! Changing resolution after setting the panel_power_savings value did the trick.
Would you mind informing the developers?
Thank you very much spending your time on this!
There is an option somewhere in Thunderbird to send as plain text or html. I guess the default must be html.
Ah great! If I don’t see your reply on Monday I’ll mention this. Thanks for testing it.
Sure! I’m also planning to wire it up to PPD, so these testing results are really helpful to catch the problem now.
after setting amdgpu.abmlevel=4
I cannot manually change display brightness with the function keys.
Is this expected?
I can not confirm this. It`s working here…
Not expected at all.
There isn’t a v2 posted yet but the solution is basically going to be for the driver to do an internal modeset when the sysfs file is written to.
It won’t do a lot of good until v2 is posted; but I’ve also wired up a MR for PPD to toggle ABM dynamically:
Basically if on battery it will set:
If on AC it will set ABM 0.
Thank you! Gave it another try and now the brightness keys are working.
Here’s v2 which does the modeset I mentioned.
[PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors (kernel.org)
Works like a charm .
Thank you!
I applied your patch and it works to change the ABM level.
But sometimes I get flickering after I change the value.
When changing the value again it disappears.
Kernel 6.7? If so I’ve got another patch for you
Yes, Kernel 6.7.4
This patch is also applied
https://patchwork.kernel.org/project/chrome-platform/list/?series=804326
Which comes from Flickering coloured glitchyness on 780M Phoenix iGPU with 6.7.0 kernel on Xorg/plasma (#3097) · Issues · drm / amd · GitLab
If it works please respond there to let author know.
Thanks, it fixed my issue
Hello @Mario_Limonciello ,
i’ve tested the current main-branch of power-profile-daemon with the build in ABM-patches on 6.8rc4 and 6.7.4. All is working as intended. Thank you very much for this!
Unfortunately the default ABM value of 3 in balanced mode is not that appropriate at least on daylight use. With a matte display on my framework 13 you have to rise screen brightness up to about 30-50% to see all content on the display, while on abm level of 1 15% of screen brightness is sufficent. On a glare display the situation is presumably worse.
Summing up an abm level of 3 with screen brightness set to around 40% needs up to 10% more power than an abm level of 1 with a screen brightness of 15% . Maybe it would be better, to set an abm level of 1 on balanced profile and an abm level of 3 on power-saver profile as you mentioned in the post above.
How are you measuring power?
I discussed with Windows team and they use 3 by default in battery for a very long time which is how I came up with the numbers used.
I used the following procedure:
I did this three times (on balanced profile) with abmlevel of 3 / 36% screen brightness and then three times (on balanced profile) with an abmlevel 1 / 12% screen brightness. With this settings the presentation is clearly visible/readable on daylight with no sun. With the first setting the time until battery drops 1% is 8,9% shorter on average than with the second setting what leads me to the conclusion that the second setting is more efficient at least in this special test scenario. Beside that: the colors look really awful on abm level 3. Is this really intended as default on battery, as balanced profile is normally the default?
Personally, it’s not that important to me because I’ve created a shortcut to switch the abm leves like I need them.
Really appreciate the feedback and detail on your testing procedure. After conversation with others and looking more closely I completely agree with you.
I’ve made the change to PPD to not be so aggressive.
amdgpu: reduce panel_power_saving values (!155) · Merge requests · upower / power-profiles-daemon · GitLab
Great stuff! Am I correct in assuming we still have to wait for a kernel with this patch included before it actually takes effect?
…that’s right, except you build your own kernel with this patch applied.