| Summary: | screenlocker: when screens are off, the key pressed to wake the screens is "lost" and not treated as part of the password | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | fawz |
| Component: | Screen locking | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kdedev, olib141 |
| Priority: | NOR | ||
| Version First Reported In: | 6.5.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
fawz
2026-02-11 16:46:56 UTC
I can reproduce this on Plasma built from git-master. When the screen is off, the first character I type brings up the SDDM background, but not the password input. The second character typed is entered into the password input. I am not entirely sure that this is unexpected. If, for instance, you were logged in and had a text editor open, and the screen turned off, you would expect to press a key to wake the screen without having it entered into the application. The same blocking (or, event consumption) is applied to mouse click, but not mouse movement (or perhaps, only the first tiny mouse movement which is effectively unnoticeable). Pursuant to my rationale above, I'm marking this as RESOLVED INTENTIONAL. We won't change this exclusively for kscreenlocker (or PLM which now has the same behaviour). It may be the case that some people expect the first input to not be consumed for waking the screen and to go to applications anyway, so I think a feature request bug could be opened for the behaviour in general. I believe KWin is responsible for this. (In reply to Oliver Beard from comment #2) > I am not entirely sure that this is unexpected. This directly contradicts what Nate had said in the other report as well as in a feature request to reject the first character entered https://bugs.kde.org/show_bug.cgi?id=514945 > This is a feature request to add a configuration option to reject keypresses on screen locker if the password entry is not visible. That was rejected, therefore this is a bug. Respectfully, I'm reopening this. . After re-reading the two reports, and some discussion with maintainers, the main difference between this and 514945 is 514945 - The screen is already awake, key presses go directly to the password input. This is expected This report - The screen is asleep, the first key press wakes the screen, the rest of the key presses are sent to the password input. This is also expected. My apologies for the confusion, I'll close this back out. I'm not sure I understand, apologies if I'm being dense. According to https://bugs.kde.org/show_bug.cgi?id=472319 this behavior is not intentional, right? It seems to involve waking the screen, not just the input field being invisible/inactive. Also, when switching from wayland to X11 the behavior is different. In other words, using X11, when I lock the screen, press escape to blank it the first character I press both wakes/unblanks the screens *and* is used as the first character to the password input field. Is this behavior (which is new from my POV coming for X11) expected due to technical limitations around wayland, or is it expected because the UX is as expected? I'm just one user, but this change means that I need to wait 5-10 seconds before I can log in whereas before I could simply start typing my password and be logged in when the screens finished waking up. At least one of my screens is quite slow to wake. I believe in 472319 Nate mistakenly thought it referred to showing the prompt rather than waking the screen.
> this change means that I need to wait 5-10 seconds before I can log in whereas before I could simply start typing my password and be logged in when the screens finished waking up
That shouldn't be the case, input should be accepted immediately following a single key press.
> That shouldn't be the case, input should be accepted immediately following a single key press.
right, I could probably press a random key and then immediately start typing the password without waiting for my screens to wakeup.
But, does this mean that the behavior on X11, where the key used to wake the screens also works as the first key in the password, was never intentional? Is this now marked fixed because the X11 behavior was considered a bug, and the wayland behavior is considered the fix?
Is this considered intentional because when the screens are off we want to treat keyboard input identically regardless of whether there's a screenlocker or text editor active on the desktop? In my book those two use-cases are not the same, even if I understand wanting to treat them the same for technical reasons.
Oh well, if this is intentional it makes me a bit sad, but maybe I just need to get used to the new way this works. At the end of the day it's a user experience decision and if this is the desired UX then I will have to adapt.
|