https://bugs.kde.org/show_bug.cgi?id=490040
Leo Shchurov <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #20 from Leo Shchurov <[email protected]> --- Created attachment 194325 --> https://bugs.kde.org/attachment.cgi?id=194325&action=edit Raw system log I encountered the same intermittent login failure on Plasma 6.7.1. This is not triggered by monitor power-cycling, it occurs for me immediately after a cold boots, always on my primary display. I captured a detailed startup trace showing plasmashell starting before KScreen applies the saved three-monitor layout, the affected primary output is configured last. Restarting plasmashell after the layout stabilizes restores the desktop. I tried to see if AI can help investigate too, below is the summary that I trimmed down. I've also attached relevant journal logs. AI summary below -------------------------------------------------- # KDE Plasma X11 multi-monitor black desktop startup trace Date observed: 2026-07-15 AEST Host: `main-pc` Likely upstream report: KDE Bugzilla 490040 ## Symptom After a cold boot into Plasma X11, the primary/middle monitor (`DP-4`) displayed windows and its panel normally, but the Plasma desktop surface itself was black and its Folder View icons were absent/non-interactive. The other two monitor desktops rendered normally. `plasmashell` remained running; it did not crash. Restarting only `plasma-plasmashell.service` after the display layout was stable immediately restored the affected wallpaper, Folder View icons, and desktop interaction without restarting the X session or user applications. ## System - NixOS 26.11 (Zokor) - KDE Plasma / KWin X11 6.7.1 - KDE Frameworks 6.27.0 - Qt 6.11.1 - Kernel 7.1.1 - NVIDIA GeForce RTX 3090, proprietary driver 610.43.02 - X11 session - Three identical 2560x1440 displays at approximately 120 Hz Stable layout: - `DP-0`: `2560x1440+0+0` - `DP-4`: `2560x1440+2560+0`, primary and affected - `DP-2`: `2560x1440+5120+0` ## High-resolution startup timeline All timestamps are from the same boot and use journal microsecond precision. | Time | Event | |---|---| | 08:43:15.595059 | systemd begins `plasma-plasmashell.service` (`Starting KDE Plasma Workspace`) | | 08:43:15.780662 | systemd reports plasmashell service started | | 08:43:16.029876 | systemd begins `plasma-kscreen.service`, about 435 ms after plasmashell startup began | | 08:43:16.111236 | systemd reports KScreen started | | 08:43:16.618034 | KScreen begins applying the saved 7680x1440 XRandR layout | | 08:43:16.622919 | KScreen configures `DP-0` at `(0,0)` | | 08:43:16.775797 | KScreen configures `DP-2` at `(5120,0)` | | 08:43:16.903861 | KScreen configures affected primary `DP-4` last, at `(2560,0)` | | 08:43:17.096772 | KScreen reports `XRandR::setConfig done!` | | 08:43:17.659911 | KScreen emits `configChanged()` | | 08:43:21.182575 | plasmashell begins a burst of `No QSGTexture provided from updateSampledImage(). This is wrong.` messages while desktop surfaces are being rendered | During the original live diagnosis, before KScreen completed, `DP-0` and `DP-4` were briefly observed at the same origin. The retained journal proves the later per-output placement sequence but does not itself contain a pre-apply `xrandr` snapshot. The key ordering fact is independently preserved in the journal: plasmashell starts and is considered active before KScreen starts and applies the final per-monitor coordinates. The affected primary output is the final CRTC KScreen repositions. ## Recovery comparison At 20:44, with the monitor layout already stable, only plasmashell was restarted: | Time | Event | |---|---| | 20:44:51.710876 | systemd begins stopping plasmashell | | 20:44:52.495072 | plasmashell stopped | | 20:44:52.497841 | systemd begins starting plasmashell | | 20:44:55.697055 | plasmashell started after the configured three-second pre-start delay | The middle desktop then rendered correctly. The three recovered X11 desktop windows advertise these geometries: - `Desktop @ QRect(0,0 2560x1440)` - `Desktop @ QRect(2560,0 2560x1440)` - `Desktop @ QRect(5120,0 2560x1440)` The same QSG texture warning also occurs transiently during the successful restart, so that warning is correlated with surface setup but is not sufficient on its own to distinguish the failed state. ## Interpretation The evidence is consistent with a Plasma X11 startup race: 1. plasmashell creates per-screen desktop surfaces against the initial XRandR output state; 2. KScreen subsequently applies saved coordinates and primary-output priorities; 3. one desktop containment/window—here the primary output configured last—fails to remap or repaint correctly; 4. recreating plasmashell after KScreen stabilizes produces all three correct desktop windows. This is stronger than a generic “black screen” report because it provides the exact service ordering, each XRandR placement timestamp, the affected output, and a controlled recovery comparison. ## What this trace cannot provide retrospectively There is no crash stack trace because plasmashell stayed alive and the original process has since been restarted. The current journal cannot reconstruct internal QML scene-graph object state that was not logged at the time. If the failure returns, additional evidence can be captured before restarting plasmashell: - live `xrandr --query`, `xrandr --listmonitors`, and `_NET_WM_WINDOW_TYPE_DESKTOP` window geometries; - a screenshot of the affected desktop window; - targeted Plasma/Qt logging enabled before login; - an all-thread debugger backtrace of the still-running plasmashell for comparison with the healthy state (possibly limited value because the process is responsive); - a pre-Plasma and post-KScreen XRandR snapshot service, which would remove the one remaining gap in this timeline. Wrapping plasmashell in broad `strace`/`rr` from login is possible but is not the first recommendation: it would generate very large traces and could alter startup timing enough to hide the race. -------------------------------- End AI summary -- You are receiving this mail because: You are watching all bug changes.
