SUMMARY If I run "Unlock screen" via KDE connect/ssh the lock screen freezes for exactly 5 seconds (the clock stops, seconds freeze) and then the screen unlocks. If the mouse is moved during those 5 seconds the screen turns black. STEPS TO REPRODUCE 1. Lock 2. Run "Unlock screen" via KDE connect OBSERVED RESULT Lockscreen freezes and unlocks after 5 seconds EXPECTED RESULT It should unlock immediately SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20250626 KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.15.3-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5700X 8-Core Processor Memory: 32 GiB of RAM (31.3 GiB usable) Graphics Processor: AMD Radeon RX 6650 XT Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C56 System Version: 2.0 ADDITIONAL INFORMATION Started with 6.4
Thanks for the bug report. I'm sorry we weren't able to respond before now. I'm not able to reproduce this, attempting to unlock a machine running Plasma built from git-master, using KDE Connect on another machine I'm also not able to reproduce this when trying to unlock a machine running Plasma 6.4.5 If you're still experiencing this bug, can you attach system logs from the machine that's being unlocked - from just before and until just after the unlock attempt? Thanks.
Hi, the delay is now about ~2 seconds, originally it was exactly 5 (Plasma 6.4.5 now) Logs when delay occurs: Oct 02 22:24:49 openSUSE kdeconnectd[2135]: new capabilities for "Galaxy S24 FE" Oct 02 22:24:49 openSUSE kdeconnectd[2135]: kdeconnect.plugin.battery: No Primary Battery detected on this system. This may be a bug. Oct 02 22:24:49 openSUSE kdeconnectd[2135]: kdeconnect.plugin.battery: Total quantity of batteries found: 1 Oct 02 22:24:49 openSUSE kdeconnectd[2135]: kdeconnect.plugin.battery: Primary Battery seems to have been removed. Suspending packets until it is reconnected. Oct 02 22:24:49 openSUSE kdeconnectd[2135]: kdeconnect.plugin.clipboard: Ignoring clipboard without timestamp Oct 02 22:24:51 openSUSE kscreenlocker_greet[73530]: pam_kwallet5(kde:auth): pam_kwallet5: Empty or missing password, doing nothing Oct 02 22:24:51 openSUSE unix_chkpwd[73773]: password check failed for user (user) Oct 02 22:24:51 openSUSE kscreenlocker_greet[73530]: pam_unix(kde:auth): authentication failure; logname=user uid=1000 euid=1000 tty= ruser= rhost= user=user Oct 02 22:24:58 openSUSE systemd[1511]: Started Konsole - Terminal. How to reproduce: 1. Meta + L 2. Move the mouse so the password input field appears 3. Run unlock via KDE connect 4. Observe frozen screen/black screen if mouse is moved Important: this does not happen without step #2
Can reproduce with step 2 included
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/296
Git commit 5c2e6e1e877c1a0ecd915d4b91773cf9c56734e6 by David Edmundson, on behalf of Fushan Wen. Committed on 12/12/2025 at 19:09. Pushed by davidedmundson into branch 'master'. greeter: fix hanging when unlocking via loginctl over KDE Connect `fail_delay` used to sleep in the thread, which blocks the screen locker from quiting when another unlock attempt succeeds. This records the next attempt allowed time point in each worker and checks it in `PamWorker::authenticate()` to make sure a previous failing worker doesn't affect other successful attempts to unlock the screen. How to reproduce: 1. Meta + L 2. Move the mouse so the password input field appears (IMPORTANT) 3. Run unlock via KDE connect 4. Observe frozen screen/black screen if mouse is moved Related: bug 505987 FIXED-IN: 6.5.4 M +13 -4 greeter/pamauthenticator.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/5c2e6e1e877c1a0ecd915d4b91773cf9c56734e6
Git commit b4f2195ecbfa4bee36ade689c7f24d9dde300dbd by Fushan Wen. Committed on 13/12/2025 at 03:02. Pushed by fusionfuture into branch 'Plasma/6.5'. 🍒greeter: fix hanging when unlocking via loginctl over KDE Connect `fail_delay` used to sleep in the thread, which blocks the screen locker from quiting when another unlock attempt succeeds. This records the next attempt allowed time point in each worker and checks it in `PamWorker::authenticate()` to make sure a previous failing worker doesn't affect other successful attempts to unlock the screen. How to reproduce: 1. Meta + L 2. Move the mouse so the password input field appears (IMPORTANT) 3. Run unlock via KDE connect 4. Observe frozen screen/black screen if mouse is moved Related: bug 505987 FIXED-IN: 6.5.5 (cherry picked from commit 5c2e6e1e877c1a0ecd915d4b91773cf9c56734e6) Co-authored-by: Fushan Wen <qydwhotmail@gmail.com> M +13 -4 greeter/pamauthenticator.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/b4f2195ecbfa4bee36ade689c7f24d9dde300dbd