swaylock often takes about 30 seconds to unlock after entering the password

[jkseppan]

When I run swaylock from either swayidle or by typing a command in a terminal, it often (but not every time) takes about 30 seconds to verify the password. During that time it hides the "Verifying" text, displays "Cleared" and can accept further input, so initially I thought I had typed my password wrong. I can easily type my password three or four times, and it looks like swaylock starts to verify each of them, but once the initial password attempt goes through it drops the lock, and I might end up typing the last few characters of my password in whatever window has focus.

Interestingly, if I ssh into the laptop from another host and run swaylock in that session (export WAYLAND_DISPLAY=wayland-1; swaylock -d), this problem never seems to happen. The lock screen goes away right after I am done typing my password.

Running swaylock -f from the terminal does not fix this problem; it still takes a long time to verify the password. Same results with systemd-run --user -E XDG_RUNTIME_DIR -E WAYLAND_DISPLAY swaylock.

I am attaching a screen recording. I am done typing my password at about 5 seconds, and I do nothing further until the end of the video. Here is what swaylock -d prints:

2022-08-27 14:22:13 - [main.c:1202] Parsing CLI Args
2022-08-27 14:22:13 - [main.c:1250] Using wlr-layer-shell + wlr-input-inhibitor
2022-08-27 14:22:13 - [main.c:317] output name is eDP-1

recording.mp4

I am running swaylock 1.6.1 on Fedora 36, from package swaylock-1.6-1.fc36.x86_64.

[jkseppan]

I guess this is a duplicate of #61. Entering the password starts the PAM wait for a fingerprint. If I scan a finger, I get access, or if I wait long enough, the fingerprint code times out and then it matters if the password was correct. Like someone said in that issue, "[it] took me longer that I am willing to admit, to understand what was happening".

[hariganti]

Thanks for the info here and the link to the other issue. I was having the same issue, and I started thinking that it may be waiting for fprintd or something to timeout, so good to know that is the case. In case you're still waiting, it looks like this comment has a possible workaround, which I intend to try shortly