Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-909GitHub issuePublicDecided· Out of scope

Stock XF86TouchpadToggle binding never fires (Hyprland resolve_binds_by_sym defaults to false)

Reported by mlusetti · filed Sep 6, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 days ago.

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

Stock XF86TouchpadToggle binding never fires (Hyprland resolve_binds_by_sym defaults to false)revision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

The stock touchpad bindings in default/hypr/bindings/media.lua never fire:

o.bind_toggle("XF86TouchpadToggle", "Toggle touchpad", "touchpad", { locked = true })
o.bind("XF86TouchpadOn", "Enable touchpad", "omarchy-toggle-touchpad on", { locked = true })
o.bind("XF86TouchpadOff", "Disable touchpad", "omarchy-toggle-touchpad off", { locked = true })

Pressing the touchpad hotkey (Fn+F1 on a System76 Serval WS) does nothing — no OSD, no state change, no error.

Expected

Fn+F1 toggles the touchpad and shows the "Touchpad disabled" / "Touchpad enabled" OSD.

Cause

Hyprland's input:resolve_binds_by_sym defaults to false, and with it off the bind on XF86TouchpadToggle never matches. Omarchy never sets the option — grep -rn resolve_binds_by_sym /usr/share/omarchy/ returns nothing — so every install gets the default and the three bindings above are dead out of the box.

Setting it fixes all three immediately:

hl.config({ input = { resolve_binds_by_sym = true } })

Everything else in the chain is fine

Verified step by step on this machine:

  • The EC emits atkbd scancode f7/f8; systemd's 60-keyboard.hwdb (svnSystem76*) maps both to touchpad_toggle.
  • The kernel delivers KEY_TOUCHPAD_TOGGLE (530) — confirmed by reading /dev/input/event4 directly.
  • Hyprland's live keymap (xkbcli dump-keymap-wayland) contains key <I538> { [ XF86TouchpadToggle ] };.
  • hyprctl binds shows the bind registered: bindld … key: XF86TouchpadToggle.
  • omarchy-toggle-touchpad works correctly when run directly (OSD, device disabled, state file written).
  • hyprctl getoption input:resolve_binds_by_sym → bool: false / set: false before, true after.
  • A notify-send probe bound to the same keysym fires on Fn+F1 only when the option is true.

Likely mechanism

XF86TouchpadToggle sits at XKB keycode 538 (evdev 530), above the classic 255 keycode ceiling. With resolve_binds_by_sym = false, Hyprland matches binds through a keysym→keycode reverse lookup that appears not to reach that range. The low-keycode media binds in the same file — XF86AudioRaiseVolume (123), XF86MonBrightnessUp (233) — work fine under the same setting.

I have not confirmed this in Hyprland's source, so treat the mechanism as a hypothesis. The behavioural difference itself is reproducible and is what the fix rests on.

Steps to reproduce

On any laptop whose touchpad hotkey emits KEY_TOUCHPAD_TOGGLE:

  1. Confirm the key produces keycode 530 (evtest on the keyboard's event device).
  2. Press the hotkey — nothing happens.
  3. hyprctl eval 'hl.config({ input = { resolve_binds_by_sym = true } })'
  4. Press again — the touchpad toggles and the OSD appears.

Suggested fix

Ship resolve_binds_by_sym = true in Omarchy's Hyprland input defaults, or bind the touchpad keys by keycode instead of keysym.

System

  • Omarchy 4.0.2-1
  • Hyprland 0.56.2 (efb5099, v0.56.2)
  • Kernel 7.1.9-arch1-2
  • System76 Serval WS (serw14), Intel Core Ultra 9 275HX
  • Intel Arrow Lake-S graphics + NVIDIA RTX 5070 Ti Mobile

(Note: contributing.md in the docs still references omarchy debug --no-sudo --print, which no longer exists in 4.0.2 — hence the hand-collected details above.)

View raw text
## What happened

The stock touchpad bindings in `default/hypr/bindings/media.lua` never fire:

```lua
o.bind_toggle("XF86TouchpadToggle", "Toggle touchpad", "touchpad", { locked = true })
o.bind("XF86TouchpadOn", "Enable touchpad", "omarchy-toggle-touchpad on", { locked = true })
o.bind("XF86TouchpadOff", "Disable touchpad", "omarchy-toggle-touchpad off", { locked = true })
```

Pressing the touchpad hotkey (Fn+F1 on a System76 Serval WS) does nothing — no OSD, no state change, no error.

## Expected

Fn+F1 toggles the touchpad and shows the "Touchpad disabled" / "Touchpad enabled" OSD.

## Cause

Hyprland's `input:resolve_binds_by_sym` defaults to `false`, and with it off the bind on `XF86TouchpadToggle` never matches. Omarchy never sets the option — `grep -rn resolve_binds_by_sym /usr/share/omarchy/` returns nothing — so every install gets the default and the three bindings above are dead out of the box.

Setting it fixes all three immediately:

```lua
hl.config({ input = { resolve_binds_by_sym = true } })
```

## Everything else in the chain is fine

Verified step by step on this machine:

- The EC emits atkbd scancode `f7`/`f8`; systemd's `60-keyboard.hwdb` (`svnSystem76*`) maps both to `touchpad_toggle`.
- The kernel delivers `KEY_TOUCHPAD_TOGGLE` (530) — confirmed by reading `/dev/input/event4` directly.
- Hyprland's live keymap (`xkbcli dump-keymap-wayland`) contains `key <I538> { [ XF86TouchpadToggle ] };`.
- `hyprctl binds` shows the bind registered: `bindld … key: XF86TouchpadToggle`.
- `omarchy-toggle-touchpad` works correctly when run directly (OSD, device disabled, state file written).
- `hyprctl getoption input:resolve_binds_by_sym` → `bool: false / set: false` before, `true` after.
- A `notify-send` probe bound to the same keysym fires on Fn+F1 only when the option is `true`.

## Likely mechanism

`XF86TouchpadToggle` sits at XKB keycode 538 (evdev 530), above the classic 255 keycode ceiling. With `resolve_binds_by_sym = false`, Hyprland matches binds through a keysym→keycode reverse lookup that appears not to reach that range. The low-keycode media binds in the same file — `XF86AudioRaiseVolume` (123), `XF86MonBrightnessUp` (233) — work fine under the same setting.

I have not confirmed this in Hyprland's source, so treat the mechanism as a hypothesis. The behavioural difference itself is reproducible and is what the fix rests on.

## Steps to reproduce

On any laptop whose touchpad hotkey emits `KEY_TOUCHPAD_TOGGLE`:

1. Confirm the key produces keycode 530 (`evtest` on the keyboard's event device).
2. Press the hotkey — nothing happens.
3. `hyprctl eval 'hl.config({ input = { resolve_binds_by_sym = true } })'`
4. Press again — the touchpad toggles and the OSD appears.

## Suggested fix

Ship `resolve_binds_by_sym = true` in Omarchy's Hyprland input defaults, or bind the touchpad keys by keycode instead of keysym.

## System

- Omarchy 4.0.2-1
- Hyprland 0.56.2 (`efb5099`, v0.56.2)
- Kernel 7.1.9-arch1-2
- System76 Serval WS (serw14), Intel Core Ultra 9 275HX
- Intel Arrow Lake-S graphics + NVIDIA RTX 5070 Ti Mobile

(Note: `contributing.md` in the docs still references `omarchy debug --no-sudo --print`, which no longer exists in 4.0.2 — hence the hand-collected details above.)

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 10:56 UTC