> *This was generated by AI during triage.*

**Updated after the discussion below.** The blank-to-link-drop mechanism v1b3m describes is confirmed on this machine too and belongs with #9078 and #10691, so I have split it out of this report. What remains here are the two findings that the siblings do not cover.

## Finding 1: the idle service cannot wake the display after a lock

`lockSystem` in `plugins/services/idle/Service.qml` clears `idledThisCycle` at line 77 immediately before triggering the lock at line 80. `handleActiveSignal` then returns early on `!root.idledThisCycle` at line 159. So once the lock has happened, every later `idle-monitor: active` produces no cancel and no wake.

The service's manifest claims display wake as its job, and after a lock it cannot perform it. Evidence from both machines:

- quattro (v1b3m): `process-start: wake` fired once for the whole boot, 6 minutes before the lock. Five later `idle-monitor: active` events over 9 hours produced nothing.
- This machine (Renoir): same pattern; the one wake of the session fired pre-lock at 21:08:45 on Sep 11, nothing after.

## Finding 2: a clamshell-disabled internal panel survives resume with nothing to reconcile it

After a lid-closed suspend, eDP-1 sits disabled by the clamshell config rule while the lock is already secure. On resume, the reconciliation poll in `omarchy-hyprland-monitor-watch` (`poll_clamshell_state`) only runs while a laptop has an external monitor active. The moment the machine is undocked the poll is killed, so re-enabling the panel depends on the lid switch bind or a monitoradded event, and the incidents show those get missed across resume. Three incidents in three days all ended the same way: the panel stayed black, the lock was secure and submitting passwords (`unix_chkpwd` failures in the journal, Sep 11 21:05, Sep 12 10:07, Sep 13 18:38), and the user hard-rebooted.

The controlled repro shows how narrow the margin is. With an external monitor connected the poll does run and fixes it, but only after a visible window:

```
19:23:50  eDP-1 disabled=true        (clamshell: lid closed + external monitor active)
19:24:00  recorder gap of 15s        (suspend)
19:24:14  resume: eDP-1 still disabled, HDMI-A-1 lit, lock secure
19:24:17  eDP-1 re-enabled           (watcher poll, 3 s later)
19:24:19  unlock
```

Two wake-path holes still apply here:

1. `omarchy-system-wake` runs only from the dead gate above or the lock view's first input, and `omarchy-brightness-display on` skips the DPMS enable when every enabled monitor is already lit, so a disabled eDP-1 reads as "all lit" while the user stares at it.
2. Even when the enable runs, `hl.dsp.dpms({ action = "enable" })` does nothing for a monitor disabled at the compositor level. Only `omarchy-hyprland-monitor-clamshell` re-enables it. One hung `omarchy-system-wake` also makes every later `runWake()` in `plugins/lock/Service.qml` a no-op for the rest of the lock (`if (!wakeProcess.running)` guard, no timeout).

## What moved to the siblings

The blank-strand mechanism, where a DPMS-off blank drops the monitor link a few seconds later and the output returns enabled with no mode, stranding the lock in `lock-pending: no-real-screen`: confirmed here too (Sep 13 19:23:59 FALLBACK with `QScreen(name="")` in the shell log, 15 s of journal silence, recovery only because the link re-asserted itself; a blank-only run today logged `amdgpu ... DMCUB error` at the DPMS-off transition). See #9078 and #10691, and v1b3m's comment above for the quattro data.

## Suggested fixes

1. Finding 1: clear `idledThisCycle` after the lock triggers, or drop the early return so a post-lock active still wakes the display.
2. Finding 2: reconcile display state on the resume edge of `PrepareForSleep(false)` (the wake side of `omarchy-system-sleep-monitor`, which already listens to that signal): run `omarchy-hyprland-monitor-clamshell` bounded by a timeout, and force `hl.dsp.dpms({ action = "enable" })` when any enabled monitor reports `dpmsStatus == false`. I run this as a user unit (reconcile at +1 s and +4 s, timeout around every call) and the controlled cycle now lights the panel reliably. Happy to turn it into a PR.

Unrelated but available on request: a quickshell segfault 11 s after the Sep 11 resume (SIGSEGV in `QQmlData::destroyed` during a `QQmlDelegateModel` teardown), coredump and `~/.cache/quickshell/crashes/` report.

## System

- Omarchy 4.0.3-1 (Arch), kernel 7.2.3-arch1-3
- Hyprland 0.56.2-2, quickshell 0.3.1-1
- AMD Renoir APU (1002:164c), amdgpu, eDP-1 1920x1080 + HDMI-A-1 1920x1080