Created attachment 193678 [details] KWin X11 diagnostic bundle: service status, current-boot KWin journal excerpts, prior kwin_x11 coredump summaries/details, and NVIDIA/DRM kernel log excerpts I selected the multi-screen component because this is an X11 triple-monitor issue; the output configuration component appears to be marked Wayland-only. === DESCRIPTION After cold boot and login, my triple-monitor Plasma X11 session sometimes comes up with the display layout/sizing wrong. Logging out and back in, or restarting KWin, can restore the correct layout. This appears separate from Bug 521954 / the resolved logout teardown crash. The linked fixes for that bug appear to address shutdown/teardown ordering and RenderLoop/workspace lifetime issues. My remaining problem happens at cold boot/login/display initialization. SYSTEM Fedora 44 KDE Plasma X11 session kwin-x11-6.7.0-1.fc44.x86_64 NVIDIA driver 595.80 Triple-monitor setup with mixed refresh rates SYMPTOM On cold boot/login, display layout/sizing can be wrong. After logout/login or KWin restart, the layout can recover. RELATED LOG EVIDENCE On a prior event, kwin_x11 produced SIGABRT coredumps. On a later boot, plasma-kwin_x11.service stopped/restarted and logged OpenGL context cleanup warnings such as: Could not delete render time query because no context is current Could not delete framebuffer because no context is current In that later event, KWin restarted successfully as /usr/bin/kwin_x11 --replace. NOTES I am filing this separately because the main symptom is cold-boot/login display initialization, not a logout/shutdown teardown crash. If this belongs under the existing resolved bug instead, please let me know.
Does the issue only happen on X11, or does it happen on Wayland too?
Created attachment 193755 [details] Clean cold boot directly into Plasma Wayland I did a clean cold boot directly into Plasma Wayland. The issue does reproduce on Wayland, so it is not X11-only. In the Wayland cold-boot test, the bad display state appeared on a side monitor rather than the center monitor. A normal graphical logout/login back into Wayland restored the displays, similar to the recovery behavior I see on X11. I captured the recovered Wayland state after logout/login and attached the logs for comparison.
Created attachment 193756 [details] Recovered Wayland logout/login logs after display layout returned to normal Follow-up for the Wayland test: I previously attached the logs from the bad cold-boot Plasma Wayland state. After that, I performed a normal graphical logout and logged back into Plasma Wayland. The displays returned to the correct layout after logout/login, matching the recovery behavior I see on X11. I am attaching the recovered Wayland logout/login logs for comparison. This bundle contains: - session-info - kscreen-doctor -o - drm_info - KWin supportInformation - user journal excerpts - kernel NVIDIA/DRM excerpts So the current behavior is: - Cold boot directly into Plasma Wayland: issue reproduces - Logout/login back into Plasma Wayland: display layout recovers - Therefore, this does not appear to be X11-only.
Thanks for the info!
• That pattern narrows the problem considerably. The logs confirm: - First Wayland session started at 12:57:56. - You logged out at 12:58:14; its KWin process stopped cleanly. - Second session started at 12:58:26 and produced the correct three-monitor layout. - The crash at that transition was SDDM’s greeter compositor (uid 983), not your active desktop compositor. - Your current KWin session has remained running normally. Assessment: - Fedora base system: stable. - NVIDIA compute path: stable. - KWin after relogin: currently stable. - Cold-boot first-login display initialization: not stable. - Because it occurs under both X11 and Wayland, the likely fault is shared NVIDIA DRM/SDDM/KScreen initialization—not Wayland alone.
I reviewed KWin MR 9443, referenced as the Plasma 6.7.2 fix for Bug 521909. That MR addresses RenderLoop/workspace and EGL teardown during compositor shutdown. It does not modify output discovery, KScreen configuration, DRM modesetting, framebuffer initialization, or cold-boot startup ordering. My remaining issue occurs during first-login initialization before any logout, and the bad and recovered kscreen-doctor -o outputs are logically identical. Therefore MR 9443 may fix the associated logout crash, but it does not appear to address this report’s visible cold-boot output corruption. I will still retest 6.7.2 for confirmation. MR 9443 fixes My remaining issue ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Crash during KWin shutdown/logout Wrong rendering after cold boot/first login ───────────────────────────────────────── ───────────────────────────────────────────────────────── Missing workspace() guard in RenderLoop Logical output configuration is already correct ───────────────────────────────────────── ───────────────────────────────────────────────────────── Compositor teardown ordering Visible output differs despite identical geometry/modes ───────────────────────────────────────── ───────────────────────────────────────────────────────── EGL context destruction Logout/login rebuilds working display state The key commit explicitly says: “At shutdown, the compositor is destroyed after the workspace…” None of MR 9443’s six changes touches: - DRM connector discovery - Output geometry or modes - KScreen configuration application - Initial framebuffer setup - Multi-monitor startup ordering - NVIDIA display initialization
Quick clarification before I retest Fedora’s Plasma/KWin 6.7.2 packages: The Plasma 6.7.2 release notes mention the VRR/multi-monitor KWin crash fix for Bug 521909. Is that fix expected to also address this separate cold-boot/login output-layout issue in Bug 522149, or should I treat 522149 as still separate and simply report back after testing 6.7.2? https://blogs.kde.org/2026/06/27/this-week-in-plasma-post-6.7-bug-fixing/ I’m not asking for an immediate diagnosis — just trying to avoid confusing the two issues.
Created attachment 194167 [details] Journal snippet capturing the rapid client.platformscreens geometry loop and QRect shifting at 08:32:33 during cold boot initialization. I am attaching a snippet of my user journal (Boot_Log_1.md) capturing the exact moment the layout corruption occurs during initialization. As you can see in the timestamps around 08:32:33, the compositor is getting trapped in a rapid, infinite geometry renegotiation loop. client.platformscreens is repeatedly firing screen update notifications and shifting the QRect canvas coordinates back and forth within the exact same second. It looks like a race condition where KWin is attempting to map the multi-monitor workspace boundaries before the proprietary NVIDIA driver has fully completed its DRM modesetting handshake with the high-refresh Blackwell hardware, causing the initial layout discovery to fail out of exhaustion.
I found the root cause and this can be closed as a local hardware/topology issue rather than a KWin bug. One of my monitors was connected through an HDMI source-switching/splitter-type device so I could switch between machines, and that same monitor also had another direct cable/source path involved. In other words, my display topology was more complicated than I realized. During cold boot, the GPU/KWin/KScreen stack was likely seeing confusing or unstable monitor/EDID/source information from that setup. After simplifying/removing that switching path and correcting the monitor cabling, the issue no longer appears to reproduce. The cold-boot display layout now initializes correctly. I apologize for the noise, and I sincerely appreciate the time spent looking at this — especially the triage around whether this was distinct from the logout/shutdown teardown issue, and the request to test Wayland. That helped me narrow the problem down. Thank you to Nate, Vlad, Xaver, David, and everyone else copied here. Please close this as a local configuration/hardware issue / not a KWin bug.
I found the root cause, and this can be closed as a local hardware/display-topology issue rather than a KWin bug. One of my monitors was connected through an HDMI source-switching / splitter-type device so I could switch between machines. That same display topology also involved another direct cable/source path, which means the GPU/display stack was likely seeing confusing or unstable monitor/source information during cold boot. After simplifying the monitor cabling and removing that switching path from the affected setup, I have now tested multiple cold boots over the last several days. The display layout initializes correctly, and the issue no longer reproduces. I have also switched from X11 to Wayland on Fedora 44, and Wayland is now working properly with this corrected cabling setup. I apologize for the noise, and I sincerely appreciate the time spent looking at this — especially the distinction between this report and the logout/shutdown teardown issue, and the request to test Wayland. That helped me narrow this down. Thank you to Nate, Vlad, Xaver, David, and everyone else copied here. Please close this as a local hardware/configuration issue / not a KWin bug.
I need to correct my previous closure comment. I suspected the HDMI source switch was the cause and removed it, but the issue has reproduced again with the switch completely removed. The original symptom remains: cold boot can produce an incorrect visible output state while kscreen-doctor reports correct geometry. Logout/login restores the displays.
Created attachment 194222 [details] Wayland bad-state diagnostic bundle captured during active triple-monitor display corruption. Contains kscreen-doctor output, drm_info output, and journal excerpts collected before logout/login recove Fresh diagnostic bundle captured while the triple-monitor output corruption was actively occurring on Fedora 44 KDE Plasma Wayland with NVIDIA RTX 5080. This archive contains kscreen-doctor output, DRM information, and user/system journal excerpts collected before logout/login recovery. The purpose is to compare the bad display state against the recovered state and investigate cold-boot/login output initialization behavior.
Created attachment 194223 [details] X11 bad-state diagnostic bundle after Wayland logout/login: kscreen-doctor, xrandr, drm_info, session info, and journal excerpts captured while output corruption was active. Additional follow-up: After attaching the earlier Wayland bad-state bundle, I tested logout/login again. In Plasma Wayland, logout/login did not fully recover the display state this time. The visible corruption remained, with the affected output changing. I then logged out and switched to Plasma X11. The issue still reproduced there as well, but the visible corruption appeared on different outputs. This suggests the problem is not Wayland-only or X11-only. The HDMI switch/source-switching device remains removed from the setup. Current connections are direct from GPU to monitors. I am attaching a new X11 bad-state diagnostic bundle captured before reboot/recovery. It includes: * session info * kscreen-doctor output * xrandr output * drm_info output * user journal excerpts * system journal excerpts The key observation remains: the logical output configuration can appear correct while the physical rendered output is visibly cropped/offset on one or more monitors.
Created attachment 194375 [details] Issue visual I’m also facing the same issue exactly as described in OP. Picture attached of how the issue manifests.