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.
Touchpad toggle leaves -mouse sibling enabled, causes 2-finger-move / 3-finger-scroll state
Reported by mhuggins7278 · filed Sep 17, 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
Touchpad toggle only disables -touchpad node, leaves -mouse sibling enabled → finger-count desync
Omarchy: 4.0.4-1
Hyprland: 0.56.2
Hardware: MSFT0001:00 093A:0255 (I2C Precision Touchpad, hid-multitouch)
What happened
Toggling the touchpad off/on (SUPER+SHIFT+T, XF86TouchpadToggle, or omarchy toggle touchpad) intermittently leaves the touchpad in a state where 1 finger does nothing, 2 fingers move the cursor, and 3 fingers scroll. Toggling off/on a second time restores normal behavior.
Steps to reproduce
hyprctl devices -jshows two devices for one physical touchpad:
msft0001:00-093a:0255-touchpadmsft0001:00-093a:0255-mouse(kernel mouse-emulation node:/proc/bus/input/devicesshowsMSFT0001:00 093A:0255 MousewithEV=17 REL=1943alongside... TouchpadwithID_INPUT_TOUCHPAD=1)
omarchy toggle touchpad off→ only the-touchpadnode is disabled (omarchy-hw-touchpadreturnsfirst(select(test("touchpad|trackpad"))),omarchy-toggle-input-deviceapplieshl.device(enabled=false)to that one name only). The-mousesibling stays enabled.omarchy toggle touchpad on→ only-touchpadre-enabled.- After some cycles, finger tracking is off by one (matches
hyprwm/Hyprland#7459: ghost/stuck finger ini2c_hid/hid-multitouch+ libinput).
Expected
Toggle fully disables the physical touchpad (both -touchpad and its -mouse emulation sibling), re-enables both together, and persists both across hyprctl reload (currently disabled-input-device.lua only re-applies the single name in touchpad-disabled-name).
Suggested fix
In omarchy-toggle-input-device / omarchy-hw-touchpad, detect sibling(s) sharing the same base name (e.g. msft0001:00-093a:0255-mouse for msft0001:00-093a:0255-touchpad) and apply hl.device(enabled=...) to all of them; persist the sibling list alongside touchpad-disabled-name so disabled-input-device.lua re-applies it on reload.
Local workaround used
Wrapper toggling both nodes + a hyprland.lua snippet re-disabling the sibling file on reload + rebinding SUPER+SHIFT+T / XF86Touchpad* to the wrapper. Happy to PR this approach.
View raw text
## Touchpad toggle only disables `-touchpad` node, leaves `-mouse` sibling enabled → finger-count desync
**Omarchy:** 4.0.4-1
**Hyprland:** 0.56.2
**Hardware:** MSFT0001:00 093A:0255 (I2C Precision Touchpad, `hid-multitouch`)
### What happened
Toggling the touchpad off/on (`SUPER+SHIFT+T`, `XF86TouchpadToggle`, or `omarchy toggle touchpad`) intermittently leaves the touchpad in a state where 1 finger does nothing, 2 fingers move the cursor, and 3 fingers scroll. Toggling off/on a second time restores normal behavior.
### Steps to reproduce
1. `hyprctl devices -j` shows two devices for one physical touchpad:
- `msft0001:00-093a:0255-touchpad`
- `msft0001:00-093a:0255-mouse` (kernel mouse-emulation node: `/proc/bus/input/devices` shows `MSFT0001:00 093A:0255 Mouse` with `EV=17 REL=1943` alongside `... Touchpad` with `ID_INPUT_TOUCHPAD=1`)
2. `omarchy toggle touchpad off` → only the `-touchpad` node is disabled (`omarchy-hw-touchpad` returns `first(select(test("touchpad|trackpad")))`, `omarchy-toggle-input-device` applies `hl.device(enabled=false)` to that one name only). The `-mouse` sibling stays enabled.
3. `omarchy toggle touchpad on` → only `-touchpad` re-enabled.
4. After some cycles, finger tracking is off by one (matches `hyprwm/Hyprland#7459`: ghost/stuck finger in `i2c_hid`/`hid-multitouch` + libinput).
### Expected
Toggle fully disables the physical touchpad (both `-touchpad` and its `-mouse` emulation sibling), re-enables both together, and persists both across `hyprctl reload` (currently `disabled-input-device.lua` only re-applies the single name in `touchpad-disabled-name`).
### Suggested fix
In `omarchy-toggle-input-device` / `omarchy-hw-touchpad`, detect sibling(s) sharing the same base name (e.g. `msft0001:00-093a:0255-mouse` for `msft0001:00-093a:0255-touchpad`) and apply `hl.device(enabled=...)` to all of them; persist the sibling list alongside `touchpad-disabled-name` so `disabled-input-device.lua` re-applies it on reload.
### Local workaround used
Wrapper toggling both nodes + a `hyprland.lua` snippet re-disabling the sibling file on reload + rebinding `SUPER+SHIFT+T` / `XF86Touchpad*` to the wrapper. Happy to PR this approach.
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 15:04 UTC