After the screen has blanked and the session locked, input of password to unlock the session without first bringing up the password input text box fails because the first character of the password is not registered. STEPS TO REPRODUCE 1. In a plasma session, allow the screen to blank and the session to lock. 2. Without waking the screen, start to enter your password to unlock the session and press <RETURN> OBSERVED RESULT The screen is awakened as you start to enter the password but screen unlock fails because the first character of the password did not register. EXPECTED RESULT The screen is awakened as you start to enter the password and the screen unlocks on input of <RETURN>. This was the behaviour pre the 5.24.90 release. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.90 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.17.9-arch1-1 (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-8700 CPU @ 3.20GHz Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1080/PCIe/SSE2 Manufacturer: Notebook Product Name: P7xxTM1 System Version: Not Applicable ADDITIONAL INFORMATION The same result can be obtained by pressing <CTRL><ALT>L to lock the screen. On performing this action the lockscreen displays without the password input field being displayed. Entering the password immediately before the screen blanks causes the password input text box to be displayed but screen unlock fails because the first character of the password has not registered.
Can reproduce. Though I'm sure it worked fine when I did my refactors :/
Yet unsurprisingly bisect shows it's 3422348c5216078f598954c4b7c7e0fc902ce3b7
It's in onPromptForSecret: mainBlock.mainPasswordBox.text = ""; This happens after the key to wake the screen. Not sure how to fix nicely neatly without breaking the hypothetical multi-prompt case. Worst case we can just remove for now.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1754
*** Bug 454147 has been marked as a duplicate of this bug. ***
*** Bug 454328 has been marked as a duplicate of this bug. ***
Git commit 74a80aaac78647c51662ca58e43078ef681059c3 by Nate Graham, on behalf of David Edmundson. Committed on 24/05/2022 at 19:53. Pushed by ngraham into branch 'master'. Lock screen: Avoid wiping password field when getting our first prompt When the lockscreen is in the screensaver mode we want the keyboard key pressed to wake the screen to go to the password box textfield. This did work correctly, but a code path also reset it when we get the first prompt. In the (currently hypothetical) case of multiple prompts we would want to clear anything in the prompt. This uses the existing boolean flag to handle that appropriately. M +9 -4 lookandfeel/contents/lockscreen/LockScreenUi.qml https://invent.kde.org/plasma/plasma-workspace/commit/74a80aaac78647c51662ca58e43078ef681059c3
Git commit 2e923593c065fa646626c3059ebfa202f1b7530e by Nate Graham, on behalf of David Edmundson. Committed on 24/05/2022 at 19:53. Pushed by ngraham into branch 'Plasma/5.25'. Lock screen: Avoid wiping password field when getting our first prompt When the lockscreen is in the screensaver mode we want the keyboard key pressed to wake the screen to go to the password box textfield. This did work correctly, but a code path also reset it when we get the first prompt. In the (currently hypothetical) case of multiple prompts we would want to clear anything in the prompt. This uses the existing boolean flag to handle that appropriately. (cherry picked from commit 74a80aaac78647c51662ca58e43078ef681059c3) M +9 -4 lookandfeel/contents/lockscreen/LockScreenUi.qml https://invent.kde.org/plasma/plasma-workspace/commit/2e923593c065fa646626c3059ebfa202f1b7530e
*** Bug 454601 has been marked as a duplicate of this bug. ***
Today there is an update of plasma 5.24.90, certainly about screen lock feature. Result: manually or automatically when the screen is locked we get a message saying locking failed, please open a text console with Ctrl_Alt_F2 then login then execute "loginctl unlock-session 2" then etc.
I don't see any updates to Arch kde-unstable. I've manually applied the commit and it fixes the original problem and I'm not seeing your issue.
Indeed, it's up to your distro to backport all fixes, and there's no guarantee that happened in the update you got.
*** Bug 454784 has been marked as a duplicate of this bug. ***