[stevederico]

Refs #13398

omarchy restart trackpad only rebound devices on i2c_hid_acpi. A touchpad bound to elan_i2c, common on ASUS laptops, was skipped, and the command printed nothing and exited 0.

This rebinds touchpads on elan_i2c as well, keeping the touchpad-only filter from #17284. elan_i2c puts its input device on the I2C device itself, not under a HID child, so is_touchpad now checks there too. Devices without an ACPI companion, like the ELAN SMBus companion psmouse creates, are named <bus>-<addr> (0-0015), so the loop matches any entry with a dash. Failing loudly when no device is found is left to #9409, which edits the same loop.

Test plan

• bash test/shell.d/restart-trackpad-test.sh: the existing fixture now also has an elan_i2c touchpad named 0-0015. Only the two touchpads are unbound and rebound; the HID keyboard and touchscreen are left alone. Fails on quattro and with an i2c-* glob
• The test override is now OMARCHY_I2C_DRIVERS_PATH (the drivers root), since the script reads two drivers
• Not tried on ELAN hardware

[llstrk]

Automated AI review

Community review: Independent automated community review, unaffiliated with the Omarchy team, intended to help prepare PRs for their review.

Outcome: elan_i2c touchpads that the kernel names <bus>-<addr> (for example SMBus ones) are still skipped silently with exit 0.

The i2c-* glob misses elan_i2c devices without an ACPI name

The kernel names an I2C client i2c-<name> only when its board info sets dev_name or it has an ACPI companion; otherwise it is <adapter>-<addr> (i2c_dev_set_name, drivers/i2c/i2c-core-base.c). psmouse's elantech driver creates the SMBus companion as I2C_BOARD_INFO("elan_i2c", 0x15) with neither, so it appears as elan_i2c/<bus>-0015 (for example 0-0015), and the loop never matches it. The Omarchy kernel config enables this path (CONFIG_MOUSE_ELAN_I2C_SMBUS=y). The reported ACPI device (i2c-ELAN1000:00) is covered.

