SUMMARY https://invent.kde.org/plasma/powerdevil/-/merge_requests/407, as prerequisite of https://invent.kde.org/plasma/kwin/-/merge_requests/6155, disabled brightness animations for laptop displays when going through KWin. It's great that KWin can now fade between SDR and fake-HDR with a brightness animation by itself. However, in the process, these changes broke all other laptop display brightness animations as well, notably for dimming and applet brightness sliders. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.2.80 (around 6.2.2) KDE Frameworks Version: 6.8 Qt Version: 6.8 Graphics platform: Wayland
Yes, they are. You're linking to the MR that animates laptop brightness... it's not about HDR or anything like that. It seems that since that was merged, the animation got really choppy though, with only 3 or 4 steps in it.
Hmm, so I added some debug logging to KWin, but after restarting it, the animations are completely smooth again.
Ah yes, you're right - it's possible to observe the animation when making large jumps in brightness. Perhaps the KAuth helper invocation isn't fast enough to handle a high frequency of brightness changes per seconds reliably? If that's the case, then either we revive my PowerDevil branch for SetBrightness via login1 D-Bus, or we extend the Wayland interface to provide more context about the intended animation (or lack thereof). But if restarting KWin helps, maybe the issue is elsewhere.
I still see brightness animations on my git master setup, FWIW.
Brightness animations on my system (Intel i7-8565U with iGPU, debug builds of kwin_wayland and powerdevil) are still visibly not as fluent as they used to be. Reopening.
I added some debug logging in powerdevil and the kauth helper takes about 40-50ms between runs, with more intermediary values from KWin being ignored. So either we'd need to make kauth faster, or wait for the KMS API. While efforts for the latter have been on pause for a long time, someone at XDC told me they're gonna finally make it happen now, so hopefully we can just rely on that instead.
*** Bug 511801 has been marked as a duplicate of this bug. ***
Replying here because my other bug report was marked as a duplicate. Yes, I have reason to believe this is absolutely related to HDR. The reason is the backlight driver is triggered based on the brightness of the content on-screen, and in my case this cannot be disabled. I confirmed this by observing the brightness values in /sys/class/backlight/. For example, if I minimize and maximize a window with full white, the backlight values in /sys/backlight change without me doing anything else. So something is clearly manipulating the backlight driver based on whatever the compositor is doing. If you have a suggestion of somewhere else to troubleshoot this behavior, I'm open to suggestions. But this is problem didn't start until the new SDR->HDR feature was added.
Unless you have actual HDR content visible, it doesn't do anything of the sort. Especially not if you turn the option off.