Display colours randomly get too bright, overblown and oversaturated on my AMD Framework

Hi there! This issue has been annoying the hell out of me on my AMD 13" running Fedora Silverblue. I can’t figure out why this started happening, either.

Randomly, the colours will get overly bright, completely overblown and the saturation will get all over the place. I deactivated the automatic brightness setting in GNOME, I already tried cleaning dust from the bezel and so on, but nothing fixed it.

Luckily, this issue has already been mentioned and already has a fix, but it’s for Intel… and on Windows.

I’m sure there has to be some driver messing up somewhere, or whatever. It’s a toggle switch on Intel / Windows, so the fix can’t be too hard on Linux. Probably a command-line away problem but for the life of me, I can’t find a solution to this. :frowning:

This happens due to adaptive backlight management in power-profiles-daemon (The software that handles power profiles).
ABM can save a bit of power in exchange for color accuracy.

If you want to disable it, read this section

Thanks for the help! I’m sorry for asking a lot but, I can’t seem to figure out how to do this. What is the exact command I’m supposed to type?

I’ve read through the documentation and I get the feeling that it assumes that I know a lot more than I actually do.

"Laptops with integrated Radeon graphics have a dedicated hardware function to decrease panel power consumption in exchange for color accuracy. This function is used when the system is on battery and the user has selected the “balanced” or “power-saver” profiles.

If you decide that you don’t like how this behaves, you can disable the function in one of two ways:

  1. Adding amdgpu.abmlevel=0 to the kernel command line. This will disable abm value changes entirely.
  2. By using --block-action=amdgpu_panel_power in the power-profiles-daemon ExecStart command. This will allow you to still change values manually in sysfs but power-profiles-daemon will not change anything."

Both ‘ways’ are things I don’t know how to do, reading some of the previous stuff in the documentation as well as further didn’t really help.

…and that’s why I love GUIs. >.<

EDIT:

I’ve entered sudo systemctl edit power-profiles-daemon.service in my terminal. And added ExecStart=/usr/lib/power-profiles-daemon --block-action=amdgpu_panel_power to the file, based on reading what I found here.

Hopefully, I fixed it. And hopefully, I didn’t mess anything up.

What you did in the edit is what I would have recommended and is completely correct.
This should now have disabled power-profiles-daemon from changing the adaptive backlight management.

Though, also add what is done here, in order to not have it overridden the next time the package is updated.
https://bbs.archlinux.org/viewtopic.php?pid=2181988#p2181988

Thank you for posting this! This started happening to me recently on Fedora 39 Workstation and I couldn’t figure out why.

I messed it up. Not only did I not fix the issue but now I can’t even undo what I did.

I don’t know how tu use “systemctl”, I do everything I can to avoid using the Terminal in my day to day so all of this is alien to me.

  • So, I did sudo systemctl edit power-profiles-daemon.service in the terminal.
  • I added this piece of text where indicated:

[Service]
ExecStart=
ExecStart=/usr/lib/power-profiles-daemon --block-action=amdgpu_panel_power

  • Tried to do systemctl restart power-profiles-daemon.service but now it spits out:

Job for power-profiles-daemon.service failed because the control process exited with error code.
See “systemctl status power-profiles-daemon.service” and “journalctl -xeu power-profiles-daemon.service” for details.

  • So I do systemctl status power-profiles-daemon.service and I get:

× power-profiles-daemon.service - Power Profiles daemon
Loaded: loaded (/usr/lib/systemd/system/power-profiles-daemon.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
/etc/systemd/system/power-profiles-daemon.service.d
└─override.conf
Active: failed (Result: exit-code) since Sun 2024-07-14 18:12:00 CEST; 57s ago
Process: 6897 ExecStart=/usr/lib/power-profiles-daemon --block-action=amdgpu_panel_power (code=exited, status=203/EXEC)
Main PID: 6897 (code=exited, status=203/EXEC)
CPU: 23ms

juil. 14 18:12:00 framework-laptop systemd[1]: power-profiles-daemon.service: Scheduled restart job, restart counter is at 5.
juil. 14 18:12:00 framework-laptop systemd[1]: power-profiles-daemon.service: Start request repeated too quickly.
juil. 14 18:12:00 framework-laptop systemd[1]: power-profiles-daemon.service: Failed with result ‘exit-code’.
juil. 14 18:12:00 framework-laptop systemd[1]: Failed to start power-profiles-daemon.service - Power Profiles daemon.

And I’m supposed to understand any of this… because? I’m not ranting against you, by the way, it’s just that… it’s a simple toggle on Windows! Why does everything on Linux has to be so complicated… >.<

I would revert the changes you did and just add the kernel parameter, to completely disable abm control.
To revert the changes, just change the lines to

[Service]
ExecStart=/usr/libexec/power-profiles-daemon

again like it was before anything was done.

Disregard what I said, see post below this. That fixes the issue, I didn’t see, that you changed it to /usr/lib/. You can still completey disable abm using the instructions I posted below, but changing the service is easier and more recomended.

To set the kernel parameter in Fedora, you need to run the following command.
sudo rpm-ostree kargs --append=amdgpu.abmlevel=0
After that, restart your computer and it should all be applied and working normally.
This completely disables the feature and also disallows other apps from applying any changes to the abm level.

I agree, that for the average user some parts are still a bit more complicated than other operating systems. But once you get more used to the command line, it is a lot faster and simpler than fiddling around with any GUI application.
Only thing I can recommend, is to not get discouraged and make backups when tweaking stuff. Despite popular consensus, it is actually quite difficult to completely break Linux by just tweaking things or trying something out.

I had the same issue. The reason is the linked instructions are for Arch and Fedora uses /usr/libexec/power-profiles-daemon. You can discover this by reading the comments in the override.conf.

The override.conf should look like this:

### Editing /etc/systemd/system/power-profiles-daemon.service.d/override.conf
### Anything between here and the comment below will become the contents of th>

[Service]
ExecStart=
ExecStart=/usr/libexec/power-profiles-daemon --block-action=amdgpu_panel_power

### Edits below this comment will be discarded [...]

This behaviour is way too complicated for an average user to discover, let alone change. It’s also confusing that this behaviour is distinct from the ambient light sensor settings in the Gnome power saving settings widget.

2 Likes

Fedora 41 will replace power-profiles-daemon with Tuned, so hopefully that has better handling of this.

1 Like

The right solution is that the compositors offer a knob to turn it on and off. We have a kernel change in 6.11 that allows compositors to do this when color accuracy is required.

But please keep in mind that power savings is pretty dramatic from having this on.

2 Likes

On further testing since making this change, the behaviour is still happening to me. The screen will get suddenly brighter then suddenly darker. Not sure how to reproduce this as it doesn’t seem to happen based on my input.

~ → sudo systemctl show power-profiles-daemon.service | grep ExecStart
ExecStart={ path=/usr/libexec/power-profiles-daemon ; argv[]=/usr/libexec/power-profiles-daemon --block-action=amdgpu_panel_power ; ignore_errors=no ; start_time=[Sun 2024-07-14 09:41:38 PDT] ; stop_time=[n/a] ; pid=12255 ; code=(null) ; status=0/0 }
ExecStartEx={ path=/usr/libexec/power-profiles-daemon ; argv[]=/usr/libexec/power-profiles-daemon --block-action=amdgpu_panel_power ; flags= ; start_time=[Sun 2024-07-14 09:41:38 PDT] ; stop_time=[n/a] ; pid=12255 ; code=(null) ; status=0/0 }