Suggested change: glob /sys/bus/i2c/drivers/$driver/*-* and add a 0-0015 case to the test.

Reproducer (fails at 491497c)

Appended to the end of test/shell.d/restart-trackpad-drivers-test.sh (reuses its scratch, CALL_LOG and run_reset):

rmdir "$scratch/drivers/i2c_hid_acpi/i2c-SYNA2BA6:00"
mkdir "$scratch/drivers/elan_i2c/0-0015"
run_reset
[[ $(<"$CALL_LOG") == "$scratch/drivers/elan_i2c/unbind < 0-0015
$scratch/drivers/elan_i2c/bind < 0-0015" ]] ||
  fail "an elan_i2c touchpad on SMBus (0-0015) is unbound and rebound" "$(<"$CALL_LOG")"
pass "an elan_i2c touchpad on SMBus (0-0015) is unbound and rebound"

Output at 491497c (bash test/shell.d/restart-trackpad-drivers-test.sh, exit 1):

ok - an elan_i2c touchpad is unbound and rebound
ok - an i2c_hid_acpi touchpad is still unbound and rebound
not ok - an elan_i2c touchpad on SMBus (0-0015) is unbound and rebound

With the inner loop changed to for dev in /sys/bus/i2c/drivers/$driver/*-*; do, the same file prints all three lines as ok and exits 0. That the rebind actually resets an SMBus pad is inferred from source (bind re-runs elan_probe), not tested on hardware.

Details

Why *-* is safe: an i2c driver directory otherwise holds only bind, unbind, uevent and module; neither driver adds attributes.

Overlapping open PRs:

• Fail clearly when trackpad reset finds no supported driver #9409 edits the same loop (one textual conflict). After a hand merge, its test's sed pattern for i2c_hid_acpi/i2c-* no longer matches, so its copy scans the real /sys/bus/i2c/drivers/{i2c_hid_acpi,elan_i2c} (writes stay stubbed), and it fails on hosts with a device on either driver. Its error message still names only i2c_hid_acpi or intel_quicki2c.
• Reset elan_i2c trackpads and fail clearly when none match #13600 ("Fixes omarchy restart trackpad silently does nothing on elan_i2c touchpads #13398") makes the same two-driver change plus the fail-loud exit, conflicts textually with this PR and has the same i2c-* glob.

Verified:

• The new test passes at the head and fails with the merge-base script (not ok - an elan_i2c touchpad is unbound and rebound).
• i2c_hid_acpi-only and THC-only runs make the same calls and print the same output as the merge-base.
• With devices on both drivers, both are reset (i2c_hid_acpi first).
• The test's sed rewrites every sysfs path in the script, and sudo, sleep and lsmod are stubbed, so no real write can happen.
• bin-style-test.sh and privileged-heredoc-test.sh pass at the head.

Optional notes:

• The test never has devices on both drivers at once, so a mutant that stops after the first device (echo "Done"; break 2) passes it. This case kills that mutant and passes at the head:

rmdir "$scratch/drivers/i2c_hid_acpi/i2c-SYNA2BA6:00"
mkdir "$scratch/drivers/i2c_hid_acpi/i2c-WACF2200:00" "$scratch/drivers/elan_i2c/i2c-ELAN1000:00" "$scratch/drivers/elan_i2c/i2c-ELAN0000:00"
run_reset
[[ $(<"$CALL_LOG") == "$scratch/drivers/i2c_hid_acpi/unbind < i2c-WACF2200:00
$scratch/drivers/i2c_hid_acpi/bind < i2c-WACF2200:00
$scratch/drivers/elan_i2c/unbind < i2c-ELAN0000:00
$scratch/drivers/elan_i2c/bind < i2c-ELAN0000:00
$scratch/drivers/elan_i2c/unbind < i2c-ELAN1000:00
$scratch/drivers/elan_i2c/bind < i2c-ELAN1000:00" ]] ||
  fail "every device on both drivers is unbound and rebound" "$(<"$CALL_LOG")"
pass "every device on both drivers is unbound and rebound"

• A failed bind write still prints Done and exits 0, which the menu shows as done while the pad stays unbound. This is pre-existing, now also on the elan_i2c path.

---

Review information

Test scope: Source code and sandbox tests with a fake sysfs tree only, at 491497c7; not tested on hardware.

AI process: Opus 5.5 Medium coordination and synthesis, Opus 5.5 Xhigh technical review and final fact check, GPT 6 Sol Xhigh search for related issues, Opus 5.5 Medium editorial check.

Opt out: To stop receiving these reviews, reply to this comment saying so.

[stevederico]

Thanks, good catch. Fixed in 8e4d112: the glob is now *-*, so <bus>-<addr> devices like 0-0015 are rebound too. Added a 0-0015 case, and the test now puts bind, unbind, and uevent in the fake driver directories to show they are never touched.

[omarchybot]

Reviewed at 8e4d1127aad0324404d4bd9c486f6278a0e7e929 by Claude Opus 5.5, with Codex Medium as a second opinion. The change does what it says, and no defect was found. Because the bug lives on ELAN hardware no worker has, it now waits for @kianlabs to confirm it on the laptop from #13398.

What was checked, on a disposable Omarchy worker VM:

• A fake-sysfs reproduction written for this review, separate from the PR's test. On the base (quattro at 97a9fce5), an elan_i2c device named i2c-ELAN1000:00 or 0-0015 is never unbound or rebound. At this head both are, an i2c_hid_acpi device still is, and with devices on both drivers all three are reset in turn. Nothing is ever written to the driver's own bind, unbind, uevent or module entries. Putting the glob back to i2c-* brings the 0-0015 failure back, so both halves of the change matter.
• test/shell.d/restart-trackpad-drivers-test.sh passes at the head and fails against the base script. bin-style-test.sh and privileged-heredoc-test.sh pass.
• ./test/cli stops at "vscode generated theme references current theme file" on the worker. It does so identically on the base, on current quattro, and on this branch merged into it, so the failure predates this change. With that block set aside, the remaining 114 checks pass on head and base alike.
• On the worker's real sysfs, which has neither driver, the script exits 0 without touching anything, as before.

The second opinion read this PR, #13600 and #9409 side by side and found no defect here. Where it agreed with this review, its independence is not guaranteed. It added one point this review had missed: #13600's test stub for sudo runs the real tee, so if that PR's sysfs override ever stopped being honoured, its test would write to real sysfs.

Related pull requests:

• Reset elan_i2c trackpads and fail clearly when none match #13600 makes the same two-driver change. Its i2c-* glob misses elan_i2c devices the kernel names <bus>-<addr>, such as the psmouse SMBus companion at 0x15. It also adds test-only environment variables to the command. This PR covers both naming forms with a smaller change.
• Fail clearly when trackpad reset finds no supported driver #9409 is a separate fix: it makes the command fail loudly when nothing was reset. It conflicts textually with this PR. If both land, Fail clearly when trackpad reset finds no supported driver #9409's test sed pattern no longer matches this loop, so the test would read real sysfs, and its error message would also need to name elan_i2c. Which order they land in is for the maintainer.
• This PR says "Refs omarchy restart trackpad silently does nothing on elan_i2c touchpads #13398" rather than "Fixes" because the fail-loudly half of that issue is left to Fail clearly when trackpad reset finds no supported driver #9409, so the issue has not been linked to close on merge.

@kianlabs, could you run the script from this exact commit on your GL752VL and say whether the touchpad is reset?

curl -fsSL https://raw.githubusercontent.com/stevederico/omarchy/8e4d1127aad0324404d4bd9c486f6278a0e7e929/bin/omarchy-restart-trackpad -o /tmp/omarchy-restart-trackpad
bash /tmp/omarchy-restart-trackpad; echo "exit $?"
journalctl -k -n 20 | grep -i elan

It should print Resetting i2c-ELAN1000:00 via elan_i2c unbind/rebind... and Done. The kernel log should then show the Elan Touchpad: Module ID line again, from the rebind. Once you confirm, the decision passes to the maintainer.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Extends omarchy restart trackpad to reset touchpads using elan_i2c.

• Trackpad restart now resets touchpads on ELAN and HID-over-I2C drivers.

stevederico explicitly deferred reporting an error when no device is found to #9409.

Review was based on code inspection. Tests and ELAN hardware checks were not run.

_{Reviews (1) · Last reviewed commit: "Reset elan_i2c touchpads named by bus an..." · Reviewed by Greptile}