Flickering in fullscreen applications on wayland with night light enabled

As the title states, I’ve run into an issue where when I mouse over a fullscreen application, such as a game, I get a brief but very noticeable flash. This only occurs when I have the “night light” enabled and only in a wayland session. I previously “fixed” this by downgrading kwin to a version before 6.3.1, but after a system update today, doing this prevents a login on either a wayland or x11 session.

Not sure if I should post this in the Bug Report section as of now, or what other logs/information I would need to provide. Regardless, because I am used to a rather extreme night light setting and would like to continue to use wayland, I would like to know where to being to troubleshoot this.

Operating System: Arch Linux 
KDE Plasma Version: 6.3.2
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.13.4-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7800X3D 8-Core Processor
Memory: 62.3 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XT
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X670 AORUS ELITE AX
2 Likes

Oh wow, I have the same issue. + worse
Suspending Night light helped very much. Whenever I would click (attack button) in FarCry Primal, the screen would flicker hard-core for a tiny moment. This is much better now. But I still have audio-cutouts when I click or hover over certain UI-Elements in games OR hover over a full-screen Video briefly. Very weird.

Operating System: Arch Linux
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.3
Kernel Version: 6.12.21-1-lts (64-bit)
Graphics Platform: Wayland
Processors: 28 × Intel® Core™ i7-14700K
Memory: 62.5 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XTX
Manufacturer: ASUS

Probably unrelated as in my case screen flickering occured randomly, no matter what I was doing. However, I found out that when I turn brightness levels below 100% (95% on my machine) the flickering stopped for good. Perhaps it’s worth a try🤞

Experiencing same issue here. 9070xt, Arch 6.14.1, KDE 6.3.4. Might be AMD specific, as I didn’t have that particular issue when I used a nvidia card recently.

Wow I kinda forgot about making this post, I guess i’ll post how I “fixed” it so I can mark it as solved.
I was setting the refresh rate to 120 in the display configuration instead of the maximum of 180 allowed by my monitor, because I prefer higher graphic settings to higher fps. When I changed it to 180 and limited the fps to 120 on a game-by-game basis the flickering stopped. I also tried lowering it to 60 but the flickering still persisted. Since this change I have not noticed anymore flickering, even with several system updates since posting this initial thread. I’m still not sure if this is an actual solution but it worked for me. I figured its better to at least mark a solution that worked for me then leave the thread unanswered.

1 Like

Hello, noticed the same issue happening to me. Have you found the fix?

I’m seeing the exact same issue on Arch Linux KDE with an RX 7600 (two monitors, one on DisplayPort, one on HDMI), and it only affects the DisplayPort screen. The visual glitches on both the desktop and cursor fire off seemingly at random, depending on cursor movements or whatever’s being rendered. However, it always starts when resuming from suspend or when toggling “Night Mode” in KDE.

I’ve tried everything below, but the problem remains:
Different refresh rates (60 – 200 Hz):** still see glitches
:yellow_circle: Mainline kernel: still see glitches
:yellow_circle: Zen kernel: still see glitches
:yellow_circle: LTS kernel: no glitches while running, and Night Mode toggles cleanly…but glitches return immediately after suspend/resume or toggling Night Mode post‑resume
:yellow_circle: GRUB CMDLINE (quiet splash amdgpu.dcdebugmask=0x10): still see glitches

The following, AI generated script, it just a workaround. Creates a udev rule plus a system‑sleep hook that forces the GPU into “high” performance on add and after suspend:

echo 'ACTION=="add", KERNEL=="card[0-9]*", SUBSYSTEM=="drm", RUN+="/bin/bash -c '\''echo high > /sys/class/drm/card*/device/power_dpm_force_performance_level'\''"' \
  | sudo tee /etc/udev/rules.d/99-force-performance-level.rules > /dev/null \
&& sudo udevadm control --reload-rules \
&& echo -e '#!/bin/sh\ncase $1 in\n  post)\n    sleep 1\n    for card in /sys/class/drm/card*/device/power_dpm_force_performance_level; do\n      echo high > $card\n      logger "AMDGPU: Set high performance for $card"\n    done\n  ;;\nesac' \
  | sudo tee /usr/lib/systemd/system-sleep/amdgpu-performance > /dev/null \
&& sudo chmod +x /usr/lib/systemd/system-sleep/amdgpu-performance

This fixes the glitches on reboot and on resume, unless I switch Night Mode immediately after resuming, in which case the glitches come right back. That last scenario is by far the most persistent.

For now, I’ve fallen back to using my CPU’s integrated GPU (Ryzen 8000), but that’s really a downgrade. We’ll have to wait for a kernel fix, apparently this is a regression, since older archived kernels didn’t exhibit the issue.