## What happened

Omarchy 4.0.4-1, stock `idle.screensaver=150` / `idle.lock=300`, single display.

After the idle lock blanks the panel, waking it shows the lock screen for only
one or two seconds before it goes black again. The password then has to be
typed blind. Unlocking succeeds and the desktop comes up lit, so nothing is
broken — the lock screen is simply not readable long enough to use.

The display is an ASUS PG49WCD at 5120x1440@120 over HDMI with DSC. It takes
several seconds to resynchronise after DPMS off→on. That delay is the
display's own and not Omarchy's problem — but it interacts badly with the
blank timer.

## The mechanism

`runWake()` re-arms the blank timer on every wake:

```qml
// shell/plugins/lock/Service.qml:167-170
function runWake() {
  if (!wakeProcess.running) wakeProcess.running = true
  if (lockRequested) armBlankTimer()
}
```

and the timer blanks unconditionally after a hardcoded 5 s:

```qml
// shell/plugins/lock/Service.qml:414-431
Timer {
  id: idleBlankTimer
  interval: 5000
  onTriggered: {
    if (Date.now() - armedAt > interval + 2000) { root.armBlankTimer(); return }
    if (root.lockRequested && !root.authenticatingPassword) root.runBlank()
  }
}
```

The 5 s budget starts at the **wake request**, not at the first frame the
display actually presents. On a panel that needs 3-4 s to resync, nearly the
whole budget is consumed before anything is visible:

```
t=0s      key/mouse -> runWake() -> dpms on, armBlankTimer()
t=3-4s    display finishes DSC resync, lock screen becomes visible
t=5s      idleBlankTimer fires -> runBlank() -> dpms off
          => ~1-2 s of visible lock screen
```

Keystrokes do re-arm the timer (`LockView.qml:177` -> `wakeRequested()`), but
each re-arm restarts the same race: the display has to resync again from
scratch, and it never wins. Submitting the password stops the timer
(`onAuthenticatingPasswordChanged`, :478-482), which is why the desktop is
stable afterwards — by then the user has typed blind.

The existing suspend guard at :423 shows the shape of the fix is already
understood for a different case: a timer that fires when the screen cannot
reasonably be seen yet should take a fresh run-up rather than blank.

## Expected

The lock screen should stay visible long enough to be used after a deliberate
wake, on any display.

## Suggested fix

Either of:

1. **Arm the timer at first presented frame** rather than at the wake request,
   so the display's wake latency is not charged against the user's reading time.
2. **Make the interval configurable** in `shell.json` (e.g. `idle.lockBlank`),
   so slow-syncing displays can raise it.

Option 1 is the real fix; option 2 is a one-line escape hatch.

## Workaround in use

`omarchy plugin clone omarchy.lock` and `interval: 30000` in the clone. Works,
but the clone falls out of updates.

## Related

#12327 is a different trigger with an overlapping symptom: there the blank is
undone by HPD link flaps and the screen strobes. Here nothing flaps — the
timer simply fires before the display has shown anything. #7145 (closed) was
a "no outputs" Wayland glitch, also distinct.

## System

| | |
|---|---|
| Omarchy | 4.0.4-1 |
| Hyprland | 0.56.2 |
| Kernel | 7.2.5-4-omarchy |
| CPU | AMD Ryzen 7 7800X3D |
| GPU | NVIDIA RTX 4080, driver 610.57.04 |
| Display | ASUS PG49WCD, [email protected], HDMI-A-2, DSC |
| idle | `screensaver: 150`, `lock: 300` |

## Steps to reproduce

1. Use a display with a multi-second DPMS wake latency (high-res + DSC).
2. Let the session idle until the lock screen blanks.
3. Press a key or move the mouse.
4. The lock screen appears, then blanks again ~5 s after the wake request —
   roughly 1-2 s after it first became visible.