The panel itself needs to support Freesync to start.
Fwiw the Framework 16 panel supports panel replay. There were some problems with it though so it’s disabled by default in 6.10. If they’re fixed in time perhaps it can be re-enabled in 6.11.
IPS2 isn’t available on the current gen platforms
It requires an updated display controller hardware.
You’ll first see it on future ones. I’m just mentioning it because it’s a pretty big power savings to turn it on.
You’re probably mixing up the cpufreq governor and PPD power saver state as you’re talking in this paragraph.
EPP can only be tuned when the cpufreq governor allows it which for historical reasons has that name.
If you’re seeing pretty big power consumption in balanced on battery such that you would rather operate in power saver I would wonder if you’ve got some inefficient userspace or some long running background tasks.
Without scheduler changes you would probably be better manually setting the affinities of such tasks and maybe even controlling the performance bounds of a CPU core they’re on. But this is getting into a pretty custom territory and you’ll need to profile your workloads to find out if it really makes sense.
No idea. To answer that I’d have to have some power monitor that will monitor every hardware component and every process during the whole charge. Sadly neither does Gnome bringt such a tool nor do I know of something fitting.
As I suspected the higher power savings are at higher brightness showing dimmer content.
That’s kind of my problem here, will a member of the majority be able to find out why the screen looks like that having never heard about abm or just blame the hardware or software as a whole?
Now panel replay sounds very nice.
IPS2 is not very google-able, not sure what exactly you mean by that.
That’s definitely true, I love that there is the option, my objection is entirely having it enabled by default since the connection between the deepfried image and that particular setting is non obvious if you don’t know abm is a thing.
That is a good justification to manually enable it.
I’ve done a little test of my own. It seems the issue isn’t ABM itself, but the fact that it must be set to 3 by default, which totally nukes the displaying quality. Manually setting it to 1 and having grub update (sysctl -a for some reason doesn’t output any string with amdgpu.abmlevel or abmlevel for that matter, but dmesg shows that amdgpu.abmlevel=1 is in the Kernel command line) doesn’t really show any visible differences as far as I can tell. So given that ABM is actually set to 1, I’d change my mind that it can stay active by default, it merely shouldn’t default to the most aggressive mode. Possibly saving 0.5 W without any drawbacks is actually more of a deal than merely saving 0.5 W by deepfrying the content.
This comes back to my comment that people should be using balanced. ABM is zero on AC and 1 on DC while in balanced.
Based on the way you use power states maybe it would be better to add a “battery level” factor into the decision. Only enable ABM starting at 50% battery level, and increase the intensity as the battery level drops. For example ABM 1 at 50%, ABM 2 at 40%, ABM 3 at 30%.
I think this could be a cool feature, but if added I think it would need to be configurable so that it can still be always-on/off.
Well the policy of allowed/disallowed at runtime will remain in compositor. So you’ll need to work with compositor devs to add such a knob.
If it’s user definable, sure.
Here, you guys can try this and see what you think.
I use a 24-Inch-Monitor (Eizo) with my Desktop-PC which also has this ABM-Feature. This Monitor also has an Ambientlight-Sensor. In this case the whole ABM-Thing is independent from any Performance-Profiles and Workloads. That’s how it should be. I try to explain.
The optimal Brightness of the Backlight always has to do with Ambientlight, Luminance of the displayed Information and the Human-Eye. Has not much to do with CPU-Power.
When bound to a Performance-Profile and implemented like it is now (i am using Kubuntu) you say only heavy Workloads need precise Color-Presentation and bright Display. Also a User who is using Performance-Profile is “forced” to waste Energy.
Let’s say i want to play a darkthemed Game. I choose the Performance-Profile. Does that mean i need precise Colors and a bright Backlight? In this Usecase i would benefit most from ABM, because ABM not only can save Energy it also can lead to a better Black-Presentation (everybody knows TFTs have Problems with Black because of the Backlight). I know this from my Desktop-Monitor. In my Monitor this Feature is bound to a Monitor-Profile (Movie/Gaming) and can be switched off by selecting onother Profile (sRGB). Also the Monitor can show the saving in Watts.
But i also know the side-effects, like in Movies when the Credits roll and they used white small Script on Black. Because of the high amount of Black my Monitor dimms the Backlight → White becomes Grey (and sometimes suddenly becomes White).
Next thing is, ABM only can be good when Ambient is taken into account. On Kubuntu my Ambientlight-Sensors does not work, so this can make things worse when ABM is on by default. As others mentioned, this Feature should be implemented in a way that the User is informed that it there (i only know because i found this Thread, was wondering why my Display changed Brightness when plugging in Power-Cable because i disabled Brightness-Switching in the Energy-Settings) and it should be configurable (ABM-Level).
Greetings from Germany
You must be referring to a different but similar technology. ABM on AMD systems only works on eDP.
Hi Mario,
You are right, Eizo don’t call it ABM but it has the same goal → saving Energy and some Eyecare.
Excerpt from Handbook (which a Framework does not have):
“EcoView Optimizer: The EcoView Optimizer determines and takes into account the white portion of the image content when controlling the background lighting. For dark images, the light emission is reduced so that power consumption can be reduced by up to 30%. The image brightness determined by the user is retained, however, because EcoView Optimizer adjusts the color tone values accordingly.”
And it has the same side effects → washed out Colors when using Desktop-Apps, sometimes abrupt changes in Brightness.
With my previous Post i wanted to explain how bad it is implemented on my Framework+Kubuntu-Computer.
On my Desktop+Eizo-Monitor this ABM-Thing isn’t a “hidden” Feature like on Kubuntu and it is under User-Control. And with a Screenmanager-Software you can bind it to Apps. It’s a better and more user-friendly Implementation.
I don’t disagree that this option should be exposed in the compositor UI. This is something KDE is working on.
You don’t happen to know if there’s work/a feature request already for Mutter? Otherwise I’ll be opening one up.
I’m not aware of such a feature request.
Then there is now