### System details

Lenovo Yoga Slim 7 Pro 14ACH5 (82MS), AMD Ryzen 9 5900HX + Radeon, BIOS GZCN27WW (2022-05-01),
Omarchy 4.0.4-1, kernel `7.2.5-3-omarchy`, Hyprland 0.56.2 / aquamarine.

Touchpad: `MSFT0001:00 06CB:CE44` (Synaptics I2C-HID) on AMD `AMDI0010:01` (`i2c-1`, Synopsys
DesignWare), handled by `i2c_hid_acpi` -> `hid-multitouch`. It exports the usual two input nodes:
`event7` = "…Mouse" (relative) and `event8` = "…Touchpad" (multitouch).

### What's wrong?

After a resume (`deep`/S3) — and also after a plain DPMS off/on with **no** suspend at all — the
touchpad keeps moving the pointer and keeps tap-to-click, but **multitouch stops being reported
entirely**: two-finger scroll and all 3-finger gestures die until the machine is rebooted (or the
driver is reseated by hand).

The kernel side looks completely healthy, which is what makes this confusing:

- No `i2c_hid` / `i2c_hid_acpi` / `hid-multitouch` errors on resume, in any boot in the journal.
- The device is never re-probed and stays bound: `0018:06CB:CE44.000N` in
  `/sys/bus/hid/drivers/hid-multitouch/`.
- Both input nodes still exist, and `event8` still advertises the full multitouch capability set
  (`ABS_MT_SLOT`, `ABS_MT_POSITION_X/Y`, `ABS_MT_TOOL_TYPE`, `ABS_MT_TRACKING_ID`).

But the pad stops sending its touch reports over the multitouch node and everything arrives over
the relative "Mouse" node instead — the "touchpad acts like a plain mouse" state.

### Evidence

Tally from `$XDG_RUNTIME_DIR/hypr/<hash>/hyprland.log` for the current boot (52378 lines), split on
every `[libinput] … Touchpad: device removed` line, which marks each time something reseated the
driver:

| log lines | `[2fg]` gesture lines | `touch 1` events | what bounded the segment |
|---|---|---|---|
| 1–517 | 0 | 0 | boot |
| 518–6644 | 831 | 311 | healthy |
| 6645–12135 | 1379 | 476 | healthy |
| 12136–13941 | 278 | 46 | manual `omarchy restart trackpad` |
| 13942–37294 | 2533 | 1215 | healthy |
| 37295–52378 | 1330 | 353 | today's post-resume rebind (my workaround) |

That table is what a *working* pad looks like — it is healthy because I reseated it after each
wake. The wedged state itself was measured on the previous boot of the same machine
(2026-09-17), and that's the interesting part:

- 06:37 — screen blanked and came back with **no suspend at all**: before that moment the pad had
  produced 912 `touch 1` events and normal `[2fg] SCROLL_START -> SCROLL`; after it, **0 `touch 1`
  and 0 `[2fg]`** for the rest of the session. Pointer + tap-to-click unaffected.
- 07:14:27 — a rebind fired in the same second as the kernel's `PM: suspend exit`. It re-probed the
  device and the log wrote `ok=1`, but a `[2fg]` count of 0 after that boundary confirms multitouch
  never came back.
- 07:30:17 — the same rebind 4 s later (after `systemctl is-system-running` reports `running`)
  restored it: `[2fg]` counts resume immediately afterwards.

In the wedged windows `event8` still exists and the only thing it logs is a storm of
`[libinput] event8 - palm: keyboard timeout` — the pad is alive but only reporting single-touch /
relative events. Compositor fingerprints seen around these events:

```
ERR [libinput] event8 - MSFT0001:00 06CB:CE44 Touchpad: kernel bug: Touch jump detected and discarded.
ERR [libinput] client bug: timer event8 keyboard: scheduled expiry is in the past (-1396ms), your system is too slow
DEBUG [libinput] event8 - MSFT0001:00 06CB:CE44 Touchpad: device removed
DEBUG [libinput] New device MSFT0001:00 06CB:CE44 Touchpad: 1739-52804
```

The DPMS-only wedge (no suspend) was observed on 2026-09-17 ~06:37: the touchpad reported 912
`touch 1` events and normal `[2fg] SCROLL_START -> SCROLL` before the screen blanked, and exactly 0
of both afterwards. So this is not only a `suspend.target` problem — a screen blank is enough.

