Bug 479659 - Cannot unlock the screen if mouse pointer is moved immediately after locking
Summary: Cannot unlock the screen if mouse pointer is moved immediately after locking
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: 5.92.0
Platform: Arch Linux Linux
: NOR grave
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: qt6
: 481150 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-01-11 18:00 UTC by Patrick Silva
Modified: 2024-05-06 14:15 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2024-01-11 18:00:50 UTC
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
Comment 1 fanzhuyifan 2024-01-12 03:46:29 UTC
Can confirm
Comment 2 fanzhuyifan 2024-01-12 03:54:21 UTC
changed component to powerdevil since support for 0s timeout was implemented there: https://invent.kde.org/plasma/powerdevil/-/merge_requests/301
Comment 3 fanzhuyifan 2024-01-12 04:41:10 UTC
For me this only happens on wayland.
Comment 4 fanzhuyifan 2024-01-12 05:47:51 UTC
Actually when this bug is triggered, I cannot even use Crtl-Alt-F3 to switch to virtual TTY.
Comment 5 Jakob Petsovits 2024-01-15 16:42:02 UTC
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.
Comment 6 Bug Janitor Service 2024-01-23 12:45:03 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5023
Comment 7 Vlad Zahorodnii 2024-01-23 20:10:31 UTC
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
Comment 8 Vlad Zahorodnii 2024-01-23 20:27:35 UTC
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
Comment 9 Nate Graham 2024-02-20 23:16:47 UTC
Unfortunately we have multiple new reports of this; re-opening.
Comment 10 Nate Graham 2024-02-20 23:16:54 UTC
*** Bug 481308 has been marked as a duplicate of this bug. ***
Comment 11 Nate Graham 2024-02-20 23:17:02 UTC
*** Bug 481150 has been marked as a duplicate of this bug. ***
Comment 12 Vlad Zahorodnii 2024-02-23 10:00:56 UTC
(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
Comment 13 Vlad Zahorodnii 2024-02-23 10:06:22 UTC
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.