## What happened

After a real suspend/resume (lid close, then reopen), the numpad does not produce digits on the lock screen's password field — pressing e.g. `KP_7` acts like a navigation key (Home/etc.) instead of typing `7`. Pressing the physical Num Lock key twice (off, then back on) fixes it immediately.

This is specific to suspend/resume, not lock screens in general:

- Plain `SUPER`-bound lock / idle-triggered lock, with no suspend involved: numpad works correctly on the lock screen, no issue.
- Lid-close suspend → reopen: numpad broken on the lock screen every time, until manually toggling Num Lock.
- Once logged in (past the lock screen), the numpad works correctly on its own — no manual Num Lock toggle needed post-login, even when it was never touched at the lock screen. So whatever is wrong resolves itself the moment a fresh desktop session surface exists; it's confined to the lock surface itself.

## What I expected

Numpad digit entry to work on the lock screen after resume, matching its behavior after a plain lock/unlock.

## Diagnosis attempted

`hyprctl devices -j` exposes a per-keyboard-device `numLock` boolean. I captured it immediately after logging in past a broken lock screen (before manually touching Num Lock):

```
video-bus                      main=false  numLock=true
video-bus-1                    main=false  numLock=true
intel-hid-events               main=false  numLock=true
intel-hid-5-button-array       main=false  numLock=true
power-button                   main=false  numLock=true
sleep-button                   main=false  numLock=true
at-translated-set-2-keyboard   main=false  numLock=true
msi-wmi-hotkeys                main=false  numLock=true
hl-virtual-keyboard-fcitx5     main=true   numLock=true
```

Every device, including the one flagged `main`, reports `numLock: true`. So whatever Hyprland exposes via introspection is already fully consistent by the time I could check — yet the numpad had just been producing wrong output moments earlier on the lock screen. This means the reported/LED-facing numlock state and the state actually applied when translating a physical numpad scancode to a keysym are able to diverge, at least on the lock surface, in a way `hyprctl devices` cannot see.

I could not capture `hyprctl devices -j` *while* the lock screen itself was still broken, because there is (deliberately) no way to open a terminal from the lock screen. So I only have the "already recovered" snapshot above, not a snapshot of the actual broken moment.

Things I tried that did **not** fix it, for what it's worth:
- Replaying a synthetic `wtype -k Num_Lock -k Num_Lock` keypress on the unlock transition (works fine for a plain lock/unlock, does nothing for the post-suspend lock-screen case)
- Retrying that synthetic keypress several times over ~3 seconds after unlock
- `hyprctl eval 'hl.config({ input = { numlock_by_default = ... } })'` toggled off/on — confirmed via `hyprctl devices -j` that this does *not* retroactively re-apply to an already-connected keyboard device
- `hyprctl reload` — same, no effect on already-connected devices' numLock field

My working theory (unconfirmed): `numlock_by_default` only applies when a keyboard device is freshly added, and a real suspend/resume tears down and recreates the physical keyboard's input device; if that recreation doesn't correctly land before/against the still-live lock surface's own keyboard state, the lock surface could be reading a stale snapshot that a synthetic keypress (routed through a different virtual device) never touches, while a **real** physical keypress does, since it goes through the compositor's normal input pipeline rather than a synthetic-injection path. I was not able to verify this internally without deeper Hyprland-side tooling.

## System details

- Omarchy 4.0.2-1
- Hyprland 0.56.2 (v0.56.2, commit `efb50993780079460b0cbed1363e2166a2de1d9f`)
- quickshell 0.3.1-1
- Kernel: 7.1.9-arch1-2
- CPU: 13th Gen Intel Core i7-13620H
- GPU: Intel UHD Graphics (Raptor Lake-P) + NVIDIA GeForce RTX 4070 Max-Q (nvidia-open-dkms 610.57.04-1) — hybrid laptop, internal panel driven by the Intel iGPU
- Single internal display (eDP), no external monitors involved in reproduction

## Steps to reproduce

1. Close the laptop lid (or `systemctl suspend`) with a lock screen already showing or set to show on suspend.
2. Reopen the lid / wake the machine.
3. At the lock screen, try typing a numpad digit (e.g. `KP_7`) into the password field.
4. Observe it does not type a digit (behaves like a non-numpad key).
5. Press the physical Num Lock key twice — numpad now works correctly for the rest of the lock screen interaction.
6. Log in. Numpad continues to work correctly with no further action, even though it was never fixed post-login specifically.