I have no clue if this is a framework firmware issue or a linux issue or something in-between. But I am having really weird color behavior right now and I was wondering if anyone can reproduce this.
Basically: as soon as the device is running on battery, its color reproduction goes nuts. The device loses some brightness, and I can understand this, but it also loses most color contrast.
Especially dark colors will become really bright, rendering white text on colorful background difficult to read. Sometimes this even makes my own speech bubbles in telegram illegible. When it is really bad, all the colors seem blown-out as if I was taking an over-exposed picture.
But as soon as I plug in a power brick, the dark colors are actually dark again and everything looks fine. Also the display becomes a bit brighter.
I do a lot of color critical work and stuff like this is a bit scary to me … so help would be highly appreciated.
I am also experiencing this but mainly trying to get my power usage down at the moment
I’m on Kubuntu/KDE, kernel 6.9.3
I believe I’ve managed to fix it following this from Mario. The issue is automatic contrast and brightness adjustment, the settings for which dont appear to show up in the KDE settings (though IIRC do show up in the base Ubuntu / gnome settings menu)
In essence, I added amdgpu.abmlevel=0 to my command line parameters to disable it
I double checked the Linux Kernel documentation, and it’s documented as disabled by default. I recall @Mario_Limonciello may have mentioned that this may be changing to enabled in a kernel version (6.8/6.9?). Is this documentation out of date then?
abmlevel (uint)
Override the default ABM (Adaptive Backlight Management) level used for DC enabled hardware. Requires DMCU to be supported and loaded. Valid levels are 0-4. A value of 0 indicates that ABM should be disabled by default. Values 1-4 control the maximum allowable brightness reduction via the ABM algorithm, with 1 being the least reduction and 4 being the most reduction.
Defaults to -1, or disabled. Userspace can only override this level after boot if it’s set to auto.
This doc also appears to indicate that both 0 and -1 represent disabled.
Ah, so -1 is what enables ppd to control it from userspace. PPD can then be configured to ignore it (the now non-default behavior as of I believe version 0.2), hence the systemctl unit configuration option. Alternatively, it abm can be disabled entirely at the kernel level with 0 and it’s no longer a feature for ppd or other userspace applications to even mess with.
Assuming what I said correctly interprets what you said, I have a much better understanding now. Thanks!
I added amdgpu.abmlevel=0 to my grub commandline but the screen still changes color when switching between energy saving and performance mode while running on battery.
Kernel 6.9.1-060901-generic
Exactly what I meant with it looks like the Gamma curve is off in this mode. And I even have set a color profile in Gnome Settings, so all necessary information for accurate color information should be present, but it all just goes nuts. So yeah, as long as this isn’t being done properly, better turn that mode off, it harms more than it helps.
I hope all upstreams opt out by default and bury this somewhere in the Energy Saving “Last Resort” settings with a warning about how it might alter contents - the entirely off color made me think the panel was broken at first.
I am not sure the slight power savings are worth the “amd just makes my screen look like crap on linux I guess” sentiment that’ll create with users that can’t track it down to this setting.
It may be low impact for some eyes/displays but just enabling it by default without any warning may be a bit much.
I don’t think that’s generally a good justification to do something XD.
Not sure if it’s actually active on my windows install but I definitely didn’t notice it looking the way it looks on linux.
Anyway, that’s just my opinion, I know what it is and how to disable it, however I am not sure I’d figure it out if I didn’t stumble over it here and would probably just think the framework display sucks.
Right; we’re not using the exact same policy in Linux as Windows does. Windows is a lot more aggressive with when it’s enabled.
I have seen review complaints about it (for example the verge had an article complaining about it on Windows). It’s definitely a polarizing setting that some people really hate and others don’t mind.
Right; the eventual goal is the compositor and DE will also have the ability to turn it on and off with a button. It will decide policy as part of it’s modest by indicating if it wants color accuracy or power savings.
Maybe it’s worth @Matt_Hartley putting together an article about it explaining it for now.