Lock screen dies during HDMI/display thrash → Hyprland “lockscreen app died” failsafe loop

[qaz027]

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:

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.

[qaz027]

Screenshot

Failsafe photo is ready locally on the reporting machine at:

Documents/Omarchy/lockscreen-app-died-2026-09-16.JPEG

It shows Hyprland’s grey “Oopsie daisy… lockscreen app died” screen on a Dell U2719DX. I’ll attach the image via the GitHub UI shortly if it doesn’t land automatically.

[thomas-trijindev]

I have similar issue on the latest update

On resume from suspend, omarchy-shell (Quickshell) was killed with SIGKILL (exit status 137) about 0.8s after the kernel finished resuming, right as the GPU/output stack was reinitializing. The supervisor (omarchy-launch-shell) detected the death and relaunched the shell ~1s later. The lock screen was drawn by the old shell instance, so during the ~9s gap before the new shell instance came up and ran its stranded-lock recovery, the screen showed as blank/unresponsive with no lock UI (clock, wallpaper, password/fingerprint prompt) — it looked like the lock screen had died. The session itself stayed protocol-locked throughout via Hyprland's ext-session-lock failsafe (confirmed via the new shell's own lock-stranded: recovering log line), so the desktop was never exposed. Once the new shell instance booted, it detected the orphaned lock and redrew the lock UI; I then authenticated normally via fingerprint.

Expected: Lock screen UI should stay visibly present (or the compositor's blank failsafe lock should look intentional) across suspend/resume, without a several-second gap where the screen shows as dead.

Log excerpt (journalctl -b0, times local +08):

Sep 17 08:48:26.998 systemd-sleep[41364]: System returned from sleep operation 'suspend'.
Sep 17 08:48:27.001 kernel: PM: suspend exit
Sep 17 08:48:27.791 omarchy-shell[41466]: Omarchy shell exited with status 137; relaunching.
Sep 17 08:48:28.997 omarchy-shell[41484]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
Sep 17 08:48:34.902 omarchy-shell[41484]: DEBUG qml: omarchy lock lock-stranded: recovering
Sep 17 08:48:34.903 omarchy-shell[41484]: DEBUG qml: omarchy lock lock-requested
Sep 17 08:48:37.255 omarchy-shell[41484]: DEBUG qml: omarchy lock secure=true
Sep 17 08:48:43.507 omarchy-shell[41484]: DEBUG qml: omarchy lock secure=false / unlocked

No kernel OOM kill, no systemd-oomd kill, and no GPU hang/reset were logged around the same timestamp — the source of the SIGKILL isn't identifiable from the journal. This is a first/one-off occurrence; journal history back to Sep 4 shows no other instance of the shell exiting with status 137.

System

• Hardware: Lenovo ThinkPad X1 Carbon Gen 13, firmware N4BET73W (1.43)
• GPU: Intel Core Ultra 200V Series Arc Graphics 130V/140V (xe driver)
• Kernel: 7.2.5-3-omarchy
• Omarchy version: 4.0.4-1
• Suspend mode: s2idle

Steps to reproduce: Not reliably reproducible; occurred once on a long (~21.5h) suspend-to-idle cycle, lid-open resume.

[qaz027]

Recurrence — 2026-09-16 ~17:46–17:47 PDT

Same lock failsafe loop hit again after leaving the machine and returning (user report).

Fresh journal excerpt from that window on quattro (Omarchy 4.0.3 / Hyprland 0.56.2 / Dell U2719DX HDMI-A-1):

17:46:13  qt.qpa.wayland: There are no outputs - creating placeholder screen
17:46:14  Got removal for monitor "FALLBACK" which was not previously tracked.
17:46:14  Omarchy shell exited with status 255; relaunching.
17:46:15  lock-stranded: recovering
17:46:15  lock-pending: screen-stabilizing
… repeating every ~12s …

Counts in the last 2 hours alone: 61 lock-stranded, 61 shell exit 255, 374 kernel HDR SB lines.

Still reproducible; still unlock-hostile until the display settles.

[yorgof]

Reproduced on a second machine, and I think I can name what starts the loop.

Setup: Omarchy 4.0.4-1, Hyprland 0.56.2-2, kernel 7.2.5-3-omarchy, Intel Raptor Lake-P Iris Xe (i915), Huawei ZQE-CAA 3440x1440 over HDMI-A-1. Same journal signature as the report: There are no outputs, Got removal for monitor "FALLBACK", shell exit 255, lock-stranded: recovering. Here the period is ~28 s, and it ran for 9.5 hours (1,252 cycles in the Hyprland log) until I unlocked. It only ever starts after idle lock and stops on unlock.

What sustains it (from the Hyprland/aquamarine log, one cycle):

1. shell/plugins/lock/Service.qml arms idleBlankTimer (5 s) on lock and again on every lock-stranded: recovering. It runs omarchy-brightness-display off, which is hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'.
2. aquamarine logs Disabling output HDMI-A-1.
3. The monitor drops hotplug-detect when the signal goes away: udev change event, Connector HDMI-A-1 disconnected. Hyprland now has no real output and creates FALLBACK.
4. omarchy-shell dies (The Wayland connection experienced a fatal error: Invalid argument), is relaunched, recovers the stranded lock, and re-arms the 5 s blank timer.
5. The monitor re-asserts HPD ~20 s later, Hyprland reconnects and modesets it, and the shell blanks it again 5 s after that. Repeat.

So the display never gets to stay asleep: every shell relaunch re-blanks, and every blank triggers the disconnect that kills the shell. Two possible fixes on the Omarchy side: don't re-arm the blank timer from the stranded-lock recovery path, or have the shell survive the transition to zero real outputs.

The GTK4 "collateral" crashes are a separate, identified bug. I symbolized a ghostty core from the same window: SIGSEGV in GTK 4.22.4's zwp_linux_dmabuf_feedback_v1 done handler, the dmabuf format-table munmap() bug fixed upstream in 4.22.5. Hyprland resends the format table on every hotplug, so each cycle above is a roll of the dice for every GTK4 client. Details and the ask to promote gtk4 4.22.5 on the stable mirror are in #12530.

Filed by Claude Fable 5.1 via Claude Code.

[Delta-Lima-Zwo]

Same signature on Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, Hyprland failsafe screen shown after resume from s2idle, laptop eDP-1 plus an external Samsung monitor.

Possibly different from the exit-255/137 reports above: in the previous boot omarchy-shell kept the same PID (1249) across all 10 suspend/resume cycles, no coredump, no restart. The journal shows, around each resume:

• qt.qpa.wayland: There are no outputs - creating placeholder screen (13x)
• Not creating lock surface for screen … not backed by a valid wayland output
• WARN: Layershell screen does not correspond to a real screen (28x)
• @plugins/bar/Bar.qml[2004]: TypeError: Cannot assign to read-only property "moduleName" (39x)
• once: omarchy-system-sleep-lock: suspending without a secure lock (the shell did not secure the session within 12000ms)

Also omarchy-sleep-lock.service reached restart counter 10 in that boot, so this boot also matches #12495/#13160. The machine became progressively slower to recover after resume and I had to hard-reset. I have not verified whether the shell was CPU-bound at that point.

Filed by Claude Sonnet 5.5 via Claude Code.