https://bugs.kde.org/show_bug.cgi?id=527082
Bug ID: 527082
Summary: kwin_wayland_drm loses DRM master ("Permission
denied") and fails to reopen render node on VT switch,
freezing display while input/audio keep running
Classification: Plasma
Product: kwin
Version First unspecified
Reported In:
Platform: Kubuntu
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Alles in das „Comments"-Feld:
ENVIRONMENT
KWin: 6.6.6 (Kubuntu 26.04.1 "Resolute Raccoon")
Kernel: 6.19.8-surface-3 (linux-surface patched kernel)
GPU: Intel Iris Graphics 540 (Skylake GT3, Core i7-6650U), i915/Mesa
Session type: Wayland
SUMMARY
When switching away from and back to the graphical VT (e.g. to a text
console and back) while a Plasma Wayland session is active, kwin_wayland's
DRM backend intermittently fails to reacquire DRM master / fails to reopen
the render node. The screen freezes (last rendered frame stays on screen),
and mouse/keyboard input stop being processed by the compositor, while audio
and the kernel-level VT switch itself keep working. Switching to a text
console and back a second time reliably recovers the session.
STEPS TO REPRODUCE
1. Start a Plasma Wayland session.
2. Run any GPU-accelerated client (observed with vdr-sxfe using its OpenGL2
xine video output, but this may not be required - see NOTES).
3. Switch to a text VT (e.g. Ctrl+Alt+F3) and back to the graphical VT
(Ctrl+Alt+F1/F2).
4. Observe the graphical session.
OBSERVED RESULT
- The display freezes on the last rendered frame.
- Mouse and keyboard input are not processed by the Plasma session
(the VT-switch shortcut itself still works, since that's handled by the
kernel, not by KWin).
- Audio playback is unaffected (confirms the kernel/session is alive and
the stall is specific to KWin's DRM backend/rendering, not a full hang).
- journalctl shows (exact timestamps, bracketing "fbcon: Taking over
console" from the kernel):
kwin_core: Failed to find a working output layer configuration! Enabled
layers:
kwin_core: src KWin::RectF(0,0 2736x1824) -> dst KWin::Rect(0,0 2736x1824)
kwin_wayland_drm: drmModeListLessees() failed: Keine Berechtigung
(Permission denied)
kwin_wayland_drm: Atomic modeset test failed! Keine Berechtigung
(Permission denied)
kwin_core: Applying output configuration failed!
kwin_core: Failed to open /dev/dri/renderD128 device (No such device)
kwin_wayland_drm: Failed to open drm device /dev/dri/renderD128
At the exact same timestamp, org_kde_powerdevil logs permission errors on
unrelated devices (/dev/i2c-4 through /dev/i2c-9 "lacks R/W permissions"),
and wireplumber/plasmashell report a Bluetooth audio sink disappearing
("No object for name bluez_output.<MAC>.1"), suggesting the whole device
ACL set for the newly-activated session is briefly inconsistent/incomplete
at this moment, not something DRM-specific.
- No GPU hang/reset is logged by the i915 kernel driver at this time, so
this is not a GPU engine hang - purely a userspace permission/master
handoff issue during VT/session reactivation.
- Recovery: switching to the text console and back a second time makes the
session functional again (forces a fresh master acquisition).
EXPECTED RESULT
KWin's DRM backend should reliably reacquire DRM master and reopen its
render node on VT reactivation without a manual extra VT-switch cycle, and
without a window where output configuration/atomic modeset fails.
NOTES
- This looks closely related to existing reports of the same
"Atomic modeset test failed! Permission denied" / "drmModeListLessees()
failed: Permission denied" pattern on VT switch / session reactivation,
reported independently on AMD and NVIDIA as well, which suggests the
underlying race is in the shared KWin DRM backend / systemd-logind
device handoff path (see systemd issue #23547), not vendor-specific.
- On a second machine (AMD iGPU, same Kubuntu 26.04.1, same KWin 6.6.6,
same systemd 259.5-0ubuntu3.4, stock Ubuntu kernel instead of
linux-surface) this has not been observed, suggesting the race window is
much easier to hit with this kernel/driver's device pause/resume timing,
but the code path itself is shared.
- Possibly relevant/related reports:
-
https://discuss.cachyos.org/t/kwin-drm-master-loss-and-powerdevil-crash-on-lock-screen-vt-switch-amdgpu/29086
- https://github.com/systemd/systemd/issues/23547
- https://bugs.kde.org/show_bug.cgi?id=501073
--
You are receiving this mail because:
You are watching all bug changes.
