Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
input.numlock_by_default = true mangles letters into digits on Apple keyboards with no numpad (hid-apple keypad emulation)
Reported by cheekychops · filed Aug 29, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
- CPU: Intel Core i5-3210M @ 2.50GHz
- GPU: Intel HD Graphics 4000 (Ivy Bridge)
- Machine: Apple Mac Mini (2012)
- Omarchy: 4.0.1-1 (
omarchy-settings4.0.1-1) - Architecture: x86_64
- Kernel: 7.1.9-arch1-2
- Hyprland: 0.56.2-1
- Keyboard: Apple Wireless Keyboard over Bluetooth, USB id
05ac:023a
What's wrong?
/usr/share/omarchy/default/hypr/input.lua:62 sets input.numlock_by_default = true
for every keyboard.
hid-apple applies numeric-keypad emulation to Apple keyboards, including models
that have no physical numpad. With numlock forced on at session start, the kernel
overlays a phantom keypad onto the letter keys, so ordinary typing produces digits.
Typing some keys are not sending the correct characters on the Apple keyboard
produces:
s60e 2eys are n6t send4ng the c6rrect charactersThe substitutions are o -> 6, m -> 0, k -> 2, i -> 4. The affected
keys are the ones hid-apple maps into its emulated keypad; the keyboard has no
numpad to make use of it, so the overlay only destroys letters.
Steps to reproduce
- Connect an Apple keyboard that has no numeric keypad (here: Apple Wireless
Keyboard, 05ac:023a, over Bluetooth).
2. Confirm the Omarchy default is in effect - hyprctl devices shows numLock: yes
for that keyboard, and /sys/class/leds/*numlock*/brightness reads 1.
3. Type letters, including o, k, m, i.
Expected result
Letter keys produce letters. A keyboard with no numeric keypad should not have
numlock forced on, since it can only misfire there.
Actual result
Letter keys produce digits, as above. The keyboard is unusable for typing until
numlock is turned off.
Workaround
Scope numlock off to the affected device in ~/.config/hypr/input.lua, rather
than disabling it globally (a global numlock_by_default = false would turn a
real numpad into arrow keys):
hl.device({ name = "<name from hyprctl devices>", numlock_by_default = false })Verified with hyprctl reload && hyprctl configerrors (clean). Afterwardshyprctl devices reports numLock: no for that device only, the numlock LED
goes 1 -> 0, and typing is correct.
Notes
- Closely related in spirit to #7110, where
fnmode=2is forced on every install
and misfires on Apple keyboards. Both are global input defaults that assume
non-Apple hardware.
- This is the inverse of #8552, #7162 and #8176, which are all about NumLock being
ignored so a numpad won't type digits. Here the problem is numlock being
applied to a keyboard that has no numpad at all.
View raw text
### System details
- CPU: Intel Core i5-3210M @ 2.50GHz
- GPU: Intel HD Graphics 4000 (Ivy Bridge)
- Machine: Apple Mac Mini (2012)
- Omarchy: 4.0.1-1 (`omarchy-settings` 4.0.1-1)
- Architecture: x86_64
- Kernel: 7.1.9-arch1-2
- Hyprland: 0.56.2-1
- Keyboard: Apple Wireless Keyboard over Bluetooth, USB id `05ac:023a`
### What's wrong?
`/usr/share/omarchy/default/hypr/input.lua:62` sets `input.numlock_by_default = true`
for every keyboard.
`hid-apple` applies numeric-keypad emulation to Apple keyboards, including models
that have no physical numpad. With numlock forced on at session start, the kernel
overlays a phantom keypad onto the letter keys, so ordinary typing produces digits.
Typing `some keys are not sending the correct characters` on the Apple keyboard
produces:
```text
s60e 2eys are n6t send4ng the c6rrect characters
```
The substitutions are `o` -> `6`, `m` -> `0`, `k` -> `2`, `i` -> `4`. The affected
keys are the ones `hid-apple` maps into its emulated keypad; the keyboard has no
numpad to make use of it, so the overlay only destroys letters.
### Steps to reproduce
1. Connect an Apple keyboard that has no numeric keypad (here: Apple Wireless
Keyboard, `05ac:023a`, over Bluetooth).
2. Confirm the Omarchy default is in effect - `hyprctl devices` shows `numLock: yes`
for that keyboard, and `/sys/class/leds/*numlock*/brightness` reads `1`.
3. Type letters, including `o`, `k`, `m`, `i`.
### Expected result
Letter keys produce letters. A keyboard with no numeric keypad should not have
numlock forced on, since it can only misfire there.
### Actual result
Letter keys produce digits, as above. The keyboard is unusable for typing until
numlock is turned off.
### Workaround
Scope numlock off to the affected device in `~/.config/hypr/input.lua`, rather
than disabling it globally (a global `numlock_by_default = false` would turn a
real numpad into arrow keys):
```lua
hl.device({ name = "<name from hyprctl devices>", numlock_by_default = false })
```
Verified with `hyprctl reload && hyprctl configerrors` (clean). Afterwards
`hyprctl devices` reports `numLock: no` for that device only, the numlock LED
goes `1` -> `0`, and typing is correct.
### Notes
- Closely related in spirit to #7110, where `fnmode=2` is forced on every install
and misfires on Apple keyboards. Both are global input defaults that assume
non-Apple hardware.
- This is the inverse of #8552, #7162 and #8176, which are all about NumLock being
*ignored* so a numpad won't type digits. Here the problem is numlock being
applied to a keyboard that has no numpad at all.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 09:52 UTC