Screen contrast changes on battery with power save mode

recently (maybe after plasma6) when I remove power from laptop (on battery) and my power profile is set as “power save” my screen change its contrast (if that is the right word). it is like my screen gets covered with a transparent grey cover.

when I set my power profile to performance it goes back to normal. and when I set it to middle (balanced) it seems to gets that grey cover but only slightly.

connecting power source to laptop makes the screen normal at all the power profile modes.

Same thing happens to me. It looks like there is a contrast & brightness decrease and also there is a kind of blue tint. I am on Fedora 40 with KDE and it started to happen several days ago after the update.

I am on a laptop with ryzen 5500u and integrated AMD gpu if it matters

Does this also happen if you manually drag the Display Brightness slider in the “Brightness and Color” applet? Also what are your exact Plasma versions right now?

weird.
mine is CPU: AMD Ryzen 7 5700U with integrated AMD gpu.

I think mine got fixed in new kde version.
but for others to know :
1: no changing brittleness did not have the same effeect. (the brightness was the same value)

2: DE: KDE Plasma 6.1.0

I think it is fixed.

For me issue still persists. It happens both if keys or slider in the applet are used. And slider in the applet behaves somewhat strangely jumping down or up from the selected value.

Here is a small summary of the system:
Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5500U with Radeon Graphics
Memory: 14.9 GiB of RAM
Graphics Processor: AMD Radeon Graphics

I should probably add, that blue tint was apparent with “Night mode” enabled with temperature set to 3000K. With “Night mode” disabled it is just slight contrast/brightness reduction, however it still feels a little bit unsettling :slight_smile:

And another thing is that on maximum brightness it does not matter if it is in performance or power save mode, it displays equally ok picture. However problem becomes visible on lower values, I would say that at 60% it becomes very noticeable.

I think I found out why we differ.

the issue is still there but happens with newer kernel.
I was on tls kernel when I said it didnt happen.

the bug happens on linux 6.9.6.arch1-1

doesnt happen on linux-lts 6.6.35-2

I think it still happens on 100% britghness but you dont see it.
when I put at 100% I think I (may) still see the bug, but because of the light the difference is not obvoius.

but when I switch the power profile mode to perfomance from power save I see a flicker on screen.

this may be because we have difference screens (mine is a low quality cheap laptop screen).

but I think it still happens.

I cant edit original post so I have no idea how to add this more information to it.

btw, I see the bug on middle power profile too (balanced) but for reproducibility I think the power-save mode is easier to spot.

Can confirm, downgrading from 6.9.5 to 6.8.5 worked for me :slight_smile:

Found post from framework laptop forum (searched “kernel 6.9 display colors issue”) that proposes following fix:

This is ABM, it automatically adjusts contrast and brightness to save some power.
If you don’t like it there are multiple ways to disable it.
   - amdgpu.abmlevel=0 on kernel command line
   - disable the amdgpu panel power action in power profiles daemon systemd unit.

well…
we can’t call it “worked for me” if it needs a downgrade in kernel.

I think it should be called a regression.
but I think it is still kde related but with kernel stuff thrown in.

how do I report this “butg”?

Edited my post above with possible solution, though I did not try it so far

Later edit: yep, setting parameter worked, now colors stay the same

thanks.
I didnt know that. but to be honest I just (Some hour ago as you saw) find the culprit to be kernel and not kde.

1 Like

I dont know if gnome does the same or not.
can you test it?

Poster on framework laptop forum had debian with gnome and the issue was the same. From my understanding amdgpu kernel module by default has this (abmlevel) parameter in auto which is disabled by default, but it is exposed to the “user” to be controlled. And power-profiles-daemon recently received update where if they detect that this parameter is exposed to be changed, set it to 0 if computer is in the performance mode, but change it to 3 and 4 respectively when it is changed to “balanced” or “power saving”. And it explains why there are different amounts of color distortion in those modes.

To my understanding right now it is possible to control this parameter through sysfs or power-profiles-daemon. Or disable it completely by setting module parameter to 0 on boot. Control on the compositor side is probably coming some day, but it is probably best to refer to the developers on this matter :slight_smile:

Good findings. I was interested in the p-p-d behavior and found some official documentation in their codebase. It doesn’t look like this is something that KDE can control, given that the p-p-d service is its own independent thing.

I wonder if p-p-d would be open to a runtime option (via D-Bus, presumably) so we could expose a GUI option for amdgpu users.

1 Like

A kernel API for disabling this from the compositor side is quite close to being finished. I’ll soon implement it in KWin and add an option to disable this to the display settings.

4 Likes

after some more searching I am of the opinion of … wtf.

after reading these from framework forum about this (not allowed to link)

it says that “No it doesn’t. It dynamically adjusts brightness for the content and then adjusts contrast to compensate.”

so my kernel changes my contrast and my brightness based on the image (media) shown on screen?

that’s fuc… up.

why would kernel decide to do that?
why this is on by default?
though I read that windows does the same but I expected more from linux.

changing brightness and contrast with no input from user is very bad.

why would they do that.
who thought this was a good idea?

what’s next? we dop frame-rate so that we get more battery?
screen would be black and white instead of color so that we get more battery?

this is the first time I have seen stuff like this coming from kernel level.

that was why I was so sure this was kde fault.

1 Like

I’ve got the same issue on my laptop except when I go from the performance profile (display looks as I’d expect) to the power save profile my display brightens significantly which seems opposite to what I’d expect it to do. The contrast also increases and the colors look all blown out.

I’ve got the ThinkPad T14 Gen 4 AMD w/ the OLED display so I’m guessing it’s not playing nicely with the OLED display. Adding amdgpu.abmlevel=0 to the kernel parameters ‘fixes’ it by turning the feature off, but I think what’s happening isn’t the intended behavior in the first place.

System information:

Operating System: EndeavourOS
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
Memory: 30.0 GiB of RAM
Graphics Processor: AMD Radeon 780M
Manufacturer: LENOVO
Product Name: 21K3CTO1WW
System Version: ThinkPad T14 Gen 4

See drm/amd/display: Don't register panel_power_savings on OLED panels (76cb763e) · Commits · Alex Deucher / linux · GitLab. Idk what kernel version it’ll be in, but it’ll be fixed

1 Like

I am completely again changing what user sees based on power level and doing that at kernel is very bad.

and it doesnt matter what change that is. color, brighness contrast and so on.

fidelity is paramount for viewing anything.

changing an output is forbidden. for those who says this is not important think about a graphical artist that migrates to linux and gets this “feature”.

it is the same as changing output of a math function based on battery mode.

I am still confused how this was accepted.
not just by default but as a feature.