Lock screen: keep fingerprint idle while the display is blanked

[niconistal]

Problem

• Once the lock screen blanks the display, the fingerprint PAM conversation stays armed and fingerprintRetryTimer re-arms it after every unsuccessful attempt, all night, even though nobody can touch the sensor with the panel dark.
• If the reader itself starts failing immediately, the retry interval is the failure interval: the lock screen opens a new omarchy-lock-fingerprint PAM session roughly every 300 ms.
• Both are pointless work against a device that cannot be reached, and a fingerprint backend left in that loop for hours can end up needing a power cycle before it verifies again.

Change

• runBlank() suspends the fingerprint: it stops the retry timer and aborts the PAM conversation; startFingerprint() refuses to start while suspended.
• runWake() resumes it, so the prompt is armed again as soon as the display is up and the session is still locked with a fingerprint enrolled. A wake caused by the first keystroke of a password resumes the reader without touching the password in flight, and a panel coming back on its own (onScreensChanged) resumes it too.
• Unsuccessful conversations now reschedule through scheduleFingerprintRetry(). An attempt that ended sooner than a finger could have reached the reader compounds a failure streak and backs the next attempt off from 2 s to a 30 s cap; an attempt that lasted long enough to have been a real touch clears the streak and keeps the existing 250 ms retry. The display waking clears the streak as well.

Behaviour

Before:

• Display blanked, still locked: a fingerprint attempt every retry interval until unlock.
• Reader failing instantly: a new PAM session about every 300 ms for as long as the lock is up.
• Waking the display changes nothing, because the reader was never stopped.

After:

• Display blanked, still locked: no fingerprint attempts at all.
• Reader failing instantly: attempts back off 2 s, 4 s, 8 s, 16 s, then 30 s — about 1,400 attempts over 12 h instead of about 144,000.
• Waking the display re-arms the reader immediately and clears any backoff, so a recovered reader is live on the first touch.

Motivation

On a MacBook Pro with Touch ID through the t1bridge fingerprint backend, after the laptop sat locked and blanked for hours, the backend was left in a bad state — its keybag relay service restarting continuously, "load biometric keybag failed" — until a power cycle. Password login was never affected. Separately, on 2026-09-10, once the backend started failing instantly ("Device reported an error during verify: fingerprint operation failed"), the journal shows about 180 fprintd verify errors per minute sustained for 12 hours, i.e. the lock screen opening a new PAM session roughly every 300 ms. Those are observations from one machine on one day.

The backend-side fault is being reported separately. This PR is only about the polling on Omarchy's side, which is worth avoiding on any fingerprint hardware.

Testing

• test/shell.d/lock-blank-fingerprint-test.sh extended to cover the suspend/resume and the backoff; it fails on the unpatched Service.qml.
• ./test/shell — 232 of 236 test files pass; the 4 failures (config, locate, snapper, unowned-system-paths) also fail on unmodified origin/quattro on this machine and are unrelated to the lock plugin.
• qmllint shell/plugins/lock/Service.qml — no new warnings against the pre-change baseline.
• No visual verification of this revision. An earlier revision of the blanked-display half was run on the owner's machine on 2026-09-07 and left locked overnight; this rebased revision, and the backoff, have only had the static checks above.

🤖 Generated with Claude Code

[hanscnelson]

Independent confirmation of both problem halves on a MacBookPro14,2 (Omarchy 4.0.3, T1Bridge Touch ID). We have not run this PR.

On this machine the lock screen already blanks after 5 seconds (idleBlankTimer). Overnight the laptop sat locked with the panel dark and no suspend (PrepareForSleep never fired). Fingerprint PAM kept running the whole time.

Rates from the journal, same omarchy-lock-fingerprint path:

• Waiting for a finger: a new PAM session about every 31 s (fprintd’s 30 s timeout plus the 250 ms retry).
• After the T1 keybag relay wedged (load biometric keybag failed): several PAM sessions per second, matching the instant Device reported an error during verify: fingerprint operation failed storm.

Password unlock still worked. A short Super+Ctrl+L then password-cancel is healthy today (in-flight verify cancelled); the “resume the reader on first keystroke, don’t touch the password” behaviour looks right for that.

This would have stopped the blanked-display polling and the post-wedge 250 ms loop. It would not have been a root-cause fix for the SEP/keybag wedge; that remains on the T1Bridge side.

