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.
Hello! I've encountered this issue again in Plasma 6.7, AFTER swapping all my inputs to my RTX4090 and disabling amd_gpu entirely. I have these 4 monitors: Dell U2715H - Displayport Alienware AW3225QF - Displayport Dell S2721DGF - Displayport Onkyo NR-TX7100 - HDMI 2.1 and I was trying to set up my AW3225QF and TX7100 @ 120hz 200% scaling at 4k with the other two monitors disabled so that I can set them as my SDDM login settings (via Colors & Themes > Login Screen (SDDM) and I noticed the udev event popping up (As I've been running journalctl -f while SSH'd so I can restart if I encounter https://bugs.kde.org/show_bug.cgi?id=507285 again) Same timing, same udev event it seems: KERNEL[802.804550] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5074 MAJOR=226 MINOR=1 UDEV [802.810815] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5074 USEC_INITIALIZED=217996969 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=1 DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: CURRENT_TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: KERNEL[811.365057] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5075 MAJOR=226 MINOR=1 UDEV [811.373062] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5075 USEC_INITIALIZED=217996969 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=1 DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: CURRENT_TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: KERNEL[819.919858] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5076 MAJOR=226 MINOR=1 UDEV [819.927645] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5076 USEC_INITIALIZED=217996969 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=1 DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: CURRENT_TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: KERNEL[828.484977] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5077 MAJOR=226 MINOR=1 UDEV [828.492930] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=5077 USEC_INITIALIZED=217996969 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=1 DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: CURRENT_TAGS=:uaccess:switcheroo-discrete-gpu:seat:master-of-seat: Is this helpful information?
There's only two commits in the same file in 6.7 vs. 6.6, so I don't know what could've triggered this. I'm relatively confident how to fix it for good though: Just keep the drm nodes open, instead of re-opening them on every udev event. The reason we didn't do it so far is mostly fear of GPUs not going into powersave mode with that. Bug 521814 kind of confirmed that, but since Vulkan forces us into that situation, we might as well fix this properly.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9568
Git commit f8f5bec7b0adcf37bf069b61cd8d992ac830b2bd by Xaver Hugl. Committed on 28/07/2026 at 13:25. Pushed by zamundaaa into branch 'master'. backends/drm: don't remove GPUs without outputs Non-primary GPUs without outputs were removed previously because: - it was required for allowing GPUs to fully power down - being able to unload the driver for VFIO requires file descriptors of the device to be closed However, this was 5 years ago, and GPU power management has gotten less terrible since then. Vulkan drivers also open file descriptors of all GPUs, so drivers must handle this situation properly either way. For VFIO, udev "remove" events can be used to make KWin remove the GPU, which is a better solution, since it works even while displays are connected to it. This also fixes KWin waking up GPUs when it receives udev events for a GPU that's in powersave mode, which could (besides the power management impact) also block KWin's main thread for some time. M +1 -4 src/backends/drm/drm_backend.cpp https://invent.kde.org/plasma/kwin/-/commit/f8f5bec7b0adcf37bf069b61cd8d992ac830b2bd
Git commit f47bc9b29cad6d6e6df66b196883ea4b22f2edec by Xaver Hugl. Committed on 28/07/2026 at 14:30. Pushed by zamundaaa into branch 'Plasma/6.7'. backends/drm: don't remove GPUs without outputs Non-primary GPUs without outputs were removed previously because: - it was required for allowing GPUs to fully power down - being able to unload the driver for VFIO requires file descriptors of the device to be closed However, this was 5 years ago, and GPU power management has gotten less terrible since then. Vulkan drivers also open file descriptors of all GPUs, so drivers must handle this situation properly either way. For VFIO, udev "remove" events can be used to make KWin remove the GPU, which is a better solution, since it works even while displays are connected to it. This also fixes KWin waking up GPUs when it receives udev events for a GPU that's in powersave mode, which could (besides the power management impact) also block KWin's main thread for some time. (cherry picked from commit f8f5bec7b0adcf37bf069b61cd8d992ac830b2bd) M +1 -4 src/backends/drm/drm_backend.cpp https://invent.kde.org/plasma/kwin/-/commit/f47bc9b29cad6d6e6df66b196883ea4b22f2edec
Amazing work. Thank you so much Zamundaaa!
Sorry to bump this again, I'm still seeing the same stutter in 6.7.4, is there any more debug information I can provide? This is on NVIDIA 610.57.04 / kernel 7.1.13 on Fedora 44, if that helps. KERNEL[13128.559756] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=8119 MAJOR=226 MINOR=1 UDEV [13128.567031] change /devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/drm/card1 SUBSYSTEM=drm HOTPLUG=1 DEVNAME=/dev/dri/card1 DEVTYPE=drm_minor SEQNUM=8119 USEC_INITIALIZED=18841943 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=1 DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card TAGS=:switcheroo-discrete-gpu:master-of-seat:seat:uaccess: CURRENT_TAGS=:switcheroo-discrete-gpu:master-of-seat:seat:uaccess: