## System details

- **OS:** Omarchy 4.0.3 (`omarchy 4.0.3-1`, `omarchy-settings 4.0.3-1`)
- **Kernel:** 6.17.2-arch1-3
- **Compositor:** Hyprland 0.56.2-2
- **Shell/lock:** quickshell 0.3.1-1 (Omarchy lock plugin — `lock-stranded` / `screen-stabilizing`)
- **GPU:** AMD Phoenix1 (AMD/ATI)
- **Display:** Dell U2719DX over **HDMI-A-1** (serial 9G4XV13)
- **Hostname:** quattro

## What's wrong?

After idle / stepping away, unlocking often enters a loop:

1. Omarchy password / lock UI
2. Blank screen
3. Hyprland failsafe: **“Oopsie daisy, it looks like you locked your screen but the lockscreen app died :(”**
4. Back to password → repeat

Sometimes on return the failsafe screen is **stuck** (not flashing). Unlocking then requires waiting for the display to settle, or recovering via another TTY as the failsafe text describes.

This is frequent: in a recent 24h window the journal showed on the order of **~3,000** combined `lock-stranded` / `Omarchy shell exited with status 255` / `FALLBACK` events.

## Evidence

### Visible failsafe (photo)

Photo of Dell monitor showing Hyprland crash-lock UI:

> Hyprland :(  
> Oopsie daisy, it looks like you locked your screen but the lockscreen app died :(  
> (instructions to use another TTY + `hyprctl` clear crashed lockscreen / kill lock process)

### Journal pattern (user session)

While locked / recovering, quickshell repeatedly logs:

```text
qml: omarchy lock ... lock-stranded: recovering
qml: omarchy lock ... lock-pending: screen-stabilizing
qt.qpa.wayland: There are no outputs - creating placeholder screen
quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked.
Omarchy shell exited with status 255; relaunching.
```

Cycle is roughly every **10–13 seconds** until outputs stabilize; PAM (`omarchy-lock-password`) can then succeed (`Authenticated successfully`).

### Kernel / link noise

In the same period, kernel logged heavy **HDR SB** spam on the HDMI path (thousands of lines / 24h), correlating with monitor loss/regain (Dell U2719DX).

### Collateral (same display storm family)

Same machine, same period — GTK/Wayland clients dying during output thrash (not OOM):

1. **2026-09-15** — `voxtype-osd-gtk4` SIGSEGV while idle during Hyprland no-outputs / FALLBACK / omarchy-shell relaunch storm (after lock/idle recovery; OSD respawned).
2. **2026-09-16** — `nautilus` SIGSEGV in libgtk-4 Wayland dispatch during ~23 min of no-outputs / FALLBACK / ~109 shell relaunches; HDR SB spam on HDMI.

These look like collateral. The **actionable Omarchy bug** is lock + shell dying when Hyprland loses the real output.

## Expected

Lock UI stays up across DPMS / monitor sleep / wake. If the lock client dies, recovery should not loop password ↔ failsafe ↔ blank every ~12s.

## Actual

Lock client dies when outputs flap → Hyprland failsafe → shell respawn → lock UI again → die again. Unlock UX is broken until the HDMI link stabilizes.

## Reproduce

1. Omarchy 4.0.3 + Hyprland, external Dell on HDMI.
2. Lock session (`Super+Ctrl+L` / idle lock) and leave until the monitor goes dark.
3. Return and attempt unlock.
4. Observe password ↔ blank ↔ “lockscreen app died” loop, or stuck failsafe.

## Notes / mitigations tried

- Not yet changed Hyprland color-management settings.
- Cable/port reseat suggested but not confirmed as a fix.
- `hypridle.service` not present; Omarchy sleep-lock path (`omarchy-sleep-lock.service`) is active.

## Ask

Is this a known lock/quickshell issue with HDMI hotplug / FALLBACK monitors? Happy to attach full `journalctl --user` slices and the failsafe photo. Primary ask is making lock resilient when Hyprland temporarily has no real outputs.

## Screenshot

Failsafe photo saved locally as `Documents/Omarchy/lockscreen-app-died-2026-09-16.JPEG` (will attach in a follow-up comment if the web UI allows; describing it here): Hyprland grey screen with handwritten "Hyprland :(" and text "Oopsie daisy, it looks like you locked your screen but the lockscreen app died :(" plus TTY recovery instructions.