# Lock screen fingerprint auth hangs ~25-30s if fprintd restarts while locked (e.g. after suspend on drivers needing a post-resume reset)

## Summary

The lock screen's fingerprint PAM session (`plugins/lock/Service.qml`) is armed once, the moment the screen locks, and stays alive for the entire locked duration — including across suspend/resume. If the fprintd D-Bus daemon backing it gets restarted while that session is still active (which some fingerprint drivers require after every resume — see below), the session is silently orphaned. It doesn't fail fast: it blocks on a dead D-Bus call until the default ~25s method-call timeout expires, *then* errors out and retries — at which point it works instantly. The net effect: touching the fingerprint reader right after waking the laptop does nothing for up to ~30 seconds, with no visible feedback that anything is wrong.

## Repro

Hardware: HP EliteBook with a Validity 138a:00ab sensor, driven by the `python-validity-d51-git` AUR package (not upstream Omarchy, but relevant context: this driver's `python3-validity-suspend-hotfix.service` restarts `python3-validity.service` + `open-fprintd.service` after every resume, because the sensor needs a full USB reset post-suspend — this is what actually triggers the bug, but the bug itself is generic to any setup where fprintd gets restarted mid-lock).

1. Configure fingerprint unlock (`omarchy-lock-fingerprint` PAM works, `fprintd-list` shows an enrolled finger).
2. Lock the screen (`omarchy-shell lock lock`, or just let it lock normally). Confirm `omarchy-shell lock status` shows `"authenticating": true`.
3. While still locked, restart the fprintd daemon underneath it: `sudo systemctl restart open-fprintd.service` (this reproduces exactly what the D51 suspend-hotfix does after every resume, without needing a real suspend/resume cycle).
4. Watch the journal (`journalctl -f`) and try the fingerprint reader.

**Observed:** nothing happens for ~25-30s. Eventually:
```
pam_fprintd(omarchy-lock-fingerprint:auth): ReleaseDevice failed: Client must claim device first
```
appears, quickshell starts a fresh PAM session, and fingerprint auth immediately works from then on.

**Expected:** the lock screen detects that its fingerprint session is now talking to a dead service and re-arms immediately, with no user-visible delay.

## Root cause

In `plugins/lock/Service.qml`:
- `startFingerprint()` is called once, from `WlSessionLock.onSecureStateChanged` when `secure` becomes true — i.e. at lock time.
- The resulting `fingerprintPam` `PamContext` session is kept alive for the whole lock (the file's own comment on the idle-blank timer notes: *"the fingerprint PAM stays armed for the whole lock"*).
- There is no code path anywhere in the file that watches for suspend/resume or for the backing fprintd D-Bus service being restarted. Recovery only happens reactively, via `fingerprintPam.onError`, which only fires once the underlying (now-pointless) D-Bus call actually fails — and a call to a service that no longer exists doesn't fail fast, it just sits until the default D-Bus method-call timeout (~25s) expires.

This isn't specific to this one driver — any fingerprint backend that needs to restart fprintd while a session might be active (crash recovery, a driver update, a manual `systemctl restart`, or any other suspend-quirk driver) will hit the identical ~25-30s hang.

## Suggested fix

Patch attached (`fingerprint-resume-fix.diff`, applies cleanly to `plugins/lock/Service.qml` as of Omarchy 4.0.1-1). Summary of the change:

- `restartFingerprint()`: aborts the current `fingerprintPam` session (if any) and re-arms `startFingerprint()`.
- `fprintdOwnerWatcher`: a small `dbus-monitor` process watching `net.reactivated.Fprint` (the standard fprintd D-Bus name — not specific to any one driver) for `NameOwnerChanged` acquiring a new, non-empty owner. That signal only fires when fprintd has genuinely been restarted out from under an in-flight session — so on the common case (a fingerprint setup where fprintd never restarts mid-lock), this stays fully inert and never interferes with a healthy verify. When it *does* fire while `fingerprintPam.active`, it calls `restartFingerprint()` immediately instead of waiting out the dead call.
- `resetFingerprint` IPC verb on the existing `lock` IPC target, as a manual escape hatch (`omarchy-shell lock resetFingerprint`).

Verified locally (see repro above): with the patch, `VerifyStart` resumes within ~1s of the daemon restart, no `ReleaseDevice failed` error, no user-visible delay.

Deliberately keyed off the D-Bus ownership-change signal itself rather than off suspend/resume directly, so it generalizes to any driver/daemon-restart scenario rather than special-casing this one sensor.

One implementation nuance worth a second opinion from someone more familiar with Quickshell's process model: this adds one persistent `dbus-monitor` subprocess per lock-plugin instance for the life of the session. It's cheap, but if there's a lighter-weight or more idiomatic way to watch a D-Bus name's ownership from within Quickshell (a native primitive rather than shelling out), that'd probably be preferable to spawning a process.

## Environment

- Omarchy 4.0.1-1
- `python-validity-d51-git` (AUR), `open-fprintd`