Happy to live-test a quattro build later if useful. This install is 4.0.3, so the PR is not a drop-in here.

[niconistal]

Thanks for the independent confirmation. Your two rates match what I saw on a MacBookPro14,3: one PAM session about every 31 s while waiting for a finger (fprintd's 30 s timeout plus the 250 ms re-arm), and several per second once the backend starts failing instantly.

On the target branch: the PR is against quattro because that is where the quickshell lock screen lives now, so you are right that it is not a drop-in on 4.0.3. I would gladly take you up on the live test on a quattro build once a maintainer has had a look.

To keep the two sides straight, since they are easy to conflate:

• This PR only fixes the downstream behaviour: stop polling the reader while the display is blanked, and back off when the backend fails instantly. It does not touch the wedge itself.
• The wedge lives in T1Bridge and is tracked in Diagnose sustained keybag relay restart loops standardagents/t1bridge#14 (still open). The evidence from both our machines is in that thread; the maintainer's latest source follow-up localizes the failure to the keybag load/promotion step at relay start, and 0.1.6 added the 2 s to 60 s restart backoff you saw at the cap.
• Related and now fixed: Enrollment fails instantly when t1bridge-keybag.service is in failed state standardagents/t1bridge#21 (enrollment failed instantly when the relay unit sat in systemd's failed state) shipped in T1Bridge 0.1.9 today.

One more data point on recovery: on the 14,3 a full shutdown and power-on cleared the wedge. After the boot the relay did its usual single boot-time retry and has been active since.

[niconistal]

First live result, on a MacBookPro14,3 running Omarchy 4.0.3 with the T1Bridge relay wedged (the reader fails every attempt instantly, the same state as the overnight reports on t1bridge#14).

How it was run on 4.0.3. The lock screen is a plugin, so no packaged file needs editing:

omarchy plugin clone omarchy.lock
# apply this PR's shell/plugins/lock/Service.qml hunks to ~/.config/omarchy/plugins/<user>.lock/Service.qml
omarchy restart shell

Six of the eight Service.qml hunks apply as-is. Two need a hand port on 4.0.3, because runWake/runBlank there have no displaysBlank/monitorDpmsKnown bookkeeping yet and onScreensChanged starts with requestSessionLock(): add resumeFingerprint() at the end of runWake, suspendFingerprint() at the end of runBlank, and root.resumeFingerprint() at the top of onScreensChanged, then the new functions themselves. Note that the lock service is keepLoaded, so saving the file hot-reloads nothing there; omarchy restart shell is required. The clone survives updates; omarchy plugin remove <user>.lock reverts. That should make it a drop-in for @hanscnelson's 4.0.3 install as well.

Observed, 27 s lock, panel blanked after the 5 s idleBlankTimer (state read via omarchy-shell lock status every 2 s, PAM starts from the journal):

• Two instant failures before the blank: failure streak 2, retry delay 4 s.
• At the blank the fingerprint PAM was aborted and stayed suspended for the remaining 21 s: 0 omarchy-lock-fingerprint sessions in that window.
• On the first keypress the reader was re-armed immediately; the password unlocked as usual.
• 6 PAM sessions for the whole lock. The stock 4.0.3 lock screen on the same wedged reader started about 80 in the same interval, and about 2.4k over a 35-minute lock earlier today.

Not a fix for the relay wedge itself (t1bridge#14), only for the lock screen hammering a reader nobody can reach.

[niconistal]

For anyone on a released Omarchy who wants this before it lands: it is now an installable plugin, so no cloning or hand-patching.

omarchy plugin add https://github.com/niconistal/omarchy-quiet-fingerprint.git --enable

It does not ship a patched copy. At every shell start it reads the lock screen Omarchy has installed, applies this PR's change as anchored edits and loads the result, so Omarchy updates flow through. If the installed lock screen already contains the change it disables itself and says so; if the file changed shape so the edits no longer apply, it applies nothing, disables itself and the stock lock screen is back in charge. Registered via clonedFrom: omarchy.lock, the same mechanism omarchy plugin clone uses, so omarchy plugin remove nn.quiet-lock restores the built-in.

Verified on 4.0.3 (same 27 s lock test as above: fingerprint PAM suspended from the blank, zero sessions until the first key); the builder is also tested against the current quattro lock screen. @hanscnelson this should be the drop-in for your 4.0.3 install.