## What happens

After `systemctl suspend` and resume, the session is permanently locked out. The lock screen's password box is visible on screen, but there is **no mouse cursor and no keyboard input at all**, and it never recovers — not after several minutes. The only way out appears to be a hard reset.

The image on screen is a dead client's last rendered frame. `omarchy-shell` exits silently during resume while holding the `ext-session-lock`, its supervisor declines to relaunch it, and Hyprland's lock failsafe then holds the session with no locker able to authenticate.

## What I expected

Either the shell survives the output churn on resume, or its supervisor relaunches it so the session can be unlocked normally.

## Root cause

Three things compound:

**1. Resume tears down every Wayland output for ~26s.** On this NVIDIA setup Hyprland drops the real output, swaps in a headless `FALLBACK`, and restores the real one much later:

```
15:02:01 omarchy-shell: INFO qt.qpa.wayland: There are no outputs - creating placeholder screen
15:02:01 omarchy-shell: DEBUG: Not creating lock surface for screen QScreen(...) as it is
                        not backed by a valid wayland output.
15:02:04 omarchy-shell: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK"
                        which was not previously tracked.
15:02:27 uwsm_hyprland.desktop: (xkbcomp runs — real output finally back, 26s after resume)
```

**2. Quickshell dies without a signal** when its Wayland connection fails — exactly as `omarchy-launch-shell:49-50` already documents:

> `Quickshell relaunches itself from its signal handlers, but Qt leaves through _exit() when the Wayland connection fails, raising no signal: no crash report, no relaunch, no bar. Supervise those deaths.`

Consistent with this, `coredumpctl` has no record of any crash, and the shell's journal trail simply stops:

```
22:50:58 omarchy-shell: DEBUG qml: omarchy lock ... lock-requested
22:50:58 omarchy-shell: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
22:50:59 omarchy-shell: DEBUG qml: omarchy lock ... secure=true
22:50:59 kernel: PM: suspend entry (deep)
<resume — no further omarchy-shell output, ever>
```

**3. The supervisor's teardown guard misfires and exits silently.** `omarchy-launch-shell:77`:

```bash
# Relaunching into a session already tearing down burns the attempt budget.
compositor_alive || exit 0
```

`compositor_alive` (line 37) allows 3 attempts with 0.5s sleeps — roughly a **1.5s** budget:

```bash
for attempt in 1 2 3; do
  hyprctl -j monitors >/dev/null 2>&1 && return 0
  (( attempt < 3 )) && sleep 0.5
done
```

A compositor 26 seconds deep in output reconfiguration cannot answer inside 1.5s, so the guard concludes the session is tearing down and returns `exit 0` — no relaunch and no log line. The comment at line 34 anticipates precisely this situation ("A compositor busy reconfiguring outputs can miss a query without being gone, and that is when the shell dies"), but the budget is an order of magnitude too small for an NVIDIA resume.

Confirming the supervisor never even tried: neither `logger` message from lines 85/89 (`relaunching` / `Giving up on the Omarchy shell`) appears anywhere in the journal, across every boot on this machine.

**Result:** the session sits in exactly the state `omarchy-restart-shell` describes in its own comments —

> `a LOCK session without an active locker — the shell died, or its crash handler re-execed a fresh instance that holds no lock — sits in that failsafe with no way to authenticate, and a restart plus re-lock is the only way back in without a reboot.`

Per `ext-session-lock-v1` the compositor must stay locked once the locker is gone, which is why no input reaches anything and why it never recovers.

## Steps to reproduce

1. On a machine where resume tears down Wayland outputs for longer than ~1.5s (NVIDIA proprietary driver + DisplayPort here).
2. `systemctl suspend`, wait for the lock to report `secure=true`.
3. Resume.
4. The password box renders but accepts no keyboard or pointer input, permanently.

Reproduces intermittently — it depends on whether quickshell's Wayland connection survives the output blackout. A resume where the shell survived shows the same `There are no outputs` / `FALLBACK` churn and a 26s gap, then unlocks normally.

## Workaround

Recovery without a reboot, from a TTY (`Ctrl+Alt+F2`):

```bash
omarchy restart shell
```

This correctly detects the dead-locker state, respawns the shell and re-locks so the user can authenticate out. Worth noting the recovery path already exists and works — the gap is that nothing invokes it automatically.

## Suggested fix

Widen `compositor_alive`'s budget in `omarchy-launch-shell` so it spans a realistic resume window rather than 1.5s, and/or distinguish "compositor unreachable but session still present" (logind session still active) from genuine teardown before giving up. Logging the give-up path would also make this diagnosable — currently it exits completely silently.

## System details

| | |
|---|---|
| Omarchy | 4.0.2-1 |
| Kernel | 7.1.9-arch1-2 |
| CPU | AMD Ryzen 9 9950X 16-Core |
| GPU | NVIDIA RTX PRO 4000 Blackwell [10de:2c34] (drives the display) + AMD Granite Ridge iGPU |
| Driver | nvidia-open-dkms 610.57.04-1, nvidia-utils 610.57.04-1 |
| Hyprland | 0.56.2 |
| quickshell | 0.3.1-1 |
| Monitor | Dell U3225QE, 3840x2160@60 on DP-4 (direct DisplayPort) |
| Board | MSI MS-7E86 |
| Session | Wayland / uwsm |

NVIDIA video-memory preservation is correctly enabled, so this is not the known unconfigured-VRAM case — `/proc/driver/nvidia/params` reports `PreserveVideoMemoryAllocations: 1`, `UseKernelSuspendNotifiers: 1`, `TemporaryFilePath: "/var/tmp"`.