SUMMARY Since an upgrade to NVidia drivers 595, my setup experiences periodical stops and stutter in updating displays - the system is working fine below (can hear sound), but everything stops. Can last from fractions of seconds to seconds. There are long periods of calm, then some periods where it starts slow and grows, etc. Also, journalctl floods with messages: Mar 22 09:40:26 lwpcomp4 kwin_wayland[6257]: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT" Mar 22 09:40:26 lwpcomp4 kwin_wayland[6257]: 0x500: GL_INVALID_ENUM error generated. Invalid <face>. a few dozen per second. My setup is an optimus laptop with 2 external monitors connected, one through USB-C and one HDMI. STEPS TO REPRODUCE 1. Install an nvidia driver on Fedora 43 2. Connect 2 external monitors, one through usb-c, one through hdmi 3. Just use the system. Perhaps the bug appears more frequently when playing videos on firefox 4. Check the journalctl -b 0 --since "1 minutes ago": a flood of OBSERVED RESULT Stuters in displays updates, flood in the log. EXPECTED RESULT System working fine, log calm. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 43 KDE Plasma Version: 6.6.3 KDE Frameworks Version: 6.24.0 Qt Version: 6.10.2 Kernel Version: 6.19.8-200.fc43.x86_64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 9 7940HS w/ Radeon 780M Graphics Memory: 32 GiB of RAM (30.6 GiB usable) Graphics Processor 1: AMD Radeon 780M Graphics Graphics Processor 2: NVIDIA GeForce RTX 4070 Laptop GPU ADDITIONAL INFORMATION
Same problem on cachy-os with kde Display (GSM5C56): 1920x1080 in 27", 60 H* Display (BOE0823): 1920x1080 in 17", 60 H] Display (LG HDR 4K): 1920x1080 in 27", 60] DE: KDE Plasma 6.6.3 WM: KWin (Wayland) CPU: AMD Ryzen 9 5900HX (16) @ 4.68 GHz GPU 1: NVIDIA GeForce RTX 3070 Mobile / M] GPU 2: AMD Radeon Vega Series / Radeon Ve] Memory: 11.23 GiB / 30.70 GiB (37%) Swap: 0 B / 30.70 GiB (0%) Disk (/): 258.31 GiB / 1.82 TiB (14%) - bs Big problem is that journalctl writes about 20-40 mB/s of logs on disk. Affected version of kwin for me kwin 6.6.3-1.1 nvidia drivers: linux-cachyos-nvidia-open 6.19.6-1 (drivers 595.45.04)
The problem remains on drivers 595.58.03 btw. in my first report the platform is shown to be X11, while it is Wayland. It was an automatic copy from system settings... interesting.
Please get the output of wayland-info on an older driver without the issue and on the new one.
Created attachment 191013 [details] wayland info output on a driver with the problem
(In reply to Zamundaaa from comment #3) > Please get the output of wayland-info on an older driver without the issue > and on the new one. I can't show from the older driver version. I have nvidia drivers installed from the nvidia repository and it seems they don't keep the older versions. Otherwise I would downgrade to avoid this nightmare.
Any other info I can provide? Reverting to the old driver causes the whole KDE to hang after login, so wayland-info can't be provided.
(In reply to Lech from comment #6) > Any other info I can provide? Reverting to the old driver causes the whole > KDE to hang after login, so wayland-info can't be provided. It seems, at least for my distro (cachyos) that downgrading gpu drivers strictly implies also having to deal with kernel problems, it's probably the same for you, maybe you didn't downgrade correctly or just can't, I might suggest using ctrl+alt+f1 to get the wayland-info command done before loggin-in. Also to cite some recent external references: https://forums.developer.nvidia.com/t/bug-invalid-framebuffer-status-gl-framebuffer-incomplete-missing-attachment/363108 seems like it's due because of nvidia drivers, moreover the workaround that I did myself and seems to partially work is https://bbs.archlinux.org/viewtopic.php?pid=2290146#p2290146 Also on cachyos forums: https://discuss.cachyos.org/t/ssd-is-at-max-writing-all-the-time/26409/20 "I found an interesting thread on the KDE bug-tracker site about this error from a few months ago. Pay attention to comments #7 and #10, where it is suggested that at least for that person, an external monitor connected to a dual-GPU laptop is the cause, and the logging level can be set lower to surpress these messages. bugs.kde.org 511852 – Journal entries like: GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT" people also present a command to revert the drivers on cachy os I hope to have helped a bit aggregating some more details
Created attachment 191197 [details] kwin-wayland-bug-report
Same problem, created an attachment https://bugs.kde.org/attachment.cgi?id=191197 with my logs
Created attachment 191199 [details] 595-driver-with-fix
Created attachment 191200 [details] 595-driver-without-fix
Created attachment 191201 [details] 580-driver-without-fix
Hopefully I downgraded correctly. I uploaded also the wayland-info with the fix stated here https://bbs.archlinux.org/viewtopic.php?pid=2290146#p2290146 After downgrading the drivers to 580, I still receive the error with an added line "Failed to create framebuffer: Invalid argument" but only about every minute (I don't get 20mb/s logs on the ssd anymore) while the error occurs, the screen freezes for about 1-2 seconds then everything resumes normally, so the problem was present before already in 580. From the research on the internet it seems that the problem is caused by bad nvidia drivers, at first I thought it was a problem with new version of kde. Maybe there's a way to workaround whatever is being used in the drivers that causes the issue. Thanks
So I spent some time staring at the drm backend code, and can't really explain this. KWin decides on format+modifiers once, and then the same buffers get re-used afterwards (and when additional ones are allocated, the same format that worked before is used). I also can't replicate this on my setup. Maybe it's specific to AMD->Nvidia, and doesn't happen with Intel? FWIW for Plasma 6.7 I rewrote a lot of the multi GPU copy code. By default it uses Vulkan now, so there's a decent chance the issue will go away with that.
*** Bug 519597 has been marked as a duplicate of this bug. ***
Alright, I managed to trigger it now. The cause is that the Nvidia driver doesn't support rendering to linear buffers with OpenGL, but it does support allocating linear buffers. Our multi GPU copy path doesn't do an early check for whether or not rendering to the allocated buffer is supported, so it re-tries every frame for the cursor, and when rendering fails, it falls back to a software cursor instead. The OpenGL errors thus get logged every single frame the cursor is visible.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9158
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9159
*** Bug 518206 has been marked as a duplicate of this bug. ***
Git commit 4729b0bb8b51af77181df7aae6ce2ae81a128784 by Xaver Hugl. Committed on 30/04/2026 at 13:50. Pushed by zamundaaa into branch 'master'. backends/drm: drop dmabuf import modes Their usefulness is questionable, and on some drivers they happen to prevent the fallback to CPU copy for the cursor from working, since addFB succeeds somehow, but the atomic test later fails. If we later find some hardware where it's proven to be beneficial, we can add this path back with checks specific to that hardware. M +2 -19 src/backends/drm/drm_egl_layer_surface.cpp M +0 -2 src/backends/drm/drm_egl_layer_surface.h https://invent.kde.org/plasma/kwin/-/commit/4729b0bb8b51af77181df7aae6ce2ae81a128784
Git commit 413face71a9b4c622c2817b8da5d888e2cd77f38 by Xaver Hugl. Committed on 30/04/2026 at 13:55. Pushed by zamundaaa into branch 'Plasma/6.6'. backends/drm: don't attempt multi GPU copies with unsupported formats Specifically with the proprietary Nvidia driver, the plane requires a linear modifier, which we can't render to with OpenGL. When attempting to render with that buffer, we end up logging errors at a really high rate, and falling back to a software cursor rather than another import mode. M +6 -1 src/backends/drm/drm_egl_layer_surface.cpp https://invent.kde.org/plasma/kwin/-/commit/413face71a9b4c622c2817b8da5d888e2cd77f38
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9162
Git commit 64d608907fc427b0791d7531959010c5093eb69e by Xaver Hugl. Committed on 30/04/2026 at 15:26. Pushed by zamundaaa into branch 'Plasma/6.6'. backends/drm: drop dmabuf import modes Their usefulness is questionable, and on some drivers they happen to prevent the fallback to CPU copy for the cursor from working, since addFB succeeds somehow, but the atomic test later fails. If we later find some hardware where it's proven to be beneficial, we can add this path back with checks specific to that hardware. (cherry picked from commit 4729b0bb8b51af77181df7aae6ce2ae81a128784) M +3 -19 src/backends/drm/drm_egl_layer_surface.cpp M +0 -2 src/backends/drm/drm_egl_layer_surface.h https://invent.kde.org/plasma/kwin/-/commit/64d608907fc427b0791d7531959010c5093eb69e
With these commits, the next bugfix release should take care of this. Until then, you can use > KWIN_FORCE_SW_CURSOR=1 to work around the issue.
Thanks for the support! can't wait for the release :)
*** Bug 519426 has been marked as a duplicate of this bug. ***
*** Bug 519856 has been marked as a duplicate of this bug. ***