### System details

- Omarchy: 4.0.4-1
- Hyprland 0.56.2-2, Aquamarine 0.15.0-2, quickshell 0.3.1-1, hyprutils 0.14.2-1
- Kernel: reproduces on both `linux-omarchy 7.2.5-3` and mainline `linux 7.2.3.arch1-3`
- Framework laptop, AMD Strix (Radeon 880M / 890M), `amdgpu`
- Monitors:
  - `DP-2` — LG HDR 4K, `3840x2160@60`, **scale 1.5**, at `0x0` (USB-C / DP alt mode)
  - `DP-3` — Dell U3415W, `3440x1440@50`, scale 1, at `2560x0`
  - `eDP-1` disabled (clamshell)
- Note: `DP-3`'s position (`2560x0`) is derived from `DP-2`'s logical width (3840 / 1.5 = 2560), so `DP-2`'s geometry has to resolve before the layout is stable.

### What's wrong

After an **idle** lock, the second monitor never unlocks. Entering the password on `DP-3` unlocks `DP-3` and returns to the desktop; `DP-2` keeps displaying a frozen lock screen indefinitely.

A **manual** lock (`omarchy-system-lock`) does not reproduce it — both monitors lock and unlock correctly, every time.

Clean discriminator: when the lock is healthy, typing the password on `DP-3` mirrors the masked characters onto `DP-2`'s lock surface. On a failed idle lock there is no mirroring at all — `DP-2`'s surface is inert, which is what first suggested it was never created against a valid output.

### Downstream damage

Once `DP-2` is in this state:

- `hyprctl monitors` reports it as mode `[email protected]` with `scale: 1` (config is `3840x2160@60` scale 1.5), while `disabled: false` and `dpmsStatus: 1`
- windows placed on its workspace get degenerate geometry — captured a Chromium window at `size: -3,-3`
- Hyprland then logs, continuously:
  ```
  *** BUG ***
  In pixman_region32_init_rect: Invalid rectangle passed
  ```
- Chromium's GPU process crashes repeatedly — 7 coredumps in ~70 minutes (1× SIGILL, 6× SIGTRAP)
- nothing recovers the output short of restarting Hyprland. `hyprctl reload`, per-monitor DPMS off/on, and re-applying the monitor with `hyprctl eval 'return hl.monitor({...})'` all return `ok` and change nothing. Physically replugging the cable does not fix it either.

### Root cause

`/usr/share/omarchy/shell/plugins/lock/Service.qml`.

`beginLock()` → `queueSessionLock()` starts a 500 ms `sessionLockStabilizeTimer` before `requestSessionLock()` sets `sessionLock.locked = true`, which is the point at which Quickshell creates the per-screen `WlSessionLockSurface`s.

**Proven:** 500 ms is too short on the idle path for this setup — raising it to 1500 ms reliably fixes it (below).

**Inferred:** `DP-2` has not presented settled geometry at the 500 ms mark, so its lock surface is created against an invalid / zero-sized screen, or skipped entirely.

The guard does not catch this:

```qml
function realScreenCount() {
  ...
  if (screen && screen.name && screen.width > 0 && screen.height > 0) count += 1
  ...
}
function hasRealScreen() { return realScreenCount() > 0 }
```

`requestSessionLock()` proceeds as soon as **at least one** screen reports valid geometry. With `DP-3` valid, the lock is taken regardless of what `DP-2` is doing. There is no per-screen validation.

### Verified fix

Cloning the plugin (`omarchy plugin clone omarchy.lock`) and changing exactly one line resolves it:

```diff
   Timer {
     id: sessionLockStabilizeTimer
-    interval: 500
+    interval: 1500
     repeat: false
     onTriggered: root.requestSessionLock()
   }
```

With that change, idle lock brings up working lock surfaces on both monitors, the mirrored password characters return, and both unlock together. Failure reproduced and fix verified.

That said, a longer fixed timeout is still a race — it just widens the window. The real fix is probably to require **every** screen to report valid geometry before taking the lock (or to create each surface as its screen becomes valid) rather than accepting the first one.

### Ruled out

- **Screensaver teardown.** The screensaver spawns one fullscreen window per monitor, and `omarchy-system-lock` kills them immediately *after* requesting the lock — which looked like the obvious perturbation inside the 500 ms window. Disabling the screensaver entirely (`omarchy toggle screensaver`) does **not** fix it, so the race is not with the screensaver windows.
- **Kernel.** Reproduces identically on `linux-omarchy 7.2.5-3` and mainline `linux 7.2.3.arch1-3`.
- **Cable / port / monitor.** The same monitor and USB-C cable work on other machines, and work fine on this machine until the first idle lock.

### Steps to reproduce

1. Two external monitors, one with a fractional scale whose logical width determines the other's position (here `DP-2` `3840x2160` @ scale 1.5 at `0x0`, `DP-3` at `2560x0`); internal panel disabled.
2. Confirm a manual lock is healthy: lock, type the password on the primary, watch the masked characters mirror onto the second monitor, unlock — both return.
3. Leave the session idle until `idle.lock` fires.
4. Wake and enter the password on the primary.
5. The primary unlocks; the second monitor stays on a frozen lock screen and never returns. No mirroring was visible while locked.

### Expected behavior

Idle lock should create a working lock surface on every connected output, and unlocking should release all of them — the same as a manual lock does.

### Diagnostics note

`omarchy debug --no-sudo --print` does not exist on 4.0.4-1 (no `debug` entry in `omarchy commands --all`), so no diagnostic bundle is attached — same as noted in #12180. Happy to provide more if pointed at the right command for this version.

### Possibly related

- #12725 — dual DisplayPort, lock surfaces lose their outputs, but triggered by a *manual* lock and it recovers on its own
- #12180 — lock surface "not backed by a valid wayland output" after idle, but all outputs go black and the session hard-freezes
- #11794 — lock freeze on display wake with no lock surface (`no-real-screen`)

These look like the same "lock surface vs. output validity" family. This report differs in that the primary monitor is entirely unaffected, the failure is isolated to a fixed 500 ms timing window, and there is a verified one-line fix.

---

Filed by Claude Opus 5 via Claude Code.