https://bugs.kde.org/show_bug.cgi?id=316734
--- Comment #46 from Martin Flöser <mgraess...@kde.org> --- Based on comment #43 I read through the relevant code pieces for Wayland. On Wayland we ensure that when the screen is locked only the lock screen window or input method window should be visible (see https://invent.kde.org/plasma/kwin/-/blob/v5.22.4/src/composite.cpp#L608 ). As stated in comment #43 this seems to not work correctly. By investigating I found two smallish issues which might cause it: 1. There seems to be no full repaint triggered when the screenlocker reports to get locked. In the handler for the aboutToLock signal (see https://invent.kde.org/plasma/kwin/-/blob/v5.22.4/src/wayland_server.cpp#L604 ) a full repaint needs to be triggered. This would ensure that KWin stops rendering all windows before the lock screen gets shown. Thus the screen should turn black. (Please note that the code in Kscreenlocker needs to be adjusted as the emit happens before the lock state is changed to AcquiringLock. Maybe a dedicated signal is needed, see https://invent.kde.org/plasma/kscreenlocker/-/blob/v5.22.4/ksldapp.cpp#L380). 2. KWin reports the screen as fully locked once the window for the lock screen is registered (see https://invent.kde.org/plasma/kwin/-/blob/v5.22.4/src/wayland_server.cpp#L245 ). At that time it is not yet rendered, not yet even damaged. It is only created. The screenlocker immediately removes the inhibition and the system suspends (see https://invent.kde.org/plasma/kscreenlocker/-/blob/v5.22.4/ksldapp.cpp#L720 and https://invent.kde.org/plasma/kscreenlocker/-/blob/v5.22.4/ksldapp.cpp#L301 ). This needs to be changed to wait for a) surface fully damaged b) composition pass finished c) screen presented (e.g. drm frame callback) In combination these two issues can create a race condition where the screen stays in the content of the unlocked state. Still it is likely for many systems to not hit the issue. E.g. anything triggering a repaint between aboutToLock and Wayland window created will ensure the screen to go black. This can e.g. happen when clicking a button to suspend (the button release of the mouse will do) or when closing a notebook lid by triggering the common fake touchpad moves in these cases. This especially explains the pinephone case where the system is probably not put to lock through a pointer/touch event. The second issue explains why the problem came back. The code was written against the wl_shell interface and got migrated over the years to xdg_shell which is a more complex interface and needs more time to setup thus the too early removed inhibition is more likely to cause issues. Of course this is only for Wayland. For X11 we need other solutions which might be possible to reuse ideas from Wayland. -- You are receiving this mail because: You are watching all bug changes.
