Bug 481086

I can confirm this bug on a Lenovo ThinkPad T14 Gen1 and also on a Lenovo ThinkPad X1 Yoga Gen 3.
Both running openSUSE Tumbleweed with Plasma 6.2.0

Can either of you test with Plasma 6.3.2? Improvements have been made to fingerprint scanning and unlocking
On 6.3.2, if I lock my screen and move the mouse, I see the prompt to unlock with the fingerprint reader, and it works on the first try.

(In reply to TraceyC from comment #2)
> Can either of you test with Plasma 6.3.2? Improvements have been made to
> fingerprint scanning and unlocking
> On 6.3.2, if I lock my screen and move the mouse, I see the prompt to unlock
> with the fingerprint reader, and it works on the first try.

(In reply to TraceyC from comment #2)
> Can either of you test with Plasma 6.3.2? Improvements have been made to
> fingerprint scanning and unlocking
> On 6.3.2, if I lock my screen and move the mouse, I see the prompt to unlock
> with the fingerprint reader, and it works on the first try.

For me, it actually got worse.
On the lockscreen, the fingerprint unlock is only possible on about 25% of attempts on Plasma 6.3.2

I tried to follow the opensuse documentation for fingerprint unlocking:
https://en.opensuse.org/SDB:Using_fingerprint_authentication

I ran sudo pam-config --update --fprintd which didn't fix anything and my configs in /etc/pam.d/kde looks like this:
#%PAM-1.0
# This service is only used by kcheckpass for unlocking,
# so only auth is really relevant here.
auth     include        common-auth
account  include        common-account
password include        common-password
auth     sufficient     pam_unix.so try_first_pass likeauth nullok
auth     sufficient     pam_fprintd.so

I also tried this
#%PAM-1.0
# This service is only used by kcheckpass for unlocking,
# so only auth is really relevant here.
auth                    sufficient      pam_unix.so try_first_pass likeauth nullok
auth                    sufficient      pam_fprintd.so
auth     include        common-auth
account  include        common-account
password include        common-password

But that didn't change anything.
/var/lib/pam.d/kde-fingerprint looks like this
#%PAM-1.0
# for fingerprint
auth     required       pam_fprintd.so
auth     include        common-auth
account  include        common-account
password include        common-password

fingerprint authentication works perfectly every time for sudo and polkit, but not the lockscreen.
I guess it is also worth mentioning that I'm on openSUSE Kalpa now, which is immutable, but uses the same packages as Tumbleweed. This means that /var/lib/pam.d/kde looks different to the /etc version, but the /etc version should have precendence, right? I'm also wondering why it works sometimes and sometimes not.
I also already had the case (multiple times actually) that I couldn't unlock my screen AT ALL, it didn't accept my password nor my fingerprint - so I had to reboot my machine, which is very annoying. Should I open a new bug for the latter issue?
Do you need any other configs? :)

Thanks for the additional details. That lets us know it's not pam or fprintd, but probably in the lock screen code. I'll let a contributor more experienced with that area take it from here.

The same issue is happening with Yubikey (u2f-2fa). I can only unlock the screen after first try. The behavior on lock screen is different than login screen: at login screen you enter the password first, then it asks for Yubikey. But on screen lock, it seems it is requesting before the password, right after the screen locks. By the time the user is back, the Yubikey stopped blinking (probably timed out). I have to enter anything just to fail the first attempt, then it trigger again the Yubikey.

I am using Fedora 42 with KDE Plasma 6.3.5.

Pam settings:

authselect current
Profile ID: local
Enabled features:
- with-faillock
- without-nullok
- with-pwhistory
- with-libvirt
- with-pam-u2f-2fa
- without-pam-u2f-nouserok

Hope this helps.

Reporting that I'm seeing similar behavior using Howdy. I believe it's due to the way the PAM stack is invoked. With SDDM PAM isn't invoked until enter is pressed on the password field. An empty password triggers the stack to process leading to howdy trying to authenticate, then falling back to password if it can't auth by Howdy. However, with KDE's lockscreen the PAM stack triggers immediately after locking, which in turn causes my camera to turn on and immediately unlock my computer unless I'm not at my desk. When I do get back to my desk I have to enter an empty password (like SDDM), but this time wait for the password failure, then for the PAM stack to restart and start checking my face again, which takes about 10 seconds overall.

If the behavior could emulate how SDDM calls the PAM stack, I think that would address this bug.

Oh wow, right after posting I see Plasma 6.4.3 came out and fixed the PAM stack issue!

> Lockscreen: prevent immediate prompting for the password. Commit. Fixes bug #499637