## Summary

After the laptop lid is opened (resume from suspend), the Omarchy lock screen appears but the password field does not have keyboard focus. Typing has no effect until the field is clicked with the mouse. Locking on demand while the screen is already on (e.g. via a keybinding or `omarchy system lock`) does not show this problem — the password field is focused automatically and typing works immediately, as expected.

## Steps to reproduce

1. Close the laptop lid (or otherwise suspend) with the session unlocked.
2. Wait for suspend to complete.
3. Open the lid.
4. Once the lock screen appears, type the password immediately (no mouse interaction).

**Expected:** Keystrokes go to the password field right away (this is how it behaves for an on-demand lock while awake).

**Actual:** Keystrokes are dropped. The password field is not visibly focused. Clicking into the field first is required before typing has any effect.

## Environment

- Omarchy: 4.0.1-1
- Hyprland: 0.56.2 (v0.56.2, commit efb50993780079460b0cbed1363e2166a2de1d9f)
- Kernel: 7.1.9-arch1-2
- CPU: 13th Gen Intel Core i5-13500H
- GPU: hybrid — Intel Raptor Lake-P (Iris Xe) + NVIDIA GeForce RTX 3050 6GB Laptop GPU
- Single internal display (eDP)

## Diagnostics

Journal around an actual lid-close/suspend/resume cycle from this session. Note `omarchy-sleep-lock.service` (the pre-suspend "lock and wait until secure" step) fails and restarts twice in the run-up to the successful suspend, i.e. the session does not appear to reach the `secure` state before the machine actually suspends:

```
Aug 26 20:23:37 systemd-logind[968]: Suspending...
Aug 26 20:23:38 systemd[1]: Starting System Suspend...
Aug 26 20:23:38 kernel: PM: suspend entry (s2idle)
Aug 26 20:27:30 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 26 20:27:30 systemd[1253]: Started Lock Omarchy before suspend.
Aug 26 20:27:30 kernel: random: crng reseeded on system resumption
Aug 26 20:27:30 kernel: PM: suspend exit
Aug 26 20:27:30 systemd[1253]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 1.
Aug 26 20:27:30 systemd[1253]: Started Lock Omarchy before suspend.
Aug 26 20:27:30 systemd[1253]: omarchy-sleep-lock.service: Main process exited, code=exited, status=1/FAILURE
Aug 26 20:27:30 systemd[1253]: omarchy-sleep-lock.service: Failed with result 'exit-code'.
Aug 26 20:27:32 systemd[1253]: omarchy-sleep-lock.service: Scheduled restart job, restart counter is at 2.
Aug 26 20:27:32 systemd[1253]: Started Lock Omarchy before suspend.
Aug 26 20:27:37 omarchy-shell[10798]: quickshell.service.pam.subprocess: Starting pam session for user "..." with config "omarchy-lock-password" in dir "/etc/pam.d"
Aug 26 20:27:37 omarchy-shell[10798]: quickshell.service.pam.subprocess: Authenticated successfully.
Aug 26 20:27:37 omarchy-shell[1456]:  DEBUG qml: omarchy lock 2026-08-27T03:27:37.542Z secure=false
Aug 26 20:27:37 omarchy-shell[1456]:  DEBUG qml: omarchy lock 2026-08-27T03:27:37.542Z session-locked=false
Aug 26 20:27:37 omarchy-shell[1456]:  DEBUG qml: omarchy lock 2026-08-27T03:27:37.542Z unlocked
```

This pattern (sleep-lock exiting 1 and being restarted right around the suspend/resume boundary) has recurred across separate suspend cycles on this machine, not just once.

## Possible cause (from reading the shipped shell source)

In `/usr/share/omarchy/shell/plugins/lock/LockView.qml`, the password `TextInput` is given active focus via `forceActiveFocus()` when `inputEnabled` (bound to `root.lockRequested` in `Service.qml`) becomes true — i.e. as soon as the lock is *requested*, not once the `WlSessionLock` surface has actually been mapped and granted exclusive keyboard focus by the compositor (`WlrLayershell.keyboardFocus: WlrKeyboardFocus.Exclusive`).

On an on-demand lock while the screen is already on and stable, that timing happens to work. On lid-open/resume, the display and compositor outputs are being re-established around the same time the lock surface is created, and `omarchy-sleep-lock` (which is supposed to have already secured the session *before* suspend, per the journal above) appears not to have finished that job in time — so the surface/focus setup may effectively be happening during the resume race rather than beforehand. Clicking into the field re-triggers focus only because `MouseArea.onClicked` in the same file explicitly calls `forcePasswordFocus()` again after things have settled.

This is a hybrid-GPU laptop (Intel + NVIDIA), which may make the resume path slower/more prone to this kind of timing race, if that's relevant to reproducing it elsewhere.

## Impact

Defeats keyboard-only use of the lock screen specifically after resume, which otherwise (per Omarchy's keyboard-driven design) does not require a mouse.