SUMMARY I encountered a bug where the lockscreen can't be unlocked. STEPS TO REPRODUCE 1. Wait till lock screen comes on automatically (or manually locking too? not sure if it makes a difference) 2. Enter password to unlock 3. Press Enter key or click on the arrow next to the password box OBSERVED RESULT Nothing happens. No reaction at all. Screen doesn't unlock. If a wrong password is entered, it also doesn't complain that the password is wrong. There's no obvious way to get back - I just decided to hard reboot my computer by pressing the power button. EXPECTED RESULT Correct password unlocks lockscreen, incorrect password gives "incorrect pw" warning. SOFTWARE/OS VERSIONS Linux: Fedora Kinoite 40 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Graphics: AMD, Wayland ADDITIONAL INFORMATION This only happened to me once so far, and I'm not sure what caused it. However, if it is reproducible it would be a very severe bug. The user would be unable to get back into Plasma and would lose any unsaved document / game / ongoing work if forcefully rebooting the system.
So it's not reproducible, and only happened once, and you can't get it to happen again? Were you using the Wayland session or the X11 session when it happened?
It happened once for me (so far), but I decided to file a bug as it might be reproducible or others have experienced the same. Wayland session
Can you get logs from around the time when the login screen wasn't working? You can specify a time range like this (change the date / time to what you need) journalctl --since "2020-07-10 15:10:00" --until "2020-07-12" Thanks!
Thanks for the tip. I think this is when it happened, as the "Boot" bit at the end must be when I hard-rebooted the PC: ``` Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b271de60 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b27c1120 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b3585b20 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b3cbbf80 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b3cba3e0 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b25f38c0 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b1fe2940 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b1fe1f80 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b1fe0a60 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b22fb760 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b22fa240 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66b22fa0a0 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora thunderbird-bin[4393]: Couldn't map window 0x7f66a6c66720 as subsurface because its parent is not mapped. Feb 18 16:00:27 fedora plasmashell[2177]: kde.plasmashell: requesting unexisting screen available rect -1 Feb 18 16:00:27 fedora plasmashell[2177]: kde.plasmashell: requesting unexisting screen available rect -1 Feb 18 16:00:27 fedora plasmashell[2177]: kde.plasmashell: requesting unexisting screen available rect -1 Feb 18 16:00:27 fedora plasmashell[2177]: kde.plasmashell: requesting unexisting screen available rect -1 Feb 18 16:00:28 fedora systemd[1]: Started dbus-:1.3-org.kde.powerdevil.backlighthelper@12.service. Feb 18 16:00:28 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.kde.powerdevil.backlighthelper@12 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 16:00:29 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-42 noise=9999 txrate=866700 Feb 18 16:00:32 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:00:35 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:00:37 fedora systemd[1]: dbus-:1.3-org.kde.powerdevil.backlighthelper@12.service: Deactivated successfully. Feb 18 16:00:37 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.kde.powerdevil.backlighthelper@12 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 16:00:38 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=780000 Feb 18 16:00:41 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:00:44 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:00:47 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:00:50 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:00:53 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:00:56 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:00:59 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:01:02 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:01:05 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:01:08 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:01:11 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:01:14 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-46 noise=9999 txrate=866700 Feb 18 16:01:17 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:01:20 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:01:23 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-46 noise=9999 txrate=866700 Feb 18 16:01:26 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:01:29 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:01:32 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:01:35 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:01:38 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:01:41 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:01:44 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-42 noise=9999 txrate=866700 Feb 18 16:01:47 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:01:50 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:01:53 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:01:56 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-47 noise=9999 txrate=780000 Feb 18 16:01:59 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:02:02 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:02:05 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=585000 Feb 18 16:02:08 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:02:11 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:02:14 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:02:17 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:02:20 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-47 noise=9999 txrate=780000 Feb 18 16:02:23 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-45 noise=9999 txrate=866700 Feb 18 16:02:26 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-45 noise=9999 txrate=780000 Feb 18 16:02:29 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-46 noise=9999 txrate=866700 Feb 18 16:02:32 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:02:35 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:02:38 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:02:41 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=780000 Feb 18 16:02:44 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=351000 Feb 18 16:02:47 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:02:50 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=780000 Feb 18 16:02:53 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-45 noise=9999 txrate=866700 Feb 18 16:02:56 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:02:59 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:03:02 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:05 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=650000 Feb 18 16:03:08 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:11 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:03:14 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:17 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:03:20 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:03:23 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:03:26 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=650000 Feb 18 16:03:29 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:32 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:03:35 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:38 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:03:41 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-44 noise=9999 txrate=866700 Feb 18 16:03:44 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:47 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:50 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:03:53 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:03:56 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-42 noise=9999 txrate=780000 Feb 18 16:03:59 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:04:02 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:04:05 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-43 noise=9999 txrate=866700 Feb 18 16:04:08 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:04:12 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:04:15 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:04:18 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:04:21 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:04:24 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-43 noise=9999 txrate=866700 Feb 18 16:04:27 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-43 noise=9999 txrate=866700 Feb 18 16:04:30 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:04:33 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:04:36 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:04:39 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:04:42 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:04:45 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:04:48 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:04:51 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:04:54 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:04:57 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:05:00 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:05:03 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:05:06 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:05:09 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:05:12 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:05:15 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:05:18 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=780000 Feb 18 16:05:21 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:05:24 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:05:25 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.kde.powerdevil.backlighthelper@13 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 16:05:25 fedora systemd[1]: Started dbus-:1.3-org.kde.powerdevil.backlighthelper@13.service. Feb 18 16:05:25 fedora kscreenlocker_greet[70560]: qml: The backend got an unknown wallpaper provider type. The wallpaper will now fall back to the default. Please check your wallpaper configuration! Feb 18 16:05:27 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:05:30 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:05:33 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-43 noise=9999 txrate=866700 Feb 18 16:05:36 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-44 noise=9999 txrate=780000 Feb 18 16:05:39 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=156000 Feb 18 16:05:40 fedora systemd[1]: dbus-:1.3-org.kde.powerdevil.backlighthelper@13.service: Deactivated successfully. Feb 18 16:05:40 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.kde.powerdevil.backlighthelper@13 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 16:05:42 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:05:43 fedora systemd-logind[1362]: Power key pressed short. Feb 18 16:05:43 fedora systemd-logind[1362]: Power key pressed short. Feb 18 16:05:45 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-46 noise=9999 txrate=866700 Feb 18 16:05:48 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:05:51 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:05:54 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:05:57 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:06:00 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:06:03 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:06:06 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:06:09 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:06:12 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:06:15 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=866700 Feb 18 16:06:18 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-44 noise=9999 txrate=866700 Feb 18 16:06:21 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:06:24 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:06:27 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:06:30 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-43 noise=9999 txrate=866700 Feb 18 16:06:33 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:06:36 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=866700 Feb 18 16:06:39 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=780000 Feb 18 16:06:42 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-44 noise=9999 txrate=780000 Feb 18 16:06:45 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:06:48 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=780000 Feb 18 16:06:51 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:06:54 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=780000 Feb 18 16:06:57 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-43 noise=9999 txrate=780000 Feb 18 16:07:00 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 Feb 18 16:07:03 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:07:06 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:07:09 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:07:12 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-40 noise=9999 txrate=866700 Feb 18 16:07:15 fedora wpa_supplicant[1544]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-39 noise=9999 txrate=866700 -- Boot d6fbaea9c1f542258c924a8bb2b21508 -- Feb 18 16:07:47 fedora kernel: Linux version 6.12.11-100.fc40.x86_64 (mockbuild@ba682f83ac67488da409b84f811b169a) (gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3), GNU ld version 2.41-38.fc40) #1 SMP PREEMPT_DYNAMIC Thu Jan 23 22:07:15 UTC 2025 Feb 18 16:07:47 fedora kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/ostree/fedora-d874e4247f1649b4caae874e6437c765af89b68e8acf5136a679d3ddf476925f/vmlinuz-6.12.11-100.fc40.x86_64 rd.luks.uuid=luks-d80f81b4-8e0e-42db-bb64-b824024859f1 rhgb quiet root=UUID=425cfaed-9acd-405e-8b10-0d94275ee2d5 rootflags=subvol=root rw ostree=/ostree/boot.0/fedora/d874e4247f1649b4caae874e6437c765af89b68e8acf5136a679d3ddf476925f/0 Feb 18 16:07:47 fedora kernel: BIOS-provided physical RAM map: Feb 18 16:07:47 fedora kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable Feb 18 16:07:47 fedora kernel: BIOS-e820: [mem 0x000000000009f000-0x00000000000bffff] reserved Feb 18 16:07:47 fedora kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000009afffff] usable Feb 18 16:07:47 fedora kernel: BIOS-e820: [mem 0x0000000009b00000-0x0000000009dfffff] reserved Feb 18 16:07:47 fedora kernel: BIOS-e820: [mem 0x0000000009e00000-0x0000000009efffff] usable Feb 18 16:07:47 fedora kernel: BIOS-e820: [mem 0x0000000009f00000-0x0000000009f3bfff] ACPI NVS ``` Also in my logs I found multiple of these (I have the default lockscreen timing of 5 minutes of inactivity, so it tends to lock often): ``` Feb 18 16:28:07 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.3-org.kde.powerdevil.backlighthelper@3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 16:28:07 fedora systemd[1]: Started dbus-:1.3-org.kde.powerdevil.backlighthelper@3.service. Feb 18 16:28:08 fedora kscreenlocker_greet[13849]: qml: The backend got an unknown wallpaper provider type. The wallpaper will now fall back to the default. Please check your wallpaper configuration! Feb 18 16:28:08 fedora kscreenlocker_greet[13849]: The Wayland connection broke. Did the Wayland compositor die? ``` But all these other times, I didn't have any problem entering my password. So even though it sounds more dramatic with the compositor dying, it's probably not relevant.
Thanks for the logs. I'll let someone more knowledgeable about the code take it from here.
Do you have the time before the computer goes to sleep and the time before the screen locks set to the same value? bug 500339 reports that this configuration breaks the lock screen so that it can't be unlocked. (I could not reproduce it with these settings though).
(In reply to cwo from comment #6) > Do you have the time before the computer goes to sleep and the time before > the screen locks set to the same value? bug 500339 reports that this > configuration breaks the lock screen so that it can't be unlocked. (I could > not reproduce it with these settings though). Oops, that should be bug 500441. Marking is as possibly related as they seem to have the same symptoms.
I just had this happen on my laptop running git-master - Closed the lid of the laptop, it went to sleep - Opened the lid - Typed in my password - Pressed enter, then clicked the arrow - neither responded After putting the laptop to sleep with a keyboard shortcut and waking it again, I was able to log in
Created attachment 178653 [details] System logs System logs from just before to shortly after the resume and login attempt
My lockscreen timeout was 5 minutes (changed it to 30 now). I was on AC power so no sleep, but the screen was set to dim after 5 minutes (turn off after 10) on AC power. Also sleep after 10 and 5 minutes if on battery or low power, but that should be irrelevant
(In reply to cwo from comment #6) > Do you have the time before the computer goes to sleep and the time before > the screen locks set to the same value? I just checked. On AC Power - When inactive: Do nothing (So the system wasn't actually asleep, the screen was off) - Dim automatically: 5 min (will not take effect) - Turn off screen: 1 min / when locked 20sec
Are you able to take a phone screenshot of what the lock screen looks like when this has happened?
I'm not currently able to reproduce it on git-master I just realized this sounds the same as bug 484363. I'm marking this as a duplicate of that, since the other has more debugging information. Please follow that report for updates. Thanks! *** This bug has been marked as a duplicate of bug 484363 ***
It's not the same; in that, trying to unlock gets you a screen with an "Unlock" button that then does nothing. In this, trying to unlock does nothing, with no "Unlock" button on a separate screen
*** Bug 501983 has been marked as a duplicate of this bug. ***
*** Bug 502188 has been marked as a duplicate of this bug. ***
*** Bug 502213 has been marked as a duplicate of this bug. ***
*** Bug 504364 has been marked as a duplicate of this bug. ***
Pretty sure I've been experiencing this, one thing I noticed that nobody mentioned (or discovered?) so far is that the lockscreen can become fully functional again by just moving the cursor to another monitor. I'll try to attach a video soon (Brand new OS install) Operating System: openSUSE Tumbleweed 20250605 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.1 Kernel Version: 6.15.0-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5700X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6650 XT
Created attachment 182125 [details] Video of the bug
There's certainly something weird going on if the mouse is on the secondary display when the screen turns off and locks automatically. I can't reproduce the problem exactly so far, but I could get the first enter key press to not do anything. Second one worked however. 1. Have two (or more?) monitors 2. Set display locking to 1 minute 3. Move mouse to the non-primary monitor 4. Wait for screen to lock 5. Wait for screens to turn off 6. Move mouse a tiny bit 7. In lockscreen, the lockscreens are not focused and pressing enter will focus it first before the press does anything.
> I can't reproduce the problem exactly so far, but I could get the first enter key press to not do anything. Second one worked however. > (...) > 7. In lockscreen, the lockscreens are not focused and pressing enter will focus it first before the press does anything. That seems to me like a different, probably unrelated, issue. I observe the issue (the one this report is about) without using multiple screens. I use a single external monitor connected to the laptop, with the laptop's built-in screen disabled, so a total of one active display. I'll copy here something I commented on my duplicate report (502213), which I'm not sure has been considered: ------- Normally, when the screen goes to lock, if I am quick enough to shake the mouse, it will unlock immediately without having to insert the password. I assume that's intended. I do that pretty often, when I'm thinking in front of the screen and not touching keyboard and mouse, and I notice that it's going to lock. I'm not sure if the password prompt is supposed to have the time to become visible in that case (...) but it definitely often does show up for a brief moment, even though it then immediately goes away without having to actually insert the password. When the issue happened, this was one of those cases. So I'm thinking: MAYBE, just maybe, there's some race condition if you shake the mouse exactly at the right (or rarther the wrong) time, just barely after the screen has been locked.
(In reply to php4fan from comment #22) > > ------- > Normally, when the screen goes to lock, if I am quick enough to shake the > mouse, it will unlock immediately without having to insert the password. I > assume that's intended. Thanks for the additional detail. I just wanted to mention that this is, indeed, controlled by a setting Settings -> Security & Privacy -> Screen Locking
I can now reproduce this consistently every time, even after rebooting multiple times From what I've observed, it only happens when the screen is locked automatically, manual locking doesn't cause this. Changing time before lockscreen appears doesn't affect anything, 1 min and 5 min behave the same. Letting the screen go to sleep/turn off and then turning it on doesn't fix anything. Delay before password required: setting to "require password immediately" actually prevents the bug from happening, but that's really not a solution systemctl: <automatic lock> Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: PAM unable to dlopen(/usr/lib64/security/pam_pkcs11.so): /usr/lib64/security/pam_pkcs11.so: cannot open shared object file: No such file or directory Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: PAM adding faulty module: /usr/lib64/security/pam_pkcs11.so Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: PAM unable to dlopen(/usr/lib64/security/pam_fprintd.so): /usr/lib64/security/pam_fprintd.so: cannot open shared object file: No such file or directory Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: PAM adding faulty module: /usr/lib64/security/pam_fprintd.so Jun 11 21:06:34 openSUSE kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Jun 11 21:06:34 openSUSE kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Jun 11 21:06:34 openSUSE kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Jun 11 21:06:34 openSUSE kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Jun 11 21:06:34 openSUSE kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: Data set on unsupported clipboard mode. QMimeData object will be deleted. Jun 11 21:06:34 openSUSE kscreenlocker_greet[20506]: Data set on unsupported clipboard mode. QMimeData object will be deleted. <mouse moved to another screen, "or scan your fingerprint" text appears> Jun 11 21:06:44 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde:auth): pam_kwallet5: pam_sm_authenticate Jun 11 21:06:44 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde-fingerprint:auth): pam_kwallet5: pam_sm_authenticate Jun 11 21:06:44 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde-smartcard:auth): pam_kwallet5: pam_sm_authenticate Jun 11 21:06:44 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde:auth): pam_kwallet5: Couldn't get password (it is empty) Jun 11 21:06:44 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde-fingerprint:auth): pam_kwallet5: Couldn't get password (it is empty) Jun 11 21:06:44 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde-smartcard:auth): pam_kwallet5: Couldn't get password (it is empty) <enter pressed> Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde:setcred): pam_kwallet5: pam_sm_setcred Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde-fingerprint:auth): pam_kwallet5: Empty or missing password, doing nothing Jun 11 21:06:50 openSUSE unix_chkpwd[20599]: password check failed for user (user) Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: pam_unix(kde-fingerprint:auth): authentication failure; logname=user uid=1000 euid=1000 tty= ruser= rhost= user=user Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: pam_kwallet5(kde-smartcard:auth): pam_kwallet5: Empty or missing password, doing nothing Jun 11 21:06:50 openSUSE unix_chkpwd[20600]: password check failed for user (user) Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: pam_unix(kde-smartcard:auth): authentication failure; logname=user uid=1000 euid=1000 tty= ruser= rhost= user=user Jun 11 21:06:50 openSUSE kscreenlocker_greet[20506]: Failed to write to the pipe: Bad file descriptor. <unlocked> Today I upgraded to tumbleweed 20250610, not sure if this is somehow related, maybe, maybe not This now happens every time so considering that is there any other info I can provide?
(In reply to MBR from comment #24) > I can now reproduce this consistently every time, even after rebooting > multiple times Thanks for those details. Just adding some data points, I re-tested with these settings: Lock screen after 1 min Delay before password required: 5 seconds I let the screen lock on its own I cannot reproduce the bug on these: KDE plasma 6.3.5, KF 6.14.0, Qt 6.9.1 - system has no fingerprint reader, single screen KDE plasma git-master, KF 6.16.0, Qt 6.9.1 - with a system that has fingerprint reader, and another that does not KDE Neon Testing VM OpenSuse Tumbleweed VM
Created attachment 182625 [details] A custom LockScreenUi.qml file with additional debugging
Created attachment 182626 [details] A screenshot of the custom LockScreenUi.qml file with additional debugging
Created attachment 182627 [details] The journalctl logs for the custom LockScreenUi file
I'm also having the issue of sometimes not being able to log in (Enter/button doesn't do anything). Here are my findings after several days of debugging: None of the following will reproduce it always, it fails rarely (~5%), works most of the time: * I can reproduce it when it's initiated by timeout (e.g. 1 minute) - different timings and other settings like grace period doesn't seem to affect it * I cannot reproduce when I initiate it myself by via Meta+L (gave it some good ~100 attempts) * However, I can reproduce it by directly executing from command line `/usr/libexec/kscreenlocker_greet`, which is strange Some of the workarounds I found when the problem hits (no restart needed): * "Switch User" button exits the lock screen (kscreenlocker) and opens the log-in view (SDDM), where the logging in works * Clear the input field and wait for 10 seconds until the inputs get hidden and then try again This led me to investigate `/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml` file and I tried to add some "logging" in there. Being new to Linux, didn't know where the console.log would be found + writing to file is a bit restricted in there = so I just created a new UI element to dump my "logs" into. Initially I thought there might be some race condition in there with how the states of `uiVisible` and `blockUI` are handled in the event handler functions, but currently my hypothesis is that the bug is not in that file, because: * `onPasswordResult` gets called * when it fails then `onSucceeded` nor `onFailed` ever get called (is there a third option besides success and fail?) I don't have any insight what happens or should happen between `onPasswordResult` and `onSucceeded`/`onFailed`, hopefully somebody knows better and can make some sense out of this all. PROBABLY IMPORTANT: If the `authenticator.startAuthenticating()` is also added to the `onBlockUIChanged` event handler, then I could not reproduce the bug anymore for some reason. Maybe because the probability goes to 0.05*0.05=0.0025 and my ~100 attempts wasn't enough to reveal it? I guess better understanding of the backend is needed here. I have also attached journalctl logs, my custom LockScreenUi.qml file and a screenshot of it: There are multiple successful attempts (for comparison) before 02:30 and then the screenshot is about the failure at 02:30:29 (+ 3 additional attempts to press Enter or click the button) followed by the workaround of clearing the input and waiting for 10 second timeout for the UI to disappear to try again (and succeed). Oh, and here's my system info: Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.14.11-300.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 2 × AMD A6-9210 RADEON R4, 5 COMPUTE CORES 2C+3G Memory: 16 GiB of RAM (15.1 GiB usable) Graphics Processor: AMD Radeon R4 Graphics Manufacturer: LENOVO Product Name: 80S9 System Version: Lenovo YOGA 510-14AST
PS. If someone's still unable to reproduce it then I have this happening on my friend's laptop available to me for this week. Let me know if some further logging/debugging is needed and I can help with that. Since I'm new to Linux I don't know where to look further.
I can confirm that this does happen as I have been experiencing this issue on an intermittent basis. I recently had to restart sddm on my KDE Neon installation due to this and I have been locked out by the screen locker a few days ago on a different configuration running Plasma 6.x.
*** Bug 505288 has been marked as a duplicate of this bug. ***
I was able to reproduce this consistently by trying to triage https://bugs.kde.org/show_bug.cgi?id=505288 - letting the screen lock on its own, then beginning to type my password on the lock screen right at the time specified in the "Delay before password required" setting. For example, with that delay set to the default 5 seconds, if I make the first keystroke at 5 seconds after the screen locks, then I observe this behavior where password attempts aren't "responded" to. That seems to fit with the observation in comment 24 that changing that setting to "require password immediately" stops the issue from occurring?
Updating severity since there are *some* workarounds
> Updating severity since there are *some* workarounds Workarounds which the average user hit by the bug will likely only find after having force-rebooted and lost their unsaved work at least once.
(In reply to John Kizer from comment #33) > I was able to reproduce this consistently by trying to triage > https://bugs.kde.org/show_bug.cgi?id=505288 - letting the screen lock on its > own, then beginning to type my password on the lock screen right at the time > specified in the setting. > > For example, with that delay set to the default 5 seconds, if I make the > first keystroke at 5 seconds after the screen locks, then I observe this > behavior where password attempts aren't "responded" to. That seems to fit > with the observation in comment 24 that changing that setting to "require > password immediately" stops the issue from occurring? First of all, how do you manage to start typing exactly at the 5 second mark? Or what do you mean? If I have "Delay before password required" set to 5 seconds and hit any key before 5 seconds then the lock screen just goes away like expected (no actual lock); if I type the password after 5 seconds then it's the usual works 95% of the time and doesn't 5% of the time. Secondly, sorry to say, but even with "require password immediately" it does not work 5% of the time. Actually, most of my debugging was done with that setting, including the attached logs and screenshots by me. Don't know what you meant by a workaround, but at least this definitely isn't. Perhaps comment 24 and you are talking about some other bug than the OP and me?
I suppose the exact time mattered less than the fact that if I wait long enough after that time - say like a full minute - then I consistently get the password attempt responded to / don't reproduce this issue. But thanks for sharing what's triggering it on your end then, the conditions for this occurring must be more complex than I had assumed.
(In reply to John Kizer from comment #37) > I suppose the exact time mattered less than the fact that if I wait long > enough after that time - say like a full minute - then I consistently get > the password attempt responded to / don't reproduce this issue. But thanks > for sharing what's triggering it on your end then, the conditions for this > occurring must be more complex than I had assumed. The "exact time" NEVER matters where race conditions are involved (concurrency problems). The timing will NEVER be the same. It's a pointless exercise to try to reproduce by trying to debug for example in an IDE, or via println() statements in code, the latter being the absolute worst way and the least likely to be effective or informative. You have to debug this by static examination of the source code. You need to ensure that there is proper mutex locking on whatever 'object' is used to ensure exclusive access to, and atomic execution of, the code that sets the state of the screen (locked/unlocked). Of course I'm assuming in the above that the desktop environment uses proper threading idioms, and I'm assuming its written in C or C++ or leverages the libc.so mutex locking primitives. But my guess is that it's using something like the mechanisms on this page: https://www.gnu.org/software/libc/manual/html_node/ISO-C-Mutexes.html
IMO it's not pointless. It's still beneficial to know from using "println" what parts of the code is reached vs not reached when the bug happens, i.e. * `onPasswordResult` gets called * `onSucceeded`/`onFailed` do not Helps to narrow down the scope (to be potentially then statically analyzed, for example).
Once the screen is locked, the password field appears (with an fade-in animation of about 1s), and after 10s the field disappear (with an fade-out animation of about 1s). If "5 seconds" is selected in "Screen Locking" settings, the screen cannot be unlocked (unresponsive interface) after the first 5s and before the disappearing of the password field (pressing Esc turns off the screen then pressing any key re-shows the password field which will then work as expected). Pressing any key once the password field has disappear to show it again will allow to unlock the screen by entering the password (as expected). When "30 seconds" or more is selected, the password field also appears during 10s (plus animations) but the password can never be entered since pressing any key unlock the screen. The simplest fix would be not displaying the password field by default, and only once the locking delay has ended (except if password must be asked immediately), since the screen is unlocked on first key pressed (or mouse moved). It's also confusing to have the password field shown when it's not needed, and some users could enter their password that would display on the current active window (they may not realizing it if they're only looking at the keyboard and not the screen), and if it's a live chat app, the password would be sent to everyone when Enter is pressed.
I am also seeing this had happened twice on one machine but other Solus Plasma is fine. Keyboard becomes unresponsive and mouse keeps disappearing on lock screen. Multimedia controls work and Caps Lock/Num Lock keys work but unable to enter password. Have to hard reset. Have changed lock screen settings from Picture of the Day/Bing to slideshow as per other machine which works as a test. Random.
(In reply to Tim from comment #41) > I am also seeing this had happened twice on one machine but other Solus > Plasma is fine. Keyboard becomes unresponsive and mouse keeps disappearing > on lock screen. Multimedia controls work and Caps Lock/Num Lock keys work > but unable to enter password. Have to hard reset. Have changed lock screen > settings from Picture of the Day/Bing to slideshow as per other machine > which works as a test. Random. Just happened on my other older Solus Plasma but up to date. Keyboard stopped responding and mouse was flaky with password box popping up randomly. Keyboard is a PS2 type microsoft internet keyboard other machine is Logitech G11. Seems that changing the wallpaper isn't a solution. So far only solution is a hard reboot.
System: Host: tim-studio Kernel: 6.15.6-321.current arch: x86_64 bits: 64 Desktop: KDE Plasma v: 6.4.4 Distro: Solus 4.7 endurance Machine: Type: Desktop Mobo: Gigabyte model: H310M S2H 2.0 serial: <superuser required> UEFI: American Megatrends v: F20b date: 07/10/2025 CPU: Info: 6-core Intel Core i5-9400F [MCP] speed (MHz): avg: 800 min/max: 800/4100 Graphics: Device-1: NVIDIA GP108 [GeForce GT 1030] driver: nouveau v: kernel Device-2: A4Tech FHD 1080P PC Camera driver: snd-usb-audio,uvcvideo type: USB Display: wayland server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8 compositor: kwin_wayland driver: gpu: nouveau resolution: 1920x1200~60Hz API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 25.1.7 renderer: NV138 Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdpyinfo, xprop, xrandr Network: Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet driver: r8169 Drives: Local Storage: total: 2.24 TiB used: 906.48 GiB (39.6%) Info: Memory: total: 32 GiB available: 31.28 GiB used: 5.72 GiB (18.3%) Processes: 298 Uptime: 1h 13m Shell: Bash inxi: 3.3.38 Machine info for detail
Sounds like your issue is something else, Tim. If it's reproducible, please open a new bug report for it. Thanks!
Seems like this is not happening anymore (6.4.5)
I will mark it as fixed then. If it happens still in 6.5.0 please reopen this report!
This just happened to me on Plasma 6.4.5 keyboard stopped responding after auto lock, mouse brought up password box but couldn't enter password and clicking mouse did nothing. Tried unplugging keyboard and mouse but no different even plugged a second keyboard in to a different USB port and still no response. Multimedia controls on keyboard were working on playing media.
Just a hunch but when this happens the text about finger print scanner dont display maybe connected to that as a course of investigation.
(In reply to Tim from comment #47) > This just happened to me on Plasma 6.4.5 Akseli had asked to reopen this report iIf it happens still in 6.5.0.
(In reply to TraceyC from comment #49) > (In reply to Tim from comment #47) > > This just happened to me on Plasma 6.4.5 > > Akseli had asked to reopen this report iIf it happens still in 6.5.0. Appreciate that but waiting for 6.5.0 to be available and its annoying because it trashes my SSDs and have to boot into Windows to run chkdsk to fix. I report em as I see em.
(In reply to Tim from comment #50) > Appreciate that but waiting for 6.5.0 to be available and its annoying > because it trashes my SSDs and have to boot into Windows to run chkdsk to > fix. I report em as I see em. I appreciate your frustration. Since this is expected to be fixed in 6.5.0, there is no value to KDE in keeping this report open unless it is *not* fixed in 6.5.0.