Created attachment 191832 [details] kscreen output SUMMARY I have the following display devices connected (attached kscreen-doctor output): Dell U2715H - Displayport Alienware AW3225QF - Displayport Dell S2721DGF - Displayport Onkyo NR-TX7100 - HDMI 2.1 In the following configurations: Desktop usage: U2715H/AW3225QF/S2721DGF enabled, TV disabled TV usage: U2715H/AW3225QF/S2721DGF disabled, TV enabled Occasionally when using the Onkyo NR-TX7100 connected to an LG C1 TV, the desktop will stutter/freeze every 8.5 seconds for around a second. I have noticed this occur either when the display switches off and powers back on (when it hits the "turn off screen" timer set in KDE) OR when opening "System Monitor", I'm not sure why this triggers it, but I've noticed a correlation. This bug DOES NOT repro when I am using the system in "Desktop" mode. Audio continues playing, the mouse freezes, and input events appear to still be processed, as if you hold a key, the output will freeze, but when the stutter finishes, the repeated text will render. The stutter can only sometimes be resolved by the following 1) Switching to TTY/back (Sometimes resolves the issue) 2) Switching VRR on/off from the TV (Sometimes resolves the issue) 3) Rebooting the connected PC (Sometimes resolves the issue) 4) Powering down the AV Receiver/TV/PC (Always resolves the issue) I see the following from "udevadm monitor", ever ~8.5 seconds: KERNEL[8749.454956] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card2 (drm) UDEV [8749.461736] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card2 (drm) Further details: ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card2 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card2 DEVTYPE=drm_minor SEQNUM=7431 USEC_INITIALIZED=8336971 ID_PATH=pci-0000:01:00.0 ID_PATH_TAG=pci-0000_01_00_0 NVME_HOST_IFACE=none ID_FOR_SEAT=drm-pci-0000_01_00_0 MAJOR=226 MINOR=2 DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card TAGS=:switcheroo-discrete-gpu:seat:uaccess:master-of-seat: CURRENT_TAGS=:switcheroo-discrete-gpu:seat:uaccess:master-of-seat: KERNEL[8963.331283] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card2 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card2 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card2 DEVTYPE=drm_minor SEQNUM=7446 MAJOR=226 MINOR=2 "journalctl -f" has the same repeating date at the same time: Mar 01 02:40:31 unicomplex org_kde_powerdevil[2454]: [216114] Udev event detected STEPS TO REPRODUCE 1. Use the machine when connecting to an AV Reciever/Television at 4k/120hz+ with HDR + VRR enabled. 2. Let the display turn off and turn on or try opening "System Monitor", this isn't 100% repro. 3. Move the mouse cursor for ~10 seconds, or use udevadm/journal to check the logs for a lag spike that occurs ~8.5s OBSERVED RESULT The system display will freeze for a second or so, every ~8.5 seconds. EXPECTED RESULT Display never freezes or stutters SOFTWARE/OS VERSIONS KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.11.0 Kernel Version: 6.19.12-1-default (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor Memory: 64 GiB of RAM (61.9 GiB usable) Graphics Processor 1: NVIDIA GeForce RTX 4090 Graphics Processor 2: AMD Ryzen 9 7950X3D 16-Core Processor ADDITIONAL INFORMATION This issue occurs on OpenSUSE, Fedora, Gentoo, Arch, every KDE plasma distro I've tested. It has occurred since I started using KDE Plasma full time, ~6 months or so. I haven't noticed this on other DEs, but I mainly use KDE 95% of the time. kscreen-doctor attached, please don't hesitate if you require any further information.
Please attach the output of drm_info. The driver detecting a hotplug every 8.5s isn't that surprising, many displays do ridiculously dumb stuff when they're in standby mode. It shouldn't usually be all that noticeable though... All KWin does in that situation is to read back KMS properties, and only if necessary, do a modeset.
Created attachment 191919 [details] drm_info Please see attached.
Also if it helps clarify on input during stutter, if there is a stutter while I am typing, the key that is active at the time acts as though it was held down during the duration of the freeze (As if the state changes of keyboard keys aren't registered during the event).
I think it might be down to power management of the integrated GPU. When the display disconnects and re-connects, KWin probes all GPU inputs, which likely turns the integrated GPU on (because drivers are still bad at this) and that takes some time and blocks KWin until it's complete. Then after a little time, the GPU powers down again. This kind of thing is usually only seen with dedicated GPUs, but it matches what you describe perfectly. Opening system monitor also wakes the GPU, which can block things. There isn't generally a lot we can do about this except to yell at driver developers to fix it, but in this specific case, there's a chance: The change events you see are on the dedicated GPU, not on the integrated one. If we restrict updating outputs to the GPU that has the events, the problem might stop being so noticeable for you.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9161
Thank you! Funnily enough, I only have the iGPU enabled as a workaround to https://bugs.kde.org/show_bug.cgi?id=507285; would it be worth me disabling the iGPU and trying to repro just on NVIDIA?
> would it be worth me disabling the iGPU and trying to repro just on NVIDIA? Yeah. If my theory is correct, just unplugging the display connected to the iGPU should work around the issue.
Git commit 5384c2f8c157296a5fc941adccf38b0a92b17403 by Xaver Hugl. Committed on 02/05/2026 at 14:30. Pushed by zamundaaa into branch 'master'. backends/drm: only update outputs on GPUs that actually changed Especially when power management is involved, probing connectors on a GPU can take time, during which KWin's main thread would be blocked. M +7 -7 src/backends/drm/drm_backend.cpp M +1 -1 src/backends/drm/drm_backend.h M +3 -1 src/backends/drm/drm_gpu.cpp M +3 -1 src/backends/drm/drm_output.cpp https://invent.kde.org/plasma/kwin/-/commit/5384c2f8c157296a5fc941adccf38b0a92b17403
Thank you so much! I also reported the other bug with the 4 monitors to developers.nvidia.com, hopefully it can gain some traction. Thanks again!
Git commit dd5864bfa4ab6ca779a08e0f8d1ae8b7a7c5b15d by Xaver Hugl. Committed on 02/05/2026 at 21:19. Pushed by zamundaaa into branch 'Plasma/6.6'. backends/drm: only update outputs on GPUs that actually changed Especially when power management is involved, probing connectors on a GPU can take time, during which KWin's main thread would be blocked. (cherry picked from commit 5384c2f8c157296a5fc941adccf38b0a92b17403) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +7 -7 src/backends/drm/drm_backend.cpp M +1 -1 src/backends/drm/drm_backend.h M +3 -1 src/backends/drm/drm_gpu.cpp M +3 -1 src/backends/drm/drm_output.cpp https://invent.kde.org/plasma/kwin/-/commit/dd5864bfa4ab6ca779a08e0f8d1ae8b7a7c5b15d
Unfortunately I'm still seeing this on 6.6.5, either by opening System Monitor, or by leaving the system idle, powering the display off, and coming back to it after a while. It seems like the freeze time is slightly reduced, however. For now, I wrote a bash alias that switches displays back to my PC with kscreen-doctor, waits 10 seconds, and switches back to the TV with kscreen-doctor, and this appears to resolve it. Unsure if I should be reopening this or not. So haven't touched the bug status.
> Unfortunately I'm still seeing this on 6.6.5, either by opening System Monitor, or by leaving the system idle, powering the display off, and coming back to it after a while. That's expected. The underlying issue can only be fixed in the driver, what I added just works around some cases.