SUMMARY Screen locking is broken on my KDE Plasma 6 system. Often, I can lock/unlock my screen exactly once, and subsequent attempts to lock (either manually, or auto-lock on screen timeout or suspend) causes a system lock-up. I notice two different behaviors: on Wayland, the screen will turn black and only the cursor will be visible (similar to https://bugs.kde.org/show_bug.cgi?id=483163). On X11 (my typical session), the system will appear to be working, but I cannot click on anything. Oddly, when in this "frozen" state, hovering over things that were active in the interface will cause them to be highlighted, but I can't click on them. Some notes from researching if this is the same as bug #483163: - Changing the theme to "Breeze Dark" does not appear to help (it does in #483163) - I cannot "blind" type in my password and press enter to unlock the screen and get access (this works in #483163) - switching to another TTY and back to tty2 does not fix/unlock the system (this was reported to workaround in #483163) STEPS TO REPRODUCE 1. Login to KDE Plasma (X11 or Wayland) 2. Lock the screen with Meta+L and then unlock 3. Lock the screen again OBSERVED RESULT The system is "hung" and cannot be recovered without rebooting from another tty EXPECTED RESULT Lock screen window correctly drawn. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.6.37-1-lts (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620 Manufacturer: LENOVO Product Name: 20KHCTO1WW System Version: ThinkPad X1 Carbon 6th ADDITIONAL INFORMATION This is similar to https://bugs.kde.org/show_bug.cgi?id=483163, but not exactly the same. I would also like to know if there's some CLI command to unlock the system, which would allow me to workaround this without a hard reboot. `logingctl unlock-session` does not appear to do anything. I would also be happy to provide any debugging information needed. I do not see anything of relevance when this occurs in journalctl.
I meant to add that this problem does not *always* occur, but I have not quite tracked down when/why it doesn't.
I did finally figure out that I can work around this by jumping to a TTY and killing `kscreenlocker_greet`, which then auto-restarts and I can unlock my session as normal when switching back to TTY2
I believe this person is having the same issue: https://discuss.kde.org/t/kscreenlocker-freezes-and-have-to-be-killed/15096
if I've understood you correctly, it seems this issue is recoverable via ctrl+alt+F[1-7]? (i'm hunting for existing bugs related to this, but a hard freeze - even capslock wont toggle its LED).
(In reply to Tim D from comment #4) > if I've understood you correctly, it seems this issue is recoverable via > ctrl+alt+F[1-7]? > > (i'm hunting for existing bugs related to this, but a hard freeze - even > capslock wont toggle its LED). Yes, I was still able to switch to a virtual tty when the system was locked (more of a soft freeze). This appears to have been resolved in either an update or configuration change, as I haven't had it happen in a couple of weeks, so I'll close this for now.