### System details

 AMD Ryzen AI 9 HX 370, AMD Radeon 890M, ViewSonic VA3456-WQHD via DisplayPort, Omarchy 4.0.0-1, kernel 7.1.8-arch1-3

### What's wrong?

## What's wrong?

After upgrading to Omarchy 4.0.0-1 (Quattro), waking the locked display is no longer responsive. A single keyboard press or mouse movement often does not bring the monitor back. I have to press keys or move the mouse repeatedly before the lock screen becomes visible.

The same hardware woke promptly on the previous Omarchy release.

This is not the shell-crash behavior reported in #7380. In my journal, `omarchy-shell` remains alive and there are no `FALLBACK` monitor or fatal Wayland errors during wake.

## Expected behavior

One keyboard press or mouse movement should wake the monitor and leave it on long enough to display and use the lock screen.

## Steps to reproduce

1. Run `omarchy system lock`, or allow the idle timeout to lock the session.
2. Wait until the monitor enters DPMS standby.
3. Press `Shift` once or move the mouse once.
4. Observe that the monitor does not reliably finish waking.
5. Continue pressing keys or moving the mouse; after repeated activity, the lock screen eventually appears.

## System details

- Omarchy: `4.0.0-1`
- Kernel: `7.1.8-arch1-3`
- Hyprland: `0.56.2-1`
- Quickshell: `0.3.0.r20.g28771c7-1`
- CPU: AMD Ryzen AI 9 HX 370
- GPU: AMD Radeon 890M (`amdgpu`, PCI ID `1002:150e`)
- Monitor: ViewSonic VA3456-WQHD
- Connection: DisplayPort (`DP-2`)
- Mode: `3440x1440 @ 59.973 Hz`, scale `1`

## Suspected root cause

The new Quickshell lock service uses a fixed 5-second timer in `shell/plugins/lock/Service.qml`:

```qml
function runWake() {
  if (!wakeProcess.running) wakeProcess.running = true
  if (lockRequested) armBlankTimer()
}

Timer {
  id: idleBlankTimer
  interval: 5000
  repeat: false
  // ...
  onTriggered: {
    // ...
    if (root.lockRequested && !root.authenticatingPassword) root.runBlank()
  }
}
```

`runWake()` is called for lock-screen keyboard and pointer activity. It enables DPMS through `omarchy-system-wake`, but also restarts the 5-second blank timer.

The ViewSonic monitor can take longer than five seconds to complete its DisplayPort DPMS wake handshake. The timer can therefore disable DPMS again before the monitor finishes waking. Repeated activity keeps restarting the timer, which explains why multiple key presses or continued mouse movement eventually works.

The idle service logs show that initial activity is detected immediately and the wake helper itself returns quickly, so this does not appear to be missing keyboard or mouse input:

```text
omarchy idle ... idle-monitor: active
omarchy idle ... idle-cycle-cancel: activity
omarchy idle ... process-start: wake omarchy-system-wake
omarchy idle ... process-exit: wake exitCode=0 status=0
```

No relevant `amdgpu` display timeout, DPMS failure, or shell crash appeared in the kernel/user journal.

## Local workaround

I cloned the built-in lock plugin and changed only the timeout from 5 seconds to 15 seconds:

```diff
-    interval: 5000
+    interval: 15000
```

The override is located at:

```text
~/.config/omarchy/plugins/puru.lock/Service.qml
```

This gives the monitor enough time to complete its wake handshake without requiring continuous input.

## Suggested fix

Please consider one or more of the following:

1. Increase the wake-to-reblank grace period from 5 seconds to a value that accommodates slow DisplayPort monitors, such as 15 seconds.
2. Make the grace period configurable in `shell.json`.
3. Start the re-blank timer only after DPMS/output readiness is confirmed, rather than immediately when wake input is received.
4. Avoid issuing another DPMS-off transition while an output is still reconnecting or modesetting.

## Diagnostics

A diagnostic log generated with `omarchy-debug --no-sudo --print` is available locally at:

```text
/tmp/omarchy-debug-for-lock-wake-issue.log
```

I can attach it after reviewing it for private information.

## Related issue

- #7380 reports a different Quattro DPMS-wake failure where Quickshell crashes during a temporary `FALLBACK` output transition. That crash signature is not present here.