### What already recovers it, and the timing gotcha

A driver reseat works, but **only if it runs once the system is fully awake**:

```
echo -n 'i2c-MSFT0001:00' | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/unbind
sleep 1
echo -n 'i2c-MSFT0001:00' | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind
```

Run in the same second as `PM: suspend exit` (07:14:27 that day, journal line identical to the
kernel's `PM: suspend exit`) it re-probes the device — HID instance goes `.0005` -> `.0006` — and
`hid-multitouch` takes it, but the pad stays wedged. Run ~4 s later (07:30:17, after
`systemctl is-system-running` reports `running`) the same commands fix it immediately
(`.0006` -> `.0007`), and `[2fg] … SCROLL_START -> SCROLL` comes back. So a naive post-resume hook
fired at the earliest possible moment is not enough; it has to wait for the resume to settle.

I'm currently running a local workaround (`/etc/systemd/system/touchpad-reset.service` +
`/usr/local/bin/touchpad-reset`: waits for systemd to settle, then unbind/bind only the I2C device
whose child input is named `*Touchpad*`, verifies the rebind, retries, falls back to a module
reload). It works for suspend, but it is local, I had to write it myself, it does not cover the
DPMS-only wedge, and every Omarchy user with this class of hardware has to rediscover it.

### Why this looks like an Omarchy-side gap (and the reason I'm filing here)

1. `omarchy restart trackpad` already exists and does exactly this reseat — but nothing runs it on
   resume. `/usr/lib/systemd/system-sleep/` only contains `keyboard-backlight` and `unmount-fuse`.
2. `#5453` (open) proposes precisely this shape for a Razer Blade AMD trackpad
   (`06CB:CDA3` on `AMDI0010`) as a DMI-gated `install/config/hardware/fix-*.sh` + post-resume hook.
   This is the same bug class on the same AMD I2C controller, different Synaptics HID — so a
   hardware fix already has a template, it just needs to either cover `06CB:CE44` or be made
   general for `AMDI0010`-hosted I2C-HID touchpads rather than vendor-triple-gated.
3. `#10924` (ASUS UM3406KA, `ASUP1206` I2C touchpad) reports the same user-visible outcome with an
   `i2c_hid_acpi` resume error in the log. Mine produces no kernel error at all, so it will never be
   caught by a log-matching fix; a resume hook has to be unconditional for the matched hardware.

### Secondary bug found while writing the workaround

`omarchy restart trackpad` loops over `/sys/bus/i2c/drivers/i2c_hid_acpi/i2c-*`, i.e. **every**
I2C-HID device, not just the touchpad. On this laptop the internal keyboard is on the same driver:

```
i2c-MSFT0001:00 -> i2c_hid_acpi   (touchpad, AMDI0010:01)
i2c-ITE8350:00  -> i2c_hid_acpi   (keyboard, AMDI0010:02)
```

So `omarchy restart trackpad` also unbinds/rebinds the built-in keyboard. It should select by the
child input device name (or skip devices whose HID usage is not a touchpad), the same scoping issue
that `#12029` / `#11836` raised for `omarchy-hw-touchpad`.

### Reproduction

1. Lid close (deep suspend), lid open.
2. Try two-finger scroll. Motion and tap-to-click work; scroll and gestures do nothing.
3. `grep -c '\[2fg\]' "$XDG_RUNTIME_DIR"/hypr/*/hyprland.log` does not move while scrolling;
   `event8` shows only `palm: keyboard timeout`, all real input is on `event7`.

### Suggested fix

Ship a hardware fix / resume hook that, for touchpads reached through `AMDI0010` I2C-HID where the
multi-report path silently goes stale (Synaptics `06CB:CE44` confirmed, `06CB:CDA3` from `#5453`,
ASUS `ASUP1206` from `#10924` as further candidates):

- rebinds `i2c_hid_acpi` for the touchpad device **only** (match the I2C device whose child input is
  named `*Touchpad*`, never the whole driver directory),
- does it after the resume has settled, not at the `suspend exit` instant, with a verify + retry,
- and is also reachable from DPMS blank, since that wedges it without any suspend.

Happy to hand over my script (`touchpad-reset` + unit) as a base if that's useful, and I can attach
a full `omarchy-debug` if wanted.