## What happened

On Apple Silicon (Quattro) with an external monitor on the built-in HDMI port, locking the screen (either via the idle timeout or manually) starts a repeating ~16–17 second cycle of the monitor losing signal ("No Signal" on the monitor's own OSD), then briefly showing the lock/password prompt for about a second, then going back to "No Signal" — repeating indefinitely until the session is actually unlocked.

## What was expected

The lock screen should stay up and stable, with the display either fully on or cleanly blanked — not flapping.

## Root cause

This is a feedback loop between two independent, otherwise-reasonable pieces of Omarchy behavior, exposed by how Apple's DCP driver implements DPMS on the HDMI output:

1. `shell/plugins/lock/Service.qml` arms a 5-second `idleBlankTimer` after the lock screen appears. When it fires, `runBlank()` shells out to `omarchy-brightness-display off`, which runs `hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'`.
2. On this hardware, DPMS disable is not a soft blank — the `apple-dcp` driver does a full link teardown/retrain. `omarchy-brightness-display`'s own source already documents this for the "on" path:
   > "a redundant DPMS enable right after system resume forces another modeset, which blanks the panel for a beat (visible flash at the unlock screen)"
3. That teardown surfaces to userspace as a real, repeated HDMI hotplug event (`apple-dcp ...: DP2HDMI HPD irq, connected:0` immediately followed by `connected:1`), which `bin/omarchy-hyprland-monitor-watch` (`recover_modeless`) and/or the lock UI's own wake path treat as monitor/user activity — waking the display back up, which re-arms the 5-second blank timer, which blanks it again, and so on. The result is a stable, mechanical oscillation for as long as the session stays locked.

### Evidence

Kernel log across one boot (53h uptime): `DP2HDMI HPD irq` fired **2,697 times**, with inter-event deltas landing almost entirely on **16 or 17 seconds** (1,437 events at 17s, 1,249 at 16s — real cable/link flakiness produces irregular timing, not a near-perfect fixed period). All flapping was confined to locked/idle windows; it started right after the idle-triggered lock and stopped **instantly** at the moment the session was unlocked (0 events in the following 7+ minutes of active use).

One representative cycle (`journalctl -k`), showing the mechanical ~16s period and a `set_digital_out_mode` (modeset) immediately following each hotplug pair:

```
Aug 29 06:59:03 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0
Aug 29 06:59:03 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:1
Aug 29 06:59:04 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, 500ms debounce: connected:1
Aug 29 06:59:04 kernel: apple-dcp 271c00000.dcp: set_digital_out_mode(color:85 timing:81) "3840x2160": 60 594000 ...
Aug 29 06:59:20 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0     (+17s)
Aug 29 06:59:20 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:1
Aug 29 06:59:21 kernel: apple-dcp 271c00000.dcp: set_digital_out_mode(...)
Aug 29 06:59:36 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0     (+16s)
Aug 29 06:59:37 kernel: apple-dcp 271c00000.dcp: set_digital_out_mode(...)
Aug 29 06:59:53 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0     (+17s)
Aug 29 07:00:09 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0     (+16s)
Aug 29 07:00:26 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0     (+17s)
Aug 29 07:00:43 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0     (+17s)
Aug 29 07:01:00 kernel: apple-dcp 271c00000.dcp: DP2HDMI HPD irq, connected:0     (+17s)
Aug 29 07:01:08                                                                   <- user typed password, session unlocked, cycle stops for good
```

Alongside this, `omarchy-shell` logs repeated `DEBUG: Not creating lock surface for screen QScreen(...) as it is not backed by a valid wayland output` every time the output is torn down mid-cycle — the lock surface itself is caught in the churn.

## Confirmation / workaround

Cloned the lock plugin (`omarchy plugin clone omarchy.lock`) and made `armBlankTimer()` a no-op, so the display is never DPMS-disabled after locking. Result: locked the session for 45+ seconds with **zero** HPD flaps and a stable `dpms=true` output, versus ~3 flaps expected in that window on stock config. Unlocking normally afterward worked fine and produced no further flapping. This isolates the DPMS-disable call as the trigger — authentication/PAM/session-lock logic was not touched.

This is a real behavior loss for stock Omarchy though: without this workaround, locking no longer actually saves any power on this hardware (the intended blank never sticks), it just visibly flickers instead.

## Suggested fix directions

- Skip the DPMS-disable blank-after-lock behavior when the active output is served by the `apple-dcp`/`apple_drm` driver (detect via `hyprctl monitors -j` or the DRM driver name), since a real "off" already isn't achievable cleanly there; fall back to some other power-saving measure (e.g. backlight-only, if the panel exposes one) or simply leave it lit.
- And/or make `omarchy-hyprland-monitor-watch`'s `recover_modeless` (and whatever wakes the lock screen on the resulting hotplug) distinguish "we just intentionally DPMS'd this output off" from "this monitor genuinely needs recovery," so a self-inflicted blank doesn't get treated as a dropped monitor.

## Steps to reproduce

1. On a Quattro/Apple Silicon machine with an external monitor on the built-in HDMI port, lock the session (`omarchy system lock`, or let idle timeout trigger it).
2. Wait ~5–20 seconds.
3. Watch the monitor cycle: signal drops ("No Signal" on the monitor OSD) → lock/password prompt flashes for ~1s → signal drops again. Repeats every ~16–17s until unlocked.
4. Confirm in `journalctl -k -f`: repeated `apple-dcp ...: DP2HDMI HPD irq, connected:0` / `connected:1` pairs at that same fixed interval.

## Environment

- Machine: Mac mini (Mac14,3 / M2), Apple mainboard model J473
- OS: Arch Linux ARM (Asahi), kernel `7.1.6-1-1-ARCH` (`linux-asahi`)
- Omarchy: `omarchy-dev 4.0.0.r6673.g5939caf-1`
- Compositor: Hyprland 0.56.1
- Display stack: `apple-dcp`, `apple_drm`, `dcp-dp-audio`; GPU Apple M2 (G14G B0) via `asahi`/`honeykrisp`
- External monitor: BenQ MA320U, 3840x2160@60, connected via `HDMI-A-1` (Apple's internal DP→HDMI bridge)

Happy to attach the full `omarchy-debug --no-sudo --print` output or a screen recording of the flap if useful — didn't include the full package list here since it's long, but have it captured.