https://bugs.kde.org/show_bug.cgi?id=524031
--- Comment #4 from Adam <[email protected]> --- Thanks for confirming, and for the LockOnResume test. Worth flagging that our triggers appear to be genuinely different rather than the same event. Suspend is disabled on this machine, so my occurrences can't be suspend/resume: $ journalctl -b | grep -iE "PM: suspend|Entering sleep state|suspend entry" (no output) $ systemctl status sleep.target suspend.target | grep -E "Loaded|Active" Loaded: masked (Reason: Unit sleep.target is masked.) Active: inactive (dead) Loaded: masked (Reason: Unit suspend.target is masked.) Active: inactive (dead) Every occurrence here has followed a screen lock and unlock. I also power both displays off physically at the switch rather than letting them blank, so the outputs genuinely disconnect and reconnect. If output removal and re-add is what suspend and that have in common, it might account for both paths into this state. One other difference: restarting plasmashell did not clear it for me. I tried that on an earlier occurrence and the desktop icons stayed dead. Killing the bridge is what worked, three times now. Not sure whether that means two failure modes or something about how my restart landed. Third shape capture, same result. The window reads identically in every field across all three samples, two broken and one working: window 0x1200008 geometry : 3840x2132+0+28 mapped : viewable input : XShapeGetRectangles(ShapeInput) -> count 0 bounding : 1 rectangle, 3840x2132+0+0 So the X11 input region is empty in both states and is not what distinguishes them. The geometry is the output height minus the panel strut, which lines up with input being swallowed across the work area specifically. This occurrence also rules out the startup path: the process was launched by hand mid-session rather than by the autostart unit at login, ran 19h37m, and went bad the same way. Killing it restored input again. -- You are receiving this mail because: You are watching all bug changes.
