Lock screen fingerprint sensor only ever runs ONE pam session per lock

[slr01]

ISSUE — Lock screen fingerprint sensor only ever runs ONE pam session per lock

Summary

The Omarchy lock screen (shell/plugins/lock/Service.qml) creates a single Quickshell PamContext for fingerprint auth and never starts a second one for the duration of a lock. After the first scan returns no-match or the driver errors, fingerprintPam.active stays truthy, so startFingerprint() bails out of every later attempt. Result: fingerprint unlock works at most once per lock, and if your first press misses (finger slipped, touched early, reader was still warming up), the reader is dead until you unlock by password and lock again.

Reproduction

Omarchy 4.0.4, laptop with an integrated fingerprint reader (tested: Broadcom ControlVault 3, USB 0a5c:5843, via libfprint-2-tod1-broadcom / fprintd 1.94.5).

1. Enroll a finger, lock.
2. Press the reader and get a miss/no-match (or wait out the 30s window without touching).
3. Press again — nothing happens, until you unlock with the password.

Details that make it visibly worse on this hardware:

• The reader needs the driver warmed up to take a pass, so the first press in a new lock often errors (Identification failed due to unforeseen error after ~10s). With the current design that one error is fatal for the whole lock.
• The lock keeps the fingerprint PAM armed (scanning) continuously while the display is blanked, which drives the Broadcom 58200 into its thermal cutoff (Device disabled to prevent overheating) after a few minutes of being locked.

Evidence

fprintd debug logs across one lock, stock Omarchy:

15:01:45 identify()            <- first (and only) session
15:01:55 Identification failed due to unforeseen error!
... user holds a finger for 60s after wake ...
15:02-15:06 (nothing)           <- reader never re-arms

And with the fix below:

15:11:17 session #1: identify() -> errors after 10s
15:11:27 session #2+ re-arm on the 250ms retry
15:14:10 fresh session on wake
15:14:18 verify-match            <- unlock works after a miss, after walking away

Root cause

Service.qml uses a single PamContext { id: fingerprintPam } whose active never returns to false after a completed/errored session within one lock. The retry Timer fires every 250ms but startFingerprint() guards on fingerprintPam.active || fingerprintAuthenticating and returns forever.

Proposed fix

See PR (re-arm manages a fresh PamContext per attempt):

• Replace the single PamContext with a Component factory creating a new instance per attempt.
• While the display is blanked (runBlank), stop the retry timer and gate startFingerprint() on the existing displaysBlank state so no NEW scan starts while the sensor is idle and could overheat; re-arm on wake (runWake). An in-flight scan is left to finish — the reader is not a compositor wake source, and aborting the pam session in runBlank severed a scan that the driver was still servicing, leaving the reader dead until password unlock.

Notes

• This is not reader-specific: any fingerprint reader that errors or misses on its first scan of a lock is affected. The thermal behavior just makes the first-scan error common on some TOD/LS drivers.

[slr01]

Follow-up: the fix has been split into two PRs out of the combined #12201 (now closed):

• lock: stop fingerprint scans while the display is blanked #12420 — gating: stop fingerprint scans while the display is blanked (purely additive, fixes the thermal-storm mode)
• lock: re-arm fingerprint reader with a fresh PAM context per attempt #12426 — re-arm: fresh PAM context per attempt (fixes the late-identify dead-reader mode documented above, stacked on lock: stop fingerprint scans while the display is blanked #12420)

[slr01]

Stock A/B capture (2026-09-25): the reader is driver/daemon-gated, not flag-stuck

I swapped the running lock plugin to a pristine stock build (hash-verified), restarted the shell, locked via IPC, and held the screen blank-idle for 25 minutes with zero touches, capturing lock status at 1 Hz plus journald for quickshell and fprintd. Then one single touch.

What actually happens under stock during a blank idle:

• authenticating clears repeatedly — scans open and error; the 250 ms retry keeps firing, but attempts die instantly while the driver is gated. Measured continuous au=false spans up to ~2.5 min. So this is re-arm thrash, not a stuck flag.
• Repeated Device disabled to prevent overheating storms. Stock arms the reader continuously through the blank period, which self-heats the driver — matching the overnight-→dead-morning pattern.
• fprintd SIGSEGV'd at 17:22:53 (Status 11/SEGV, SEGV_MAPERR, in its libusb/gusb USB event thread) and systemd auto-restarted it.
• Post-restart, a steady ~30 s loop: Driver reported successful verify complete but did not report the result earlier. Reporting error instead.
• The morning's ~60 s dead window did not reproduce within 25 min. The closest analog was the thermal storm where every re-arm errors instantly — which reads as "no response" to the user. Password-only recovery fits: ending the lock tears down the thrashed attempt cycle.
• A single touch after 25 min blank idle ran a scan and unlocked normally.

Net: the OS-side loop works; the failure is daemon/driver-side thermal gating plus a genuine fprintd crash. Blank gating (#12420) stops the reader from being armed through the blank period, breaking the overnight self-heating that trips the gate — that is the load-bearing fix. The per-attempt factory (#12426) does not address the reported symptom, and I'll be closing that PR on the strength of this capture.