The core issue is a structural defect in KWin 6.5.1's DRM initialization logic. It rigidly attempts to access the device file at /dev/dri/card0 and cannot gracefully handle the absence of this file (an ENOENT error) by automatically falling back to the only available, valid GPU device, /dev/dri/card1. Chain of Consequences: Kernel → udev → KWin The problem is triggered by a seemingly optimal configuration, revealing the KWin bug: 1. Kernel Optimization (The Trigger) Action: added the kernel parameter nvidia-drm.fbdev=0 to the GRUB command line. Result: this flag instructs the kernel's NVIDIA driver not to register the legacy VESA/simple framebuffer device. 2. udev Device Management (Correct Action) Action: as a result of the kernel's decision, the udev device manager never receives an event to create the device file for the fallback GPU. Result: the file /dev/dri/card0 is correctly and intentionally absent from the filesystem. This verifies the system configuration is clean. 3. KWin Failure (The Bug) Action: KWin begins its initialization and attempts to access the DRM backend via a hard-coded or strictly ordered search for device files. Result (The Bug): KWin fails on the non-existent /dev/dri/card0 and aborts the entire DRM initialization sequence, resulting in the log error: kwin_wayland_drm: failed to open drm device at "/dev/dri/card0". some tests: a) journalctl -b -e --user-unit=plasma-kwin_wayland.service -g "kwin" kwin_wayland_drm: failed to open drm device at "/dev/dri/card0" b) ls -l /dev/dri/ total 0 2 root root 100 nov 4 20:06 by-path 1 root video 226, 1 nov 4 20:06 card1 1 root render 226, 128 nov 4 20:06 renderD128 Operating System: KDE neon User Edition KDE Plasma Version: 6.5.1 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.14.0-35-generic (64-bit) Graphics Platform: Wayland Memory: 16 GiB of RAM (15.6 GiB usable) Graphics Processor: NVIDIA GeForce GT 1030
The root cause is a KWin DRM enumeration failure: KWin rigidly attempts to access the non-existent /dev/dri/card0 and prematurely terminates the initialization sequence, failing to automatically fall back and utilize the correctly enumerated primary GPU device at /dev/dri/card1.
Nvidia specs and dynamics: The issue occurs under a stable system configuration with NVIDIA Proprietary Driver version 580.95.05, configured to prevent the creation of the legacy VESA framebuffer device. This configuration relies specifically on the nvidia-drm kernel module. Driver in Use: NVIDIA Proprietary Driver Version: 580.95.05; Configuration Parameter: the kernel parameter nvidia-drm.fbdev=0 is used; Resulting System State: the primary DRM device, /dev/dri/card0, is non-existent. The sole active GPU is correctly registered as /dev/dri/card1. KWin Failure (Core Bug): KWin (kwin_wayland) fails to initialize because its enumeration logic rigidly expects and fails on the missing /dev/dri/card0, instead of gracefully falling back and initializing with the available and correct /dev/dri/card1. Conclusion based on analysis: the KWin DRM backend logic should be reviewed to correctly handle the ENOENT error when probing a non-existent /dev/dri/card0 and continue the probe with the next available device (i.e., /dev/dri/card1).
Created attachment 186534 [details] content table
(In reply to proteus5 from comment #2) > KWin Failure (Core Bug): KWin (kwin_wayland) fails to initialize because > its enumeration logic rigidly expects and fails on the missing > /dev/dri/card0, instead of gracefully falling back and initializing with the > available and correct /dev/dri/card1. That is wrong, KWin lists card nodes with udev, nothing is hardcoded. This sounds to me more like a race condition between simpledrm and the proprietary driver initializing - similar problems have been hit before, see https://github.com/sddm/sddm/issues/1917 Tbh I'm not sure there's anything good that can be done about it on our side in the near future... but I would definitely recommend you just don't use that "optimization" that breaks your system.
Final Technical Details for Bug Report (English) The issue is definitively traced to an enumeration failure within the KWin DRM backend (kwin_wayland_drm) when the system is running the NVIDIA proprietary driver in a modern, clean configuration. A. Observed System State (Intentional Configuration): Driver: NVIDIA Proprietary Driver (Version: 580.105.08). Kernel Parameter: nvidia-drm.fbdev=0 is used to disable the creation of the legacy VESA framebuffer device. Result: The primary DRM device, /dev/dri/card0, is non-existent. The sole active GPU is correctly registered as /dev/dri/card1. B. KWin Failure Evidence (Core Bug): KWin fails to initialize because it attempts to open the first DRM device rigidly at /dev/dri/card0 and fails, despite the presence of /dev/dri/card1. Proof from user session log: nov 06 22:15:28 james-computer kwin_wayland[1360]: kwin_wayland_drm: failed to open drm device at "/dev/dri/card0" Conclusion: The KWin DRM backend logic must be updated to correctly handle the ENOENT error when probing a non-existent /dev/dri/card0 and continue the probe with the next available device (i.e., /dev/dri/card1), rather than aborting the session.
If you won't respond but rather continue commenting the same wrong things, then there's no sense in keeping this bug report open.
(In reply to Zamundaaa from comment #6) > If you won't respond but rather continue commenting the same wrong things, > then there's no sense in keeping this bug report open. The bug has been fixed?
*** Bug 512401 has been marked as a duplicate of this bug. ***