STEPS TO REPRODUCE 1. open Energy Saving KCM 2. set "When locked, turn off screen" to "after 0 sec" 3. lock the screen and move the mouse pointer immediately, before the screen turns off OBSERVED RESULT the screen is on, password field and buttons are visible, but you cannot type the password, keyboard input has no effect. After the screen turns off, you can reactivate it and unlock it. EXPECTED RESULT the screen can be unlocked immediately after the provided steps SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.7.0 Graphics Platform: Wayland
Can confirm
changed component to powerdevil since support for 0s timeout was implemented there: https://invent.kde.org/plasma/powerdevil/-/merge_requests/301
For me this only happens on wayland.
Actually when this bug is triggered, I cannot even use Crtl-Alt-F3 to switch to virtual TTY.
Not sure what component was assigned initially, but I'll reassign to KWin because both DPMS and input functionality is located there. From a PowerDevil point of view, what happens (on Wayland) is: 1. When the screen locker gets activated (via OrgFreedesktopScreenSaverInterface::ActiveChanged signal), PowerDevil installs a 100ms KIdleTime timeout (increased from 0s to avoid weird behaviors). 2. Once the timeout triggers, PowerDevil sets keyboard backlight brightness to 0 and then calls KScreen::Dpms::switchMode(KScreen::Dpms::Off), which on Wayland asks KWin to please turn off the display. 3. Once input is detected (via KIdleTime::resumingFromIdle signal), the short 100ms KIdleTime timeout is removed and we instead install a longer 10s minimum timeout so the user has time to unlock their session. Also, keyboard brightness back to where it was before. None of these behaviors include grabbing input events directly, which makes me think that whichever race condition is exposed by this would be located closer to KWin. Perhaps KIdleTime, but on Wayland that also goes through KWin.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5023
Git commit bbb40a9a84200866872ea6726c3c070f279e59a1 by Vlad Zahorodnii. Committed on 23/01/2024 at 21:05. Pushed by vladz into branch 'master'. Fix lingering dpms input event filter after cancelling scheduled dpms mode change The output goes through the following stages when it changes its dpms mode: - Output::aboutToTurnOff()] - some time later, Output::dpmsModeChanged() to indicate that it's off - Output::dpmsModeChanged() to indicate that it's back on - Output::wakeUp() The Output::dpmsModeChanged() signals in the middle are optional. They may not be emitted after Output::aboutToTurnOff() if the user quickly cancels the dpms mode transition. The Workspace should monitor the Output::wakeUp() signal instead. Alternatively, create the dpms input event filter only after the dpms mode has changed. While the screen won't be turned back on immediately, it's still going to produce acceptable visuals. Either solution is fine. This patch makes the Workspace monitor the wakeUp signal because it takes fewer lines of code. M +1 -1 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/bbb40a9a84200866872ea6726c3c070f279e59a1
Git commit 424ba7d0fcbaf2105d7f19bfdc5be8d96902502f by Vlad Zahorodnii. Committed on 23/01/2024 at 21:25. Pushed by vladz into branch 'Plasma/6.0'. Fix lingering dpms input event filter after cancelling scheduled dpms mode change The output goes through the following stages when it changes its dpms mode: - Output::aboutToTurnOff()] - some time later, Output::dpmsModeChanged() to indicate that it's off - Output::dpmsModeChanged() to indicate that it's back on - Output::wakeUp() The Output::dpmsModeChanged() signals in the middle are optional. They may not be emitted after Output::aboutToTurnOff() if the user quickly cancels the dpms mode transition. The Workspace should monitor the Output::wakeUp() signal instead. Alternatively, create the dpms input event filter only after the dpms mode has changed. While the screen won't be turned back on immediately, it's still going to produce acceptable visuals. Either solution is fine. This patch makes the Workspace monitor the wakeUp signal because it takes fewer lines of code. (cherry picked from commit bbb40a9a84200866872ea6726c3c070f279e59a1) M +1 -1 src/workspace.cpp https://invent.kde.org/plasma/kwin/-/commit/424ba7d0fcbaf2105d7f19bfdc5be8d96902502f
Unfortunately we have multiple new reports of this; re-opening.
*** Bug 481308 has been marked as a duplicate of this bug. ***
*** Bug 481150 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #9) > Unfortunately we have multiple new reports of this; re-opening. Those bug reports seem to come for X11
The screen locker also receives mouse input and keyboard input, it just doesn't accept enter key for some reason. That's the opposite what this bug report is about.