https://bugs.kde.org/show_bug.cgi?id=525779
Joep Admiraal <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #8 from Joep Admiraal <[email protected]> --- I'm seeing the same on Plasma 6.6.6 (Ubuntu 26.04, Wayland, Dell Precision 5560, Intel + NVIDIA). The laptop panel eDP-1 and an LG 4K monitor over USB-C end up overlapping. I ran a script for six weeks that snapshots kwinoutputconfig.json, kscreen-doctor -o and the lid state on every output change (~450 snapshots). The data supports both suspicions from comment #2: the lid state goes wrong, and an overlap gets stored and is restored after that. 1) The overlap is written into the lid-open setup and comes back on every later hotplug. For this output combination, setup 2 has `lidClosed: false` and setup 3 has `lidClosed: true`: 2026-10-02 19:11 (before) setup 2: eDP-1 160,1271 DP-2 0,0 setup 3: eDP-1 107,1271 DP-2 0,0 2026-10-02 22:51 (after) setup 2: eDP-1 0,0 DP-2 0,0 <- overlap setup 3: unchanged Context of the 22:51 hotplug: - Fresh boot at 19:27, no suspend in between, lid open the whole time. - KWin picked the correct setup (lidClosed: false). - kwinoutputconfig.json was rewritten in the same second as the hotplug. - eDP-1 stayed at 0,0, which is where it sits when it is the only output, and the monitor got its stored 0,0. Every overlap I captured has this pattern. After that, every hotplug that used setup 2 restored the overlap, until I moved the panel back with kscreen-doctor. Editing the file doesn't help, because KWin rewrites it from memory within seconds (as in bug 517882). 2) The lidClosed: true setup is used while the lid is open. The two setups store different eDP-1 positions, so the live geometry shows which one KWin applied. Lid state read from /proc/acpi/button/lid/LID0/state: lid open: lidClosed:true setup 55x, lidClosed:false setup 24x lid closed: lidClosed:true setup 12x, lidClosed:false setup 1x Pattern over 15 boots: - After a fresh boot, KWin picks the correct setup. - Later in the same boot, after one or more lid close/open or suspend cycles, it switches to the lidClosed: true setup and almost never switches back before the next reboot. - In an affected session, with the lid open, the result is deterministic: kscreen-doctor output.eDP-1.position.300,1271 is written to the lidClosed: true setup and the lidClosed: false setup is left unchanged. - The internal panel stays enabled throughout, so only setup lookup and saving seem to use the wrong lid state. This also explains why the bug is intermittent. While KWin is on the wrong (lidClosed: true) setup, the corrupted lidClosed: false setup is hidden. The overlap showed up again after a reboot, once KWin was back on the correct setup. A user who closes and reopens the lid changes which setup is used, which fits comment #1. Bug 493879 (fixed in 6.4.5) covered findSetup() using the lid-closed setup while the lid is open, triggered by DPMS. That fix is in 6.6.6, so another path into that state seems to remain. Bug 517240 looks like the same problem as 1) on a desktop: positions reset to 0,0 and are then persisted. Attached: - kwinoutputconfig.json before (2026-10-02 19:11) and after (22:51) the overlap was written - bug525779-data.zip, containing: - events.log: timeline of all output changes since 2026-08-31, with the lid state for each - diag/20261002-*: both configs above, plus snapshot metadata - diag/20261013-090150-change/: full snapshot of the current overlap (kscreen-doctor -o and JSON, DRM connector state, config, KWin journal of the preceding 30 minutes) I have no KWin debug log of the moment the overlap was written. I'll try to run with QT_LOGGING_RULES="kwin_*.debug=true" and attach the log from the next occurrence. If there's a more specific logging category or a patch you'd like me to test, I'm happy to do so. -- You are receiving this mail because: You are watching all bug changes.
