https://bugs.kde.org/show_bug.cgi?id=515786
Corbett <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #29 from Corbett <[email protected]> --- I'm seeing what looks like a related but distinct root cause on a custom Arch-based build (KDE Frameworks 6.27, Plasma 6.6.5, kernel 7.1.2, SDDM), and wanted to add a data point in case it's contributing to what's reported here. Symptom: SDDM authenticates successfully and hands off cleanly, but Plasma fails to come up — session dies with a black screen shortly after handoff, systemd shows the plasma-wayland/plasmashell unit exiting and restarting, consistent with the status=255/EXCEPTION behavior already noted in this thread. Working theory: rather than (or possibly in addition to) the xdg-activation/data_offer protocol race already discussed, this reproduces as a hardware-timing race at the DRM layer — SDDM initiates the handoff to the Plasma/KWin session before DRM/DRI has fully completed mode-setting and settled on the GPU. The session starts against a DRM state that isn't fully ready, and the resulting failure surfaces downstream as a plasmashell crash/restart, which would look identical in the logs to a protocol-level race even though the actual cause is earlier in the boot sequence. This would also explain the inconsistency several people in this thread have noted (crash doesn't always happen, sometimes recovers after a TTY switch, varies by GPU/driver) — a hardware-settling race is inherently timing- and hardware-dependent rather than deterministic. Fix in progress: I'm implementing a settle-check gate between SDDM's handoff and the Plasma session start — polling DRM/DRI readiness state before the session is permitted to start, rather than assuming a fixed delay is sufficient. Writing this to be hardware-agnostic (driver/vendor independent) so it isn't a workaround specific to one GPU. Expect to have a tested patch within a few days; will attach it here along with a coredumpctl backtrace from my own hardware once confirmed. -- You are receiving this mail because: You are watching all bug changes.
