SUMMARY Colors in games are noticeably worse, the best example is in Deadlock, going to one of the corners and turning night light off and on shows a very noticeable drop in quality, (it looks similar to how photos taken in the dark have that weird shading to it). Another example is the skill tree in Path of Exile. What's also weird, and I'm not sure if it's related, but moving the mouse back from my laptop monitor to my secondary monitor seems to dim my laptop screen, almost like I have the dim inactive windows effect on. Before the 6.3 update this wasn't an issue. The more extreme of a temperature (3000K>) the issues become more noticeable This issue is exclusively on Wayland, on X11 it works just fine and none of the mentioned bugs are present. I can't share a screenshot because it doesn't capture night light. STEPS TO REPRODUCE 1. Log into a Plasma Wayland 2. Open something with a dark image 3. Turn on Night Light and notice the difference in quality 4. Move mouse back and forth from monitor to show the dimming effect SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20250222 KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.3-1-default (64-bit) Processors: 12 × Intel® Core™ i7-10750H CPU @ 2.60GHz Memory: 15.4 GiB of RAM Graphics Processor 1: Intel® UHD Graphics Graphics Processor 2: NVIDIA GeForce RTX 2070 Manufacturer: Micro-Star International Co., Ltd. Product Name: GE75 Raider 10SF System Version: REV:1.0
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.