An agent, so a finger can mean something in your session

The daemon announces every matched finger on the system bus and stops there,
because root has no session bus, no display and no business starting your
applications. fingerprintd-agent is the other half: it runs as you, subscribes
properly rather than parsing gdbus monitor output, filters by uid because the
signal is visible to every local user, and maps fingers to commands from a file
you own and can edit without restarting anything.

It is a separate binary and a separate subpackage because it is a separate
trust domain. /etc/fingerprintd/actions.conf is a root shell and is guarded
like one; ~/.config/fingerprintd/fingers.conf runs your commands as you, so it
is an ordinary dotfile.

Demonstrated on the phone: one press of the unlock finger both unlocks it and
opens plasma-camera.

packaging/fingerprint-auth.pam

@@ -19,8 +19,16 @@
 # conversation; sufficient, so a match ends the stack successfully and a
 # failure falls through to pam_deny rather than to a password -- the caller
 # (kde-fingerprint) is the one that decides whether to offer a password next.
+# timeout: pam_fprintd defaults to 30 seconds and the lock screen arms
+# fingerprint exactly ONCE when it appears, so on a stock setup the sensor is
+# live for half a minute and then silently is not -- a press after that reaches
+# nothing at all, which reads as a broken sensor rather than an expired window.
+# 60 s is a compromise, not a fix: every second of it is our verify loop
+# polling the trustlet at ~5 Hz, so the honest ceiling on this number is set by
+# the idle-IRQ work (fp6 journal/fingerprint, "SENSOR POWER"). Raise it once an
+# idle verify costs nothing.
 auth       required    pam_env.so
-auth       sufficient  pam_fprintd.so
+auth       sufficient  pam_fprintd.so timeout=60
 auth       required    pam_deny.so
 
 account    include     base-account