### What's wrong?

After a long idle, I unlock and no window on the workspace takes keyboard input.

The window still looks focused. It keeps its focus border, the bar still names it, and `hyprctl activewindow` still reports it. But nothing I type reaches any client. Compositor keybinds still work, so the keyboard is fine.

Any workspace or window switch brings input back. `SUPER+2` then `SUPER+1` fixes it instantly. So does `SUPER+left/right`.

It doesn't happen on a short lock.

### Steps to reproduce

1. Focus a terminal on workspace 1 and leave the machine alone.
2. Let the screensaver (150s) and then the lock (300s) kick in.
3. Leave it locked at least 10 minutes.
4. Wake the display and unlock.
5. Try to type. Nothing lands.
6. Press `SUPER+2`, then `SUPER+1`. Typing works again.

### What I'd expect

After unlocking, the window Hyprland reports as active should hold keyboard focus. No manual workspace switch needed.

### System details

- Omarchy `4.0.1-1`, Hyprland `0.56.2-1`, quickshell `0.3.1-1`, kernel `7.1.8-arch1-3`
- Intel i9-9900K, NVIDIA RTX 4070, `nvidia-open-dkms` and `nvidia-utils` `610.57.04-1`
- Single monitor, LG UltraGear on `HDMI-A-1`, [email protected], scale 2
- Terminal is `foot`. Stock idle config: `{ "screensaver": 150, "lock": 300 }`
- No suspend involved. Machine was up 3 days straight across all of this.

### What the socket shows

I caught one with a capture running. Lock at 12:43:10, unlock at 12:56:23, so 13m13s. From `.socket2.sock`:

```
12:56:14 monitorremoved>>HDMI-A-1
12:56:14 focusedmon>>FALLBACK,4
12:56:14 monitoradded>>FALLBACK
12:56:14 activewindow>>,                <-- focus cleared
12:56:17 monitoradded>>HDMI-A-1
12:56:17 focusedmon>>HDMI-A-1,1
12:56:17 monitorremoved>>FALLBACK
                                        <-- no activewindow event, focus never comes back
12:56:23 (unlocked)
12:56:30 activewindow>>foot,...         <-- only after I switched windows by hand
```

The monitor drops out. Everything migrates to `FALLBACK` and Hyprland clears focus. The real monitor is back 3 seconds later. Focus is never restored. There's no `activewindow` event between `12:56:17` and my manual switch at `12:56:30`.

This `hyprctl` dump is from `12:56:24`, one second after the unlock, before I touched anything:

```
--- activewindow ---
{ "address": "0x5570ff79c070", "class": "foot", "workspace": { "id": 1, "name": "1" },
  "mapped": true, "visible": true, "acceptsInput": true, "focusHistoryID": 0, ... }
--- activeworkspace ---
{"id":1,"name":"1","lastwindow":"0x5570ff79c070"}
--- layers (overlay) ---
[{"mon":"HDMI-A-1","overlay":[]}]
```

So `hyprctl` names a window with `focusHistoryID: 0` and `acceptsInput: true`. The event stream says focus was cleared and never restored. That mismatch is the visible bug: the window keeps its border, the bar keeps its name, and no client gets a key. The overlay level is empty, so no stray layer is holding input.

The workspace disagrees too. The stream emits `workspace>>6` at `12:56:17`, the dump at `12:56:24` reports workspace `1`.

### How often

On wake from a long lock, `omarchy-shell` logs a full loss of outputs while still locked:

```
2026-08-30T12:56:14 kernel: nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed.
2026-08-30T12:56:14 omarchy-shell:  INFO qt.qpa.wayland: There are no outputs - creating placeholder screen
2026-08-30T12:56:18 omarchy-shell:  WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked.
2026-08-30T12:56:23 omarchy-shell: DEBUG qml: omarchy lock ... unlocked
```

There are 15 of these clusters this boot. 14 land seconds before an unlock. The odd one out is a wake I didn't unlock.

| Lock duration | Output dropped before unlock? |
| --- | --- |
| 5s, 8s, 14s, 19s, 1m48s | No (5/5) |
| 9m06s, 9m51s, 11m, 13m13s, 14m30s, 19m16s, 19m50s, 1h01m, 1h38m, 2h14m, 2h38m, 4h32m, 16h49m, 39h20m | Yes (14/14) |

Every lock over 9 minutes dropped the output. None of the five under 2 minutes did. I've got nothing between 2 and 9 minutes, so I don't know where the line sits.

One caveat on that table. It tracks output loss, read from the journal afterwards. It isn't a record of input dying. I only saw dead input on the times I came back and tried to type. The 13m13s row is the one with the trace above.

13 of the 15 clusters land on the same second as the `FRL link training failed` warning. Two don't, so that warning travels with these wakes but isn't required.

I couldn't force it on a short timescale. 80 seconds of `hl.dsp.dpms({ action = "disable" })` never dropped the output, and focus was fine after. I haven't tried a longer forced one.

### Upstream

Hyprland [discussion #15554](https://github.com/hyprwm/Hyprland/discussions/15554) is the same thing on a sole monitor. Same `FALLBACK` round trip, same `activewindow>>,`, same workspace switch to recover. It was closed with a Lua workaround after this reply:

> I don't think we enforce focus on monitor addition to not disrupt current state. With lua I think the workaround is totally reasonable

Reading that, I don't expect a fix upstream. Omarchy's idle lock is what puts the display into the state that leads to the round trip, so this felt like the right place to raise it.

One thing worth flagging: focus is already gone at `12:56:14`, before I authenticate. The unlock isn't losing it. It hands back a session that already has nothing focused. Whether the lock matters at all, I haven't tested.

Possibly related, same `FALLBACK` and output loss pattern: #7811 (similar dead keyboard input after lid-open resume), #7380 (shell crashes on `FALLBACK` removal at wake, mine survives), #8580 and #8946 (monitors dropping HPD after DPMS off).

### Happy to help

Could I put a PR together for this? I was thinking a `monitor.added` handler that re-asserts focus when a `FALLBACK` migration just happened, along the lines of the Lua workaround above. Happy to go another way if you'd rather 🤔