### System details

Framework Laptop 13 (AMD Ryzen 5 7640U, Radeon 760M, amdgpu), Thunderbolt dock with 2x DELL S2721DGF over DP, Omarchy 4.0.3-1, Hyprland 0.56.2-2, quickshell 0.3.1-1, kernel 7.2.3-arch1-3.

(`omarchy debug` is not an available command in 4.0.3, so no debug log; journal timeline included below.)

### What's wrong?

After waking the laptop from suspend, the lock screen is visible for about five seconds, then all displays blank (DPMS off). Typing the password still works — each keypress wakes the displays again (`submitPassword()` -> `runWake()`) — but the freshly woken lock screen goes dark under the user.

The Thunderbolt dock makes this easy to hit: on resume the dock's DP outputs re-enumerate and a recreated output comes back with DPMS **on** (the same mechanism documented in #11330's root-cause analysis), so the lock screen lights up on its own without any input — and then the blank timer turns it off again.

**Steps to reproduce**

1. Dock the laptop, lock the session, close the lid / let it suspend.
2. Wake the machine.
3. The lock screen appears, then blanks ~5 seconds after resume.

**Root cause**

`shell/plugins/lock/Service.qml` arms a 5-second blank timer at lock and re-arms it on every wake:

- `idleBlankTimer` (`interval: 5000`) -> `blankProcess` -> `omarchy-brightness-display off` -> `hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'`
- `runWake()` re-arms it on every input while locked

QML timers freeze across suspend and fire right after resume. The wall-clock guard in `idleBlankTimer.onTriggered` exists for exactly this case, but it **re-arms** the timer instead of cancelling it:

```qml
onTriggered: {
  // A countdown frozen by suspend fires right after resume, which would
  // blank the freshly woken unlock screen under the user. Wall-clock time
  // exposes the gap: take a fresh run-up instead of blanking.
  if (Date.now() - armedAt > interval + 2000) {
    root.armBlankTimer()
    return
  }
  ...
}
```

The comment states the intent — don't blank the freshly woken unlock screen under the user — but re-arming guarantees exactly that blank, 5 seconds after resume. The guard postpones the blank by one interval; it does not prevent it.

Journal timeline from one cycle (lock ~64s before suspend, so the timer had already fired and the displays were DPMS-off before sleep; the dock's output re-enumeration at resume is what lit them again):

| Time | Event |
|---|---|
| 12:28:11 | `lock-requested` / `secure=true` (blank timer armed, fires at 12:28:16, displays DPMS-off) |
| 12:29:15 | `PM: suspend entry (s2idle)` |
| 12:34:08 | `PM: suspend exit` — dock outputs re-enumerate, panels light with DPMS reset to on |
| 12:34:13 (approx) | lock screen blanks again |
| 12:34:16 | user types password -> `runWake()` -> displays on -> `unlocked` |

The same blank also lands when the lock happens seconds *before* suspend (lid-close -> `omarchy-sleep-lock` -> logind suspends right after `secure=true`): the timer is frozen mid-countdown and blanks 5s after resume even without the output-recreation path.

**Expected**

After waking the machine, the lock screen stays visible until the user interacts. Any input already re-arms the normal 5s countdown via `runWake()`.

**Actual**

The lock screen goes dark ~5 seconds after resume; the user must type blind or press a key to bring it back.

**Proposed fix**

On the suspend-gap branch, hold the display instead of scheduling a blank:

```qml
if (Date.now() - armedAt > interval + 2000) {
  // Freshly resumed: the user woke this machine to unlock it. Hold the
  // display up; their next input re-arms the normal countdown via runWake().
  idleBlankTimer.stop()
  return
}
```

Trade-off: an unattended wake (WoL, rtcwake) leaves the lock screen lit until input. That is cosmetic, and the same is already true today whenever an output is recreated with DPMS reset — which the quattro branch already acknowledges ("A panel coming back is a display turning on that runWake did not ask for"). A more conservative variant would re-arm with a longer post-resume grace (30-60s).

Still present on the `quattro` branch as of this report.

**Related issues**

- #11330 — output recreation resets DPMS to on (why the lock screen lights up on its own at resume)
- #8361 — lock screen loses keyboard focus after resume (compounds this: after the blank, a click may be needed before typing works)