Created attachment 189054 [details] Journalctl output since 2026-01-29 21:56:00 containing the title error SUMMARY Around two weeks ago, I first noticed an issue with the kscreenlocker that would leave me unable to log back into my user session after my screen locked due to inactivity. I am not 100% certain how to reproduce the bug, but when I manage to reproduce it, I end up in the situation where I can still type in characters into the lock screen password field, but I can't submit the password (pressing enter/clicking the submit button no longer works). STEPS TO REPRODUCE 1. Lock the screen (either manually or by user inactivity) 2. Type in an incorrect password and hit enter 3. Wait until the incorrect password animation is done and a new password can be entered 4. Type in the correct password and hit enter OBSERVED RESULT I am not logged back in. The password field remains filled, no animation plays, nothing happens - as if I hadn't pressed enter. EXPECTED RESULT The password should be checked and confirmed, and I should be back in my session. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.7-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 69 GB of RAM (67.1 GB usable) Graphics Processor: AMD Radeon RX 7900 XTX ADDITIONAL INFORMATION When this problem occurs, there is an error line in my journalctl that reads: Jan 29 20:02:42 Cre8or-PC kscreenlocker_greet[44136]: [PAM worker kde] Authentication attempt too soon. This shouldn't happen! I *think* this might be related to a recent change where there was an initial delay before the incorrect password animation (text field wiggles a few times) starts playing, which is no longer present. Currently the animation plays immediately, so I'm hypothesising that the reduced overall delay between password prompts causes the password field to reset too early, which causes the title error to appear in my journalctl.
Looking at the source code on the Github mirror, I see that there was a commit around a month ago (https://github.com/KDE/kscreenlocker/commit/5c2e6e1e877c1a0ecd915d4b91773cf9c56734e6) that introduced the error handling which raises this error message. It seems to involve moving the mouse around, which may be something that I have also been doing in my experiments. Maybe a good time to mention that I have a dual-monitor setup and sometimes enter my password on the left monitor, sometimes on the right (depending on where the text field happens to be in focus)?
I am also affected by this issue. My current workaround is to open tty and kill the running kscreenlocker_greet process. It will then respawn the kscreenlocker_greet automatically, and when switching back to the lock-screen, the unlock is working.
I believe I am also experiencing this issue. I am using Plasma 6.5.5 on a dual monitor setup on Wayland. I've been able to reproduce the issue consistently by first entering an incorrect password, then immediately moving the mouse to the other screen before the failure animation finishes playing (causing the controls to switch screens), which seems to cause the failure animation to freeze for around a second before returning to normal. After that, I can't submit passwords, either with the button or by pressing the enter key. Other controls on the lock screen seem to continue functioning normally.
I have found a way to reproduce this issue. 1. Lock the screen 2. Enter a wrong password, press Enter, press Escape within a second 3. The screen turns off 4. Enter any password, submit 5. The UI does not respond to Enter or the submit button I've identified two flaws that cause this. 1. The plasma-desktop QML triggers startAuthenticating() on every onUiVisibleChanged, including the transition to invisible. In my reproduction, this causes a rapid reattempt, which is then handled incorrectly. The graceLockTimer makes it impossible to trigger this with normal password submissions. This is good UX, but makes it hard to reproduce the bug. 2. The rapid reattempt is not handled correctly. The recently introduced return in PamWorker::authenticate() causes the flow to terminate without emitting any signal. PamAuthenticators has already transitioned to the Authenticating state, and only returns to Idle when it receives a failed() or succeeded() signal. Since neither is emitted, the state is permanently stuck at Authenticating, causing startAuthenticating() to silently reject all subsequent attempts. I have reproduced this with a single monitor. A multi-monitor setup could trigger the same issue, because onExited also sets uiVisible = false, triggering startAuthenticating() via onUiVisibleChanged. References: Newly introduced return: kscreenlocker, greeter/pamauthenticator.cpp:169, https://github.com/KDE/kscreenlocker/commit/5c2e6e1e877c1a0ecd915d4b91773cf9c56734e6#diff-bc041436d9ffc2f07acb68b28c8f7aaf0dadc9fefd37ab085116d83fd699991dR169 Unconditional startAuthenticating(): plasma-desktop, desktoppackage/contents/lockscreen/LockScreenUi.qml:136, https://github.com/KDE/plasma-desktop/blob/v6.6.0/desktoppackage/contents/lockscreen/LockScreenUi.qml#L136 onExited sets uiVisible = false: plasma-desktop, desktoppackage/contents/lockscreen/LockScreenUi.qml:146-147, https://github.com/KDE/plasma-desktop/blob/v6.6.0/desktoppackage/contents/lockscreen/LockScreenUi.qml#L146-L147
Brilliant! I can reproduce that 100% of the time. Since you've already dug into the code, would you be interested in submitting a merge request with a fix for the issue?
*** Bug 516746 has been marked as a duplicate of this bug. ***
I am able to reproduce it on Plasma 6.5.6 (Kubuntu 25.10) I don't see anything related in logs. To reproduce: 1. Lock the session 2. Wake the screen to show login dialog 3. Type wrong password 4. Press 'Enter' key or click `>` 5. Quickly press ESC before password error feedback happens 6. From this moment 'Enter' key and `>` button do not work Until the bug is fixed, here is a workaround: 1. Follow above instructions to "break" 'Enter' key and `>` button 2. Press 'Switch User' button 3. Press 'Other" button 4. Enter User/Pass 5. Press 'Enter' key or click `>` to resume the session
> Since you've already dug into the code, would you be interested in > submitting a merge request with a fix for the issue? Apologies for my late response. To be honest, I've been occupied and terrified. I have no idea what else I would be breaking, and I'm sure someone with project experience will have better insights than me.
I'm still able to reproduce this with Plasma built from git-master following the steps in comment #4
I think this is related, but a few times now waking up the system and the hitting enter or the login button basically does nothing. Last time both of my monitors didn't allow login (nothing happens clicking the button or enter). Previously I have also had it where it was frozen on one monitor but switching to the other allowed me to log in. When both lock up, I need to drop to a virtual terminal and manually unlock-sessions. My most recent occurrence (both screen frozen login): Operating System: Arch Linux KDE Plasma Version: 6.6.3 KDE Frameworks Version: 6.24.0 Qt Version: 6.10.2 Kernel Version: 6.19.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 32 GiB of RAM (31.3 GiB usable) Graphics Processor: AMD Radeon RX 6900 XT
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/312
Another way I managed to repro this 1. Lock the session 2. Wake the screen to show login dialog 3. Type wrong password 4. Press ESC so screen starts to dim 5. Now quickly press 'Enter' key or click `>`
Git commit d609004b642612d2052fe54af228dec364ed1e47 by Akseli Lahtinen. Committed on 14/04/2026 at 13:24. Pushed by akselmo into branch 'master'. PamAuthenticator: Emit failed on authentication attempts that happen too soon In cases where authentication attempt happens too soon, such as when user presses esc right after inserting wrong password, we need to emit the failed signal to set the state from being stuck in Authenticating to Failed. M +1 -0 greeter/pamauthenticator.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/d609004b642612d2052fe54af228dec364ed1e47
Git commit 093598fdf00d069e251cd891e26998df933cbfed by Akseli Lahtinen. Committed on 15/04/2026 at 16:39. Pushed by akselmo into branch 'Plasma/6.6'. PamAuthenticator: Emit failed on authentication attempts that happen too soon In cases where authentication attempt happens too soon, such as when user presses esc right after inserting wrong password, we need to emit the failed signal to set the state from being stuck in Authenticating to Failed. (cherry picked from commit d609004b642612d2052fe54af228dec364ed1e47) Co-authored-by: Akseli Lahtinen <akselmo@akselmo.dev> M +1 -0 greeter/pamauthenticator.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/093598fdf00d069e251cd891e26998df933cbfed