| Summary: | Wayland Night Color Mode causes Color Issues (notably on dark areas) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Dominic <dominicgluskin> |
| Component: | night color | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | alexl, kde, nate, spider.gaming, xaver.hugl |
| Priority: | NOR | ||
| Version: | 6.3.2 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/6dbea6dafceff7e1ca744c272b5477ef07c22a34 | Version Fixed In: | 6.3.3 |
| Sentry Crash Report: | |||
| Attachments: |
drn info
The output of drm_info |
||
|
Description
Dominic
2025-02-27 20:37:27 UTC
Tested on 6.3.2 the visual bug is still there. The issue still is present on both prefer efficiency and prefer color accuracy settings. I'm on an Arch Linux based system running KDE Plasma 6 in X11. Since the kwin update to 6.3.2.1-1, Night Light has a stark green/purple hue instead of red/orange. (In reply to Geno from comment #2) > I'm on an Arch Linux based system running KDE Plasma 6 in X11. > > Since the kwin update to 6.3.2.1-1, Night Light has a stark green/purple hue > instead of red/orange. Sounds like a different issue, mine is exclusive to wayland Fedora 41, Plasma 6.3.2, Wayland same thing. Thinkpad T480 (Intel UHD 620) There are related issues with night light like #500036 and #499103 but it does get worse on fullscreen rendered/accelerated apps. Games have very blocky shadows like the gamma is very aggressive (low for dark areas), and it's also visible on videos. When I play a video in mpv, smplayer or vlc, it's already affected when not fullscreen. But switching to fullscreen makes it much worse, shadows get completely clipped. Strangely enough, when I move or click the mouse (even if it doesn't cause the UI to show), the worse variant disappears for a few seconds and then comes back. Btw it doesn't happen in Gnome/Wayland with their implementation of night light. Can't say for X11 since I can't launch Plasma with it. I’m also affected in Tuxedo OS, Plasma 6.3.2 in Wayland. I didn’t play games but noticed on full-screen videos. I thought the video was crappy, but when I move the mouse, the dark areas re-appear. Happens both in VLC and Haruna. Whenever the mouse disappear, the dark areas get cropped. I noticed that if I enable the Desktop Effect "Show Compositing", the issue happens when "Compositing" is not visible. I found a temporary workaround for videos, which is to use Celluloid. In Celluloid, in full-screen, the cursor disappear but the compositing continues, so there is no cropping of dark areas. Also, switching to X11, there are no issues at all there. Let's please not pile on night light related issues in one bug report. (In reply to Geno from comment #2) > I'm on an Arch Linux based system running KDE Plasma 6 in X11. > > Since the kwin update to 6.3.2.1-1, Night Light has a stark green/purple hue > instead of red/orange. Please open a separate bug report for that. If you can, a bisect would be very useful... afaict, there were no Xorg specific commits between 6.3.1 and 6.3.2. (In reply to Aroun from comment #5) > Whenever the mouse disappear, the dark areas get cropped. > I noticed that if I enable the Desktop Effect "Show Compositing", the issue > happens when "Compositing" is not visible. Okay, then this is caused by direct scanout. You can work around it by setting https://invent.kde.org/plasma/kwin/-/wikis/Environment-Variables#kwin_drm_no_direct_scanout to 1. Now the question is, why it happens. Can everyone affected please attach the output of drm_info on their systems? Created attachment 179078 [details]
drn info
> Variables#kwin_drm_no_direct_scanout to 1. That fixed it for me both for videos and games. (the colors are still off as per the other night light issues but the shadows don't clip like they did) > Can everyone affected please attach the output of drm_info on their systems? Did I do it right? Created attachment 179080 [details]
The output of drm_info
ok, so we have
> "DEGAMMA_LUT_SIZE" (immutable): range [0, UINT32_MAX] = 1024
in both cases. That should be plenty for an 8 bit framebuffer, but it's possible that the resolution of the actual hardware doesn't match this number.
On my Intel laptop the DEGMMA_LUT_SIZE is only 129, so this bug doesn't happen there because KWin doesn't use LUTs with such a low resolution.
I think for now we should just disable the DEGAMMA lut on Intel, which should remove the problem. Longer term we get better defined APIs for such color operations, where hopefully this won't be an issue.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7258 Git commit 83e2f5703c6ab2fd0eda2cd9626be4aad6d34987 by Xaver Hugl. Committed on 04/03/2025 at 17:40. Pushed by zamundaaa into branch 'master'. backends/drm: also don't use DEGAMMA_LUT on Intel It doesn't seem to have the resolution that the API claims. In the hopefully near future, the degamma lut will be replaced with the better defined drm color pipeline API anyways. M +1 -1 src/backends/drm/drm_crtc.cpp https://invent.kde.org/plasma/kwin/-/commit/83e2f5703c6ab2fd0eda2cd9626be4aad6d34987 Git commit 6dbea6dafceff7e1ca744c272b5477ef07c22a34 by Xaver Hugl. Committed on 04/03/2025 at 23:41. Pushed by zamundaaa into branch 'Plasma/6.3'. backends/drm: also don't use DEGAMMA_LUT on Intel It doesn't seem to have the resolution that the API claims. In the hopefully near future, the degamma lut will be replaced with the better defined drm color pipeline API anyways. (cherry picked from commit 83e2f5703c6ab2fd0eda2cd9626be4aad6d34987) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +1 -1 src/backends/drm/drm_crtc.cpp https://invent.kde.org/plasma/kwin/-/commit/6dbea6dafceff7e1ca744c272b5477ef07c22a34 (In reply to Zamundaaa from comment #10) > I think for now we should just disable the DEGAMMA lut on Intel, which > should remove the problem. Longer term we get better defined APIs for such > color operations, where hopefully this won't be an issue. Thanks for intel users' sake, but OP uses nvidia so it may be something else? Btw is it common that intel hw doesn't report capabilities properly? (Seems to me like a stretch to assume it wouldn't, unless it's happened before) OP is using Intel to drive the screen. The degamma lut is already disabled for NVidia for unrelated reasons. (In reply to Zamundaaa from comment #15) > OP is using Intel to drive the screen. The degamma lut is already disabled > for NVidia for unrelated reasons. Correct, I have a optimus system, laptop screen runs off of intel card, external monitor (via display port) runs on nvidia. What was changed in the update to have caused night light to suddenly ruin colors on screens? I'll have to wait for the patch to be pushed to OpenSUSE Tumbleweed repos before I can say for sure it's fixed for me (In reply to Dominic from comment #16) > What was changed in the update to have caused night light to suddenly ruin > colors on screens? We made night light much more accurate (read https://zamundaaa.github.io/wayland,/colormanagement/2025/01/07/fixing-night-light.html for more details), but that requires a bit more complex color operations than it did before. When we try to offload those operations to the display controller in fullscreen mode, that just happened to make the issue visible that you were a lot less likely to come across before. > Btw is it common that intel hw doesn't report capabilities properly? (Seems to me like a stretch to assume it wouldn't, unless it's happened before) Sorry, I noticed I forgot to answer that. Yes, this sort of thing did happen before with Intel - on Tigerlake, GAMMA_LUT_SIZE was 262145, and the driver actually used like 1000 of those values. |