## What happens

The numeric keypad types nothing in every Omarchy shell surface that takes text
input — the polkit authentication dialog, the lock screen, and the launcher —
even though NumLock is on system-wide (LED lit, `hyprctl devices` reports
`numLock: true`, `input:numlock_by_default = true`).

Toggling NumLock off and on again makes the keypad work until the next dialog
appears, so anyone whose password contains digits typed on the keypad has to
perform that dance every single time they authenticate.

Letters and the top number row are unaffected.

## Root cause

This is not a NumLock configuration problem and not a Hyprland problem. It is
[QTBUG-32687](https://bugreports.qt.io/browse/QTBUG-32687): **Qt does not read
the system NumLock state at startup**, so it treats the keypad as NumLock-off
and delivers the cursor variants of the keys, which carry no text. A later
NumLock toggle is what syncs Qt's state.

Because the Omarchy shell is Quickshell (Qt/QML), every one of its text-input
surfaces inherits this.

## Evidence

I built a minimal Quickshell key probe that logs what actually arrives, and ran
it in two configurations. With NumLock **on** system-wide, pressing keypad `4`:

**A — layer-shell surface, `WlrKeyboardFocus.Exclusive`** (same as
`plugins/polkit/PolkitAgent.qml`):

```
scancode  83  Qt.Key 0x01000012  KEYPAD  mods 0x20000000  repeat non  texte (aucun texte)
scancode  38  Qt.Key 0x00000041  ------  mods 0x0         repeat non  texte 'a'
scancode  13  Qt.Key 0x00000034  ------  mods 0x0         repeat non  texte '4'
```

**B — ordinary `FloatingWindow` (xdg_toplevel)**:

```
scancode  83  Qt.Key 0x01000012  KEYPAD  mods 0x20000000  repeat non  texte (aucun texte)
```

`0x01000012` is `Qt::Key_Left`. Keypad `4` arrives as **left arrow with no
text**, identically in both cases, while the letter `a` and the top-row `4`
arrive correctly.

That the normal window fails the same way rules out layer-shell, exclusive
keyboard focus, and `wl_keyboard.enter` delivery. Stopping
`omarchy-fcitx5.service` changes nothing, ruling out fcitx5. What remains is Qt.

Cross-check: swapping the polkit agent for `mate-polkit` (GTK) makes the keypad
work immediately — a non-Qt agent is simply not subject to the bug.

## Why this is worth fixing in Omarchy

Qt has not fixed QTBUG-32687 in over a decade, so waiting upstream is not a
plan. The fix is small and local to the affected input fields.

It also explains two existing reports that were filed as separate NumLock or
keybinding problems:

- #3224 — "Numlock problem after boot and suspend": the lock screen is a
  Quickshell surface, so this is the same bug.
- #2542 — keypad keys not usable when unlocking.

Note that `hyprpolkitagent` is also Qt/QML and would reproduce the bug
identically, so it is not an alternative here.

## Suggested fix

In each text-input surface, map keypad keys back to their digits when
`Qt.KeypadModifier` is set. Applied to `PolkitAgent.qml`'s password field, this
resolves it (verified on my machine):

```qml
function keypadDigit(k) {
  switch (k) {
    case Qt.Key_Insert:   return "0"
    case Qt.Key_End:      return "1"
    case Qt.Key_Down:     return "2"
    case Qt.Key_PageDown: return "3"
    case Qt.Key_Left:     return "4"
    case Qt.Key_Clear:    return "5"
    case Qt.Key_Right:    return "6"
    case Qt.Key_Home:     return "7"
    case Qt.Key_Up:       return "8"
    case Qt.Key_PageUp:   return "9"
    case Qt.Key_Delete:   return "."
  }
  return ""
}

Keys.onPressed: function(event) {
  if (event.key === Qt.Key_Escape) { root.cancelRequest(); event.accepted = true; return }
  if ((event.modifiers & Qt.KeypadModifier) && !passwordInput.readOnly) {
    var d = passwordInput.keypadDigit(event.key)
    if (d !== "") {
      passwordInput.insert(passwordInput.cursorPosition, d)
      event.accepted = true
    }
  }
}
```

Scoping it to password/search fields keeps normal NumLock-off cursor behaviour
everywhere else. The lock screen and launcher need the same treatment.

I am happy to open a PR if the approach looks right.

## Steps to reproduce

1. Ensure NumLock is on (LED lit, `hyprctl devices` shows `numLock: true`).
2. Run `pkexec true`.
3. Type digits on the numeric keypad — nothing is entered.
4. Press NumLock twice, and the keypad now works until the dialog is dismissed.

## System

- Omarchy: 4.0.1-1
- Kernel: 7.1.9-arch1-2
- CPU: 13th Gen Intel(R) Core(TM) i9-13905H
- GPU: Intel Corporation Raptor Lake-P [Iris Xe Graphics] (rev 04);NVIDIA Corporation AD106M [GeForce RTX 4070 Max-Q / Mobile] (rev a1)
- Machine: LENOVO Yoga Pro 9 16IRP8
- Packages: hyprland 0.56.2-1,quickshell 0.3.1-1 qt6-base 6.11.2-2,qt6-declarative 6.11.2-1
- Keyboard layout: ch (variant fr)
- input:numlock_by_default: bool: true
- Keyboard numLock state per hyprctl: {True}

*Issue opened by Claude Code Agent*