## Environment
- Omarchy 4.0.1-1 (Arch)
- GPU: AMD HawkPoint1 [Radeon] (PCI 66:00.0)
- HDMI audio: AMD Radeon High Definition Audio Controller (PCI 66:00.1)
- Terminal: foot (screensaver launches fine)
- Display connected via HDMI/DP

## Expected behavior
When idle, the system should lock and the display should turn off (or stay locked) cleanly — the same way Suspend from the menu does.

## Actual behavior
After the lock engages, the display turns off and on repeatedly (~5–8 s) while locked. The lock state itself is stable (`secure=true`); only the display DPMS toggles.

## Root cause
The lock plugin (`shell/plugins/lock/Service.qml`) arms `idleBlankTimer` (5 s) after locking; its trigger runs `blankProcess` → `omarchy-brightness-display off` → `hl.dsp.dpms disable` (DPMS off) **while the session is live**.

On this AMD + HDMI combo, DPMS-off drops the HDMI link, and the Radeon HDMI audio codec emits `SW_VIDEOOUT_INSERT` / `SW_LINEOUT_INSERT` switch events (evdev `event18` — "HD-Audio Generic HDMI/DP"). These are treated as activity, which wakes the lock (`runWake` → `omarchy-system-wake` → DPMS on), re-arms the 5 s blank, and the cycle repeats.

## Evidence
Traced `hyprctl monitors` `dpmsStatus` with `omarchy-shell idle/lock status` and raw `/dev/input` events. Every DPMS toggle coincides exactly with a switch event from the HDMI audio device; no keyboard/mouse input occurs during the flicker:

```
19:05:40  EVENT event18 [HD-Audio Generic HDMI/DP,pcm=7] SW c=6  → dpms=[False]
19:05:48  EVENT event18 [HD-Audio Generic HDMI/DP,pcm=7] SW c=8  → dpms=[True]
19:05:53  EVENT event18 [...]                                → dpms=[False]
19:06:01  EVENT event18 [...]                                → dpms=[True]
... (continues; locked=true secure=true throughout)
```

## Why Suspend works but idle doesn't
Suspend powers the display down at the kernel PM level (clean, like Windows). The lock-during-suspend path uses `OMARCHY_LOCK_ONLY=true omarchy-system-lock` ("lock before suspend without scheduling display off"), so it never schedules the live DPMS-off blank that triggers the loop. Windows (dual-boot, same cable/monitor) also sleeps the display cleanly, confirming it is not a hardware/cable fault.

## Workaround
Commenting out the blank in `shell/plugins/lock/Service.qml` stops the flicker (display stays on while locked):

```qml
function runBlank() {
    // if (!blankProcess.running) blankProcess.running = true
}
```

(Note: editing a `/usr/share/omarchy` file; it can be overwritten on update.)

## Suggested fix
- Don't treat unrelated switch/jack events (e.g. HDMI audio `SW_VIDEOOUT_INSERT`) as wake activity, or
- Stabilize/guard the display before issuing DPMS-off (e.g. delay the blank, or detect the link-flap and avoid re-arming), or
- On lock, prefer a suspend-like display power-down instead of a live `hl.dsp.dpms disable` that flaps on certain GPUs.

## Steps to reproduce
1. Omarchy on AMD APU with HDMI/DP display + Radeon HDMI audio.
2. Leave idle until the lock engages (default `lock = 300`, repro used `100`/`200`).
3. ~5 s after lock, the display flickers off/on.
4. Confirm with `watch -n1 'hyprctl monitors -j | jq .[].dpmsStatus'` and `sudo libinput debug-events` (or raw `/dev/input` monitoring) showing HDMI audio switch events coinciding with each toggle.