DESCRIPTION After upgrade to Plasma 6.7 (on Intel graphics), kwin_wayland takes about 5% CPU on idle (and a lot more when doing trivial tasks like viewing a static web page with no animations). STEPS TO REPRODUCE 1. Upgrade to Plasma 6.7 2. Launch KDE normally, and run htop to monitor usage. OBSERVED RESULT kwin_wayland takes high CPU usage even when idle. EXPECTED RESULT Low CPU usage when idle. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.7.1 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.1 Kernel Version: 6.18.36-1-lts (64-bit) Graphics Platform: Wayland Processors: 6 × Intel® Core™ i5-9600K CPU @ 3.70GHz Memory: 16 GiB of RAM (15.3 GiB usable) Graphics Processor: Mesa Intel® UHD Graphics 630 ADDITIONAL INFORMATION If I set the variables `KWIN_DRM_USE_MODIFIERS=0` and `KWIN_DRM_NO_ATOMIC=1` before starting KDE, then the CPU usage drops to about 1/1.5% on idle, and stays below 10% when doing trivial tasks.
Operating System: Fedora Linux 43 KDE Plasma Version: 6.7.1 KDE Frameworks Version: 6.27.0 Qt Version: 6.10.3 Kernel Version: 7.0.13-100.fc43.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × 13th Gen Intel® Core™ i5-1340P Memory: 32 GiB of RAM (30,9 GiB usable) Graphics Processor: Intel® Iris® Xe Graphics Manufacturer: Intel(R) Client Systems Product Name: NUC13ANKi5 System Version: N11211-203 UHD screen, color correction and night mode. kwin uses ≈50% of a single core after update when repainting. KWIN_DRM_USE_MODIFIERS=0 returns it to regular 10-15% KWIN_DRM_NO_ATOMIC=1 has no effect.
"KWIN_DRM_NO_ATOMIC" is not an environment variable that KWin actually checks for. Please run > drm_info > info.log and > journalctl --user-unit plasma-kwin_wayland --boot 0 > kwin.log and attach the resulting files here, once with the modifiers environment variable set to 1, and once with it set to 0 (don't forget to reboot in between).
Created attachment 193944 [details] KWIN_DRM_USE_MODIFIERS=0 (In reply to Zamundaaa from comment #2) > "KWIN_DRM_NO_ATOMIC" is not an environment variable that KWin actually > checks for. > > Please run > > drm_info > info.log > and > > journalctl --user-unit plasma-kwin_wayland --boot 0 > kwin.log > and attach the resulting files here, once with the modifiers environment > variable set to 1, and once with it set to 0 (don't forget to reboot in > between).
Created attachment 193945 [details] running without environment variables I did not reboot, just relogin with restarting sddm. Made sure that kwin_wayland does not have the environment by reading environ.
Important note: I use night light function. In a default configuration, with night light enabled, kwin consumes ~55% of CPU when something is repainting. With KWIN_DRM_USE_MODIFIERS=0 it consumes 10-11%, as usual. Without night light I don't see any difference.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9516
The patch fixed it for me. Thanks!
Thanks for the fast fix; I'll have to wait until Arch ships it and I'll post back if it's not working. (If there's an easy way for me to test it on arch without compiling mysself let me know and I'll try.)
Git commit 1ad316036405196854cf72cfff831e33ef594d46 by Xaver Hugl. Committed on 02/07/2026 at 10:56. Pushed by zamundaaa into branch 'master'. backends/drm: match color pipelines already in importScanoutBuffer If a pipeline can't be matched or is even missing, which is relatively common, then we can abort preparations for direct scanout earlier and avoid buffer re-allocations that would just be a waste of time anyways. M +20 -6 src/backends/drm/drm_colorop.cpp M +1 -0 src/backends/drm/drm_colorop.h M +11 -2 src/backends/drm/drm_egl_layer.cpp https://invent.kde.org/plasma/kwin/-/commit/1ad316036405196854cf72cfff831e33ef594d46
Git commit 2a4806495d0716cd88f9f06a7893e663a426f837 by Xaver Hugl. Committed on 02/07/2026 at 10:56. Pushed by zamundaaa into branch 'master'. compositor: attempt direct scanout before preparing rendering Otherwise we may re-allocate in preparation for underlays, just to then throw the buffer away again when direct scanout import fails. M +6 -5 src/compositor.cpp https://invent.kde.org/plasma/kwin/-/commit/2a4806495d0716cd88f9f06a7893e663a426f837
Git commit 1c1ba7e836bb22671fdd9cc9f637ad2e98fbd2e7 by Xaver Hugl. Committed on 02/07/2026 at 12:16. Pushed by zamundaaa into branch 'Plasma/6.7'. compositor: attempt direct scanout before preparing rendering Otherwise we may re-allocate in preparation for underlays, just to then throw the buffer away again when direct scanout import fails. (cherry picked from commit 2a4806495d0716cd88f9f06a7893e663a426f837) M +6 -5 src/compositor.cpp https://invent.kde.org/plasma/kwin/-/commit/1c1ba7e836bb22671fdd9cc9f637ad2e98fbd2e7
Git commit 3dda580d6c033aee7a238e4086d032de032acb90 by Xaver Hugl. Committed on 02/07/2026 at 12:16. Pushed by zamundaaa into branch 'Plasma/6.7'. backends/drm: match color pipelines already in importScanoutBuffer If a pipeline can't be matched or is even missing, which is relatively common, then we can abort preparations for direct scanout earlier and avoid buffer re-allocations that would just be a waste of time anyways. (cherry picked from commit 1ad316036405196854cf72cfff831e33ef594d46) M +20 -6 src/backends/drm/drm_colorop.cpp M +1 -0 src/backends/drm/drm_colorop.h M +11 -2 src/backends/drm/drm_egl_layer.cpp https://invent.kde.org/plasma/kwin/-/commit/3dda580d6c033aee7a238e4086d032de032acb90
(In reply to gi1242 from comment #8) > Thanks for the fast fix; I'll have to wait until Arch ships it and I'll post > back if it's not working. (If there's an easy way for me to test it on arch > without compiling mysself let me know and I'll try.) I’ve compiled a modified version, and can confirm it works perfectly. I can send it to you if you don’t want to wait for Plasma 6.7.3.
did this commit break KWIN_DRM_NO_DIRECT_SCANOUT=1 ??? i use this to fix brave freezing (sound works), when video is in fullscreen, and i've been running this for months now, no issues up to 6.7.2, now it looks like this variable isn't being honored anymore in 6.7.3.
No.