Fix ASUS ExpertBook B9406 touchpad quirk never being applied

[dhh]

Ports #6093 to quattro, with the fix mechanism changed. Original diagnosis and hardware verification by @mijuny.

On a fresh install of an ASUS ExpertBook B9406 the touchpad is dead: clicks register but the cursor never moves. The quirk from #5435 that masks the pad's bogus pressure axes never took effect.

Why it never applied

libinput scandirs /usr/share/libinput for *.quirks and additionally reads the single file /etc/libinput/local-overrides.quirks. It never scans /etc. The quirk was written to /etc/libinput/asus-expertbook-b9406.quirks, so it was silently ignored.

Verified against the installed libinput rather than taken from docs: built a probe against libinput.so, pointed LIBINPUT_QUIRKS_DIR at a copy of the data dir, and dropped in a deliberately malformed file under a name libinput does not ship. libinput failed quirks loading — proving it reads any *.quirks in that directory, not a fixed list.

Drop-in rather than appending to local-overrides

#6093 appends to local-overrides.quirks. That works, but it is the one file users edit by hand, and a shared file can only be updated idempotently by grepping for a section we already wrote — which silently pins the first version we ever shipped. If the quirk ever needs correcting, the grep matches the stale section and the fix never lands.

A drop-in at /usr/share/libinput/99-omarchy-asus-b9406-touchpad.quirks is a file we own outright, rewritten wholesale on every run. Consistent with how fix-z13-touchpad.sh owns its udev rule, and with the /usr/share/fontconfig/conf.avail, /usr/share/xdg-terminal-exec and /usr/lib/chromium drop-ins already shipped elsewhere.

MatchUdevType

Dropped, as in #6093: the pad's event node is tagged ID_INPUT_MOUSE, so a touchpad constraint skips the section. Bus, vendor, product and DMI already pin the device exactly, so the widened match is inert on any other hardware.

Worth flagging honestly: this claim sits uneasily with the original diagnosis, since the "Touch jump detected and discarded" message comes from libinput's touchpad backend, which only runs on devices tagged as touchpads. Most likely the pad exposes several event nodes. The reporter's confirmation also bundled both changes, so the evidence clearly supports the path fix and is only suggestive on this one. Kept because it costs nothing if unnecessary. Full touchpad classification (gestures, two-finger scroll) remains follow-up work.

Quattro porting

Three things in #6093 would not have worked here:

• sudo throughout — install/hardware/* runs as root (omarchy-setup-hardware hard-fails if EUID != 0).
• the migration sourced the leaf — migrations run as the user, so it now escalates explicitly.
• migration timestamp 1781432360 predates quattro's newest (1785095882) — renumbered.

Stale-file cleanup moved out of the install leaf into the migration; fresh installs never had that file.

Verification

• Quirks syntax parses cleanly under real libinput with MatchUdevType removed.
• Install leaf is idempotent — byte-identical file on rerun.
• Migration end to end with stubbed sudo: removes the stale file, writes the drop-in, exits 0.
• Migration on non-matching hardware exits 0 and writes nothing.
• test/shell.d/migrate-scope-test.sh passes; bash -n clean.

Not verified on the hardware itself — @mijuny's B9406 is currently broken. The path fix is mechanically proven; a confirmation on a live B9406 before merge would be ideal.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[dhh]

@mijuny — could you test this on a B9406 when you have one in hand? No rush if the ExpertBook is still out of action; I'd rather this sit than merge unverified.

The fix moves to a drop-in libinput actually reads, so the check is whether the cursor moves after a relogin:

# 1. Apply
sudo bash /usr/share/omarchy/install/hardware/asus/fix-asus-ptl-b9406-touchpad.sh

# 2. Confirm the drop-in landed and the stale file is gone
cat /usr/share/libinput/99-omarchy-asus-b9406-touchpad.quirks
ls /etc/libinput/

# 3. Relog, then confirm libinput applied it
libinput list-devices | grep -A5 -i touchpad

Two things beyond "cursor moves" that would be genuinely useful:

• sudo libinput record on the touchpad node, so we can see what udev actually tags it. That settles the MatchUdevType question I flagged — the ID_INPUT_MOUSE vs ID_INPUT_TOUCHPAD story doesn't quite line up with the original jump-detection diagnosis, and I suspect the pad exposes more than one event node.
• Whether two-finger scroll and tap-to-click work, or only pointer motion. If it's motion only, that confirms the device is being driven as a mouse and scopes the follow-up you mentioned.

If you'd rather test the migration path as an existing install would hit it:

rm -f ~/.local/state/omarchy/migrations/1785114924.sh
omarchy-migrate