Summary: | Cannot unlock the screen if mouse pointer is moved immediately after locking | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Patrick Silva <bugseforuns> |
Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | grave | CC: | agurenko, fanzhuyifan, jpetso, markcapella, me, natalie_clarius, nate, null, pmargeti34 |
Priority: | NOR | Keywords: | qt6 |
Version: | 5.92.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/424ba7d0fcbaf2105d7f19bfdc5be8d96902502f | Version Fixed In: | 6.0 |
Sentry Crash Report: |
Description
Patrick Silva
2024-01-11 18:00:50 UTC
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. |