## Summary

When `pam_fprintd` cannot reach the fingerprint reader, the lock screen retries fingerprint
authentication every 250 ms indefinitely — no backoff, no attempt cap — forking a PAM subprocess
each time. On a machine whose reader becomes unavailable across suspend, this makes the first
unlock after a break visibly laggy, and it can spin for minutes.

The device fault itself is upstream (details below). This report is about Omarchy converting a
recoverable, detectable fault into a sustained busy-loop instead of falling through to the password
prompt.

## Where

`shell/plugins/lock/Service.qml`

```qml
Timer {
  id: fingerprintRetryTimer
  interval: 250
  repeat: false
  onTriggered: root.startFingerprint()
}
```

Both the completion path and the error path restart it unconditionally:

```qml
function handleFingerprintFinished(result) {
  fingerprintAuthenticating = false
  if (!lockRequested) return
  if (result === PamResult.Success) {
    finishUnlock()
  } else if (fingerprintConfigured) {
    fingerprintRetryTimer.restart()
  }
}
```

```qml
PamContext {
  id: fingerprintPam
  config: "omarchy-lock-fingerprint"
  ...
  onError: function(error) {
    root.fingerprintAuthenticating = false
    if (root.lockRequested && root.fingerprintConfigured) fingerprintRetryTimer.restart()
  }
}
```

Nothing distinguishes "the user presented the wrong finger" from "the reader is unavailable"
(`PAM_AUTHINFO_UNAVAIL`). The only attempt counter in the file, `failedAttempts`, is on the
password path and is not consulted here.

Additionally `/etc/pam.d/omarchy-lock-fingerprint` is:

```
auth       required                    pam_fprintd.so
account    include                     system-local-login
```

so there is no graceful fallthrough at the PAM layer either.

## Root cause chain

1. A Synaptics Prometheus reader (`06cb:00fc`) re-enumerates over USB on every resume — device
   number 20 → 24 → 25 → 26 across two days on this machine.
2. `fprintd` creates a new D-Bus device object per re-enumeration and never reaps the dead ones.
   After four days uptime, `fprintd-list` reported **4 devices for a single physical sensor**
   (`Device/0`, `/3`, `/4`, `/10`) and selected a stale one.
3. `pam_fprintd` tries to `Claim` the dead object and gets
   `Authorization denied ... Device was already claimed`, returning PAM code 9
   (`PAM_AUTHINFO_UNAVAIL`, "Authentication service cannot retrieve authentication info").
4. Omarchy sees a non-success result and re-arms the 250 ms timer. Forever.

Steps 1–2 are not Omarchy's — 2 looks like an `fprintd` leak. Step 4 is.

## Evidence

Counts from a single boot on this machine:

- **36,782** × `fprintd[...]: Authorization denied ... to call method 'Claim' ... Device was already claimed`
- matching `quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)`

Worst sustained episode: **219 denials/minute for five consecutive minutes**, which is 3.65/s
against the timer's 4.00/s. The loop ran at its designed rate until a password was typed. A milder
episode during a normal unlock produced 25 denials and 26 PAM subprocess spawns.

Representative excerpt (username redacted):

```
fprintd[218632]: Authorization denied to :1.38010 to call method 'Claim' for device 'Synaptics Sensors': Device was already claimed
omarchy-shell[1852287]: quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)
omarchy-shell[1852394]: quickshell.service.pam.subprocess: Starting pam session for user "<user>" with config "omarchy-lock-fingerprint" in dir "/etc/pam.d"
fprintd[218632]: Authorization denied to :1.38013 to call method 'Claim' for device 'Synaptics Sensors': Device was already claimed
omarchy-shell[1852394]: quickshell.service.pam.subprocess: Error while authenticating: "Authentication service cannot retrieve authentication info" (code 9)
...
```

For contrast, suspend/resume itself is not slow here — `Freezing user space processes completed
(elapsed 0.001 seconds)`. The perceived lag is the retry storm.

## Expected behaviour

On a PAM error or `PAM_AUTHINFO_UNAVAIL`, stop retrying and fall through to the password prompt,
or back off exponentially with a cap. A failed *swipe* can reasonably re-arm; an unavailable
*device* should not be retried four times a second indefinitely.

## Steps to reproduce

1. Laptop with a fingerprint reader that re-enumerates on resume (Synaptics Prometheus `06cb:00fc`
   here; likely any reader that drops off the USB bus during suspend).
2. Enroll a fingerprint so `fingerprintConfigured` is true.
3. Suspend/resume several times without restarting `fprintd`.
4. `fprintd-list $USER` now reports multiple devices for the one sensor.
5. Lock the session. The lock screen spins at 4 PAM spawns/second until a password is entered;
   `journalctl -f` shows the paired "already claimed" / code 9 lines.

## Workaround

Restarting `fprintd` clears the stale objects (4 → 1 here). To stop it recurring,
`/etc/systemd/system-sleep/fprintd-reset`:

```bash
#!/bin/bash
case "$1" in
  post) systemctl try-restart fprintd.service ;;
esac
```

Confirmed working on this machine. This only papers over the upstream leak; the retry loop is
still worth bounding, since any cause of an unavailable reader will trigger it.

## System

| | |
|---|---|
| Omarchy | 4.0.4-1 |
| Kernel | 7.2.5-3-omarchy |
| CPU | 13th Gen Intel Core i7-1365U |
| GPU | Intel Raptor Lake-P \[Iris Xe Graphics\] (rev 04) |
| Hyprland | 0.56.2-2 |
| quickshell | 0.3.1-1 |
| fprintd | 1.94.5-2 |
| libfprint | libfprint-git 1:1.94.100.r10.g6f9479c-1 |
| Reader | `06cb:00fc` Synaptics Prometheus |

Note `libfprint-git` rather than stable `libfprint`, in case the device-object leak is specific to
that build.