SUMMARY With a Plasma 6 session compiled using kdesrc-build, if the screen locks automatically but I move the mouse within the "Allow unlocking within password" time period the screen will either freeze after unlocking or just go black, and when that happens I have to use the `loginctl unlock-session` command from another TTY. So far it appears that the screen locker only does that after I've locked the session manually and/or I've suspended the system at least once, the problem doesn't occur on a fresh reboot. The problem also doesn't occur if I move the mouse after the grace period, and disabling that grace period completely also works around the problem. STEPS TO REPRODUCE 1. Set up the system to lock automatically after 1 minute and allow unlocking without a password for 10 seconds (optional for easier testing) 2. Wait until the screen locks automatically 3. Move the mouse within 10 seconds (or under whatever time is set for the unlock without password setting) OBSERVED RESULT The screen is not properly unlocked, and the session is inaccessible without using the `loginctl unlock-session` command. EXPECTED RESULT The screen should unlock without asking for a password. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.240.0 Qt Version: 6.6.0 Kernel Version: 6.5.9-arch2-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 6800H with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics ADDITIONAL INFORMATION kscreenlocker is at commit 6777145016231427cccb4721de1e469a1512715c when I compiled it. The logs look the same as a manual unlock, except for the authentication failure message from bug 465266.
This is also reproducible on a fresh Neon Unstable 20231107-1001 install in a QEMU/KVM VM on Wayland (without updates since there's a dependency issue at the moment, although coincidentally the problem there is libkscreenlocker6 having an unmet plasma-framework6 dependency).
Can reproduce the issue as described with 100% reliability. Possibly relevant-looking console logs: Nov 08 14:34:37 Liberator kwin_wayland[1994]: kwin_wayland_drm: atomic commit failed: Invalid argument Nov 08 14:34:37 Liberator kernel: i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID 50 Nov 08 14:34:36 Liberator kernel: [00] BAD 1e 00 00 00 00 00 fd fd 00 32 32 3c 1e 1e 50 50 Nov 08 14:34:36 Liberator kernel: [00] BAD 40 58 58 2c 45 45 00 00 56 50 50 21 00 00 00 00 Nov 08 14:34:36 Liberator kernel: [00] BAD c0 01 01 01 01 02 3a 3a 80 18 18 71 71 38 2d 2d Nov 08 14:34:36 Liberator kernel: [00] BAD 00 00 a9 c0 c0 95 00 00 81 80 80 81 81 00 81 81 Nov 08 14:34:36 Liberator kernel: [00] BAD 26 26 11 50 50 54 a1 a1 08 08 00 d1 d1 c0 b3 b3 Nov 08 14:34:36 Liberator kernel: [00] BAD 3c 3c 22 78 78 2a 2a 1e 50 50 a7 56 56 51 9c 9c Nov 08 14:34:36 Liberator kernel: [00] BAD 33 33 01 00 00 00 00 00 14 14 1a 01 01 03 03 80 Nov 08 14:34:36 Liberator kernel: [00] BAD 00 ff ff ff ff ff ff 00 ff ff 00 22 22 f0 f0 25 Nov 08 14:34:36 Liberator kernel: EDID block 0 (tag 0x00) checksum is invalid, remainder is 9
Interestingly, when this happened just now I noticed that there is no kscreenlocker_greet process running, but the session is still locked (hence loginctl unlock-session being required).
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/178
Git commit e7764a5360e59ffb9e9da5bc2b956365f3eff277 by David Edmundson. Committed on 20/11/2023 at 23:34. Pushed by davidedmundson into branch 'master'. Reset lock complete variable after lock adfae58490b4b2307221fa4e45465948b749937b changed the greeter to notify out of band that the lock has been successfully lifted. s_lockProcessRequestedExit represents the state between unlock occurring and the greeter exiting. This was not reset when we next showed the lockscreen. A symptom amongst others is that the grace locker would be broken if used after a successful lock. M +2 -0 ksldapp.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/e7764a5360e59ffb9e9da5bc2b956365f3eff277
*** Bug 479601 has been marked as a duplicate of this bug. ***
Unfortunately I continue to be able to reproduce this in Plasma 6,0.4 as well as current git master, exactly as originally described. We also have more reports coming in. Re-opening.
*** Bug 486628 has been marked as a duplicate of this bug. ***
Wonder what the problem is this time, I haven't seen the problem resurface since last year when the initial fix was merged, I went through the reproduction steps I posted in the initial report and can't get the problem to reappear, on both Plasma 6.0.4 from the Arch repos as well as git master Plasma. I also checked a KDE Neon Testing edition VM I have laying around, and it also doesn't exhibit the problem, both before updating (the dates in the package versions are from around mid February) and after updating (Plasma 6.0.4, Frameworks 6.2.0, Qt 6.7.0). A fresh install of Fedora 40 KDE in a VM also doesn't exhibit the problem for me. Current system info in case it's useful: Operating System: Arch Linux KDE Plasma Version: 6.0.80 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.8.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 6800H with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics
I'm also on git master packages with Qt 6.7.0. Fedora 40 for me, with an Intel iGPU.
Created attachment 169571 [details] kinfocenter I don't have this error. Laptop with hybrid Intel + Nvidia graphics. Operating System: ROSA Fresh Desktop 2023.1 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.8.10-generic-3rosa2023.1-x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × 11th Gen Intel® Core™ i7-11800H @ 2.30GHz Memory: 38.9 ГиБ of RAM Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus M16 GU603HE_GU603HE System Version: 1.0
*** Bug 487473 has been marked as a duplicate of this bug. ***
I'm currently experiencing this also. It seemed to start right after the rough upgrade to Plasma 6. Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-35-generic (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6950 XT
I failed to mention that it happens with X11 in my case. I don't use Wayland regularly.
*** Bug 487495 has been marked as a duplicate of this bug. ***
I cannot reproduce it
The only way I have found that I can get back in is to force kill the seemingly hung kscreenlocker_greet process. I had previously tried the "loginctl unlock-session <id>" command right before force killing kscreenlocker_greet though so I'm not sure if that played a part or not. Also, the lock screen only seems to hang on me if i move the mouse right when it's trying to lock. If I wait for a couple of seconds it doesn't hang even if I'm still within the "without password" grace period.
Vlad/Zamundaaa is there anything else log wise or debugging we can provide to help find a way to reproduce this?
*** Bug 488185 has been marked as a duplicate of this bug. ***
*** Bug 487914 has been marked as a duplicate of this bug. ***
Fresh install of Tumbleweed on Plasma 6, new to both. This happens day one, I didn't understand what to do so I reboot my PC, losing progress. It has been over a year since this was discovered, why does this absolutely critical bug still exist??
The "Allow unlocking without password" field should default to 0 and be immediately removed from the settings GUI or be renamed to "Brick your session if you shake your mouse" until this bug is squashed. This is an unacceptable user experience.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/227
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/228
Git commit 59198bbc7ce74606e86b73aa3826892be3a68ed3 by Xaver Hugl. Committed on 17/06/2024 at 14:59. Pushed by zamundaaa into branch 'master'. greeter: don't start authenticating during the grace lock time Some authenticators, like the one for fprintd, block until success or some timeout, and can't be interrupted, which can cause the greeter to stick around for longer than necessary and block the session from being usable during that time. M +6 -3 greeter/greeterapp.cpp M +1 -1 greeter/greeterapp.h M +7 -1 greeter/pamauthenticators.cpp M +2 -0 greeter/pamauthenticators.h https://invent.kde.org/plasma/kscreenlocker/-/commit/59198bbc7ce74606e86b73aa3826892be3a68ed3
Git commit 62bdb37a910866b39420d7111d522227519f670e by Xaver Hugl. Committed on 18/06/2024 at 11:55. Pushed by zamundaaa into branch 'Plasma/6.1'. greeter: don't start authenticating during the grace lock time Some authenticators, like the one for fprintd, block until success or some timeout, and can't be interrupted, which can cause the greeter to stick around for longer than necessary and block the session from being usable during that time. (cherry picked from commit 59198bbc7ce74606e86b73aa3826892be3a68ed3) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +6 -3 greeter/greeterapp.cpp M +1 -1 greeter/greeterapp.h M +7 -1 greeter/pamauthenticators.cpp M +2 -0 greeter/pamauthenticators.h https://invent.kde.org/plasma/kscreenlocker/-/commit/62bdb37a910866b39420d7111d522227519f670e
*** Bug 489118 has been marked as a duplicate of this bug. ***
Does this fix https://bugs.kde.org/show_bug.cgi?id=484931?
Almost certainly yes
*** Bug 484931 has been marked as a duplicate of this bug. ***