Fixing the ThinkPad T14 AMD touchpad on Omarchy

The ThinkPad T14 AMD Touchpad Fix on Omarchy

thinkpad-t14-amd-touchpad-dkms is a DKMS package (version 0.2.3-1, by orospakr, packaged for Omarchy) that fixes the ThinkPad T14/P14s Gen 1 and Gen 2 AMD touchpad by switching it from the sluggish PS/2 fallback to RMI4 over SMBus — with the TrackPoint still working on its pass-through.

TL;DR

omarchy pkg add thinkpad-t14-amd-touchpad-dkms

Reboot, then run thinkpad-t14-amd-touchpad-check to confirm the pad is on the RMI4 transport. This is for one specific family of machines: ThinkPad T14 Gen 2a/Gen 2 AMD and T14/P14s Gen 1 AMD with a Synaptics pad (TM3471-030, PnP IDs LEN2073 / LEN2064). If that’s not your machine, this package does nothing for you. Free and open (GPL-2.0-only). Honest framing from the repo itself: this is a carry, not a fork — every patch is aimed at a specific upstream tree, and the package exists only until stock Omarchy/Arch kernels drive the pad over SMBus on their own.

Getting started (5 minutes — plus a reboot)

1. Check you have the right hardware.

This is only for ThinkPad T14 Gen 2a / Gen 2 AMD, T14 Gen 1 AMD, and P14s Gen 1/Gen 2 AMD with a Synaptics pad. The shape that matters: an AMD FCH SMBus controller (1022:790b) and a Synaptics pad that supports RMI4 over SMBus. If your touchpad currently shows as SynPS/2 Synaptics TouchPad in libinput list-devices on one of these machines, you’re the target audience. The maintainer tested on three T14 Gen 2a AMD units (Ryzen 7 PRO 5850U, pad firmware ids 3942087 and 3418235), and there’s an independent report on a T14 Gen 1 AMD (Ryzen 7 PRO 4750U, LEN2064, Fedora 44, kernel 7.2.9).

2. Install with headers present.

omarchy pkg add thinkpad-t14-amd-touchpad-dkms. The README’s upstream install path says to have the headers for your kernel installed (linux-omarchy-headers on Omarchy) — confirm during verification whether the Omarchy package declares that dependency or whether you need omarchy pkg add linux-omarchy-headers first. The install triggers an initramfs rebuild (mkinitcpio’s hook fires on usr/src/*/dkms.conf; on a UKI setup that’s a new image), so expect it to take a little while.

3. Reboot and check.

Run thinkpad-t14-amd-touchpad-check. It reports whether the three modules are installed, loaded from the DKMS copies, and whether the touchpad is on the RMI4 transport. The pad’s input device is renamed from SynPS/2 Synaptics TouchPad to Synaptics TM3471-030 (synaptics-tm3471-030 in Hyprland) — anything keyed on the old name has to follow it (see issues below).

4. The three things everyone needs to know:

• DKMS means “rebuilt on every kernel update” — automatically, until it can’t. On each kernel install DKMS reapplies the patches and recompiles. If a build fails (e.g. a kernel series bump the patches don’t apply to), the stock modules silently load and your pad drops back to PS/2. The check command makes that visible. Run it after every kernel update — that’s the whole maintenance routine.
• The modules are unsigned. Installing them sets the kernel’s O (out-of-tree) and E (unsigned module) taint flags. On a kernel that enforces module signatures (typical with locked-down Secure Boot), they won’t load at all. See the issues section.
• Removal is clean. sudo pacman -Rns thinkpad-t14-amd-touchpad-dkms (or dkms remove thinkpad-t14-amd-touchpad/<version> --all), reboot, and DKMS restores the stock modules — the pad returns to PS/2 exactly as before.

5. What the patches actually do (the short version).

i2c-piix4 gains SMBus Host Notify through the AMD FCH’s ASF target block (ACPI SMB0001) — without this, psmouse can’t use the SMBus path at all. rmi_smbus gets a 300 ms settle after the PS/2 reset psmouse sends at resume — without it the pad reconfigured too soon and came back at 80 Hz or jumped on first touch after suspend. psmouse sets the F01 doze interval Lenovo’s Windows driver uses (short taps and two-finger touches were missed at the default) and adds LEN2073 (Gen 2) and LEN2064 (Gen 1) to the SMBus allowlist. Two mainline backports ride along so installing the package doesn’t drop fixes Omarchy’s linux-omarchy already ships (a psmouse use-after-free and signed coordinates in focaltech.c).

Common issues & fixes

Sourced from the project’s README (orospakr/thinkpad-t14-amd-touchpad, 0.2.3) — the maintainer documents behavior thoroughly, so these are maintainer-documented, cited where possible. Not reproduced by the draft author.

After a kernel update the touchpad feels bad again — taps missed, gestures gone

Fix: The DKMS build probably failed on the new kernel and the stock modules silently loaded, dropping the pad back to PS/2. Run thinkpad-t14-amd-touchpad-check — it’s designed to make this visible. If it reports the stock modules, reinstall the package (omarchy pkg add thinkpad-t14-amd-touchpad-dkms) to trigger a rebuild, and check the DKMS log for the failure. The repo’s kernel policy: tools/pre-build.sh warns in the DKMS log when the running kernel is from a different series than the pristine sources, and CI tests patch application weekly against current Arch linux-headers, linux-omarchy-headers, and mainline master — so a series bump shows up as a known failure before a refresh release lands.

Omarchy’s touchpad toggle (and the XF86TouchpadOn/Off keybinds) stop finding the touchpad

Fix: Expected side effect: the device is renamed from SynPS/2 Synaptics TouchPad to Synaptics TM3471-030, and Omarchy’s omarchy-hw-touchpad used to match on the name alone. Fixed in omacom/omarchy#14431, which added a fallback to udev’s ID_INPUT_TOUCHPAD — so the toggle works again on Omarchy releases that include that fix. If your toggle still can’t find the pad, update Omarchy first. Anything else keyed on the old device name (Hyprland input config, scripts) needs updating to the new name manually.

The modules won’t load — dmesg complains about signatures, or the check shows stock modules

Fix: The three DKMS modules are unsigned, so the kernel taints (O and E flags) and a kernel enforcing module signatures refuses to load them. If you run Secure Boot in enforcing mode, either sign the modules yourself (MOK workflow) or accept that this package can’t load on your setup. The stock modules then load and the pad stays on PS/2.

On a kernel with psmouse built in (not a module), nothing improves

Fix: This is documented for Fedora (which builds psmouse into the kernel): the DKMS copy of psmouse is unused, patches 0003–0005 and the backports don’t take effect, and the pad needs psmouse.synaptics_intertouch=1 on the kernel command line — with only the i2c-piix4 and rmi_smbus patches applying. Omarchy builds psmouse as a module, so this shouldn’t apply to Omarchy users; it’s here for completeness because the same package is installable on other distros.

You bought a T14 Gen 1 AMD and wonder if it’s covered

Fix: Yes, since 0.2.3: LEN2064 (Gen 1 AMD) joined the SMBus allowlist via patch 0005. An independent report confirms a T14 Gen 1 AMD (20UD001AMH, Ryzen 7 PRO 4750U, TM3471-020) attached over RMI4 at 15 ms reports with working taps across three suspend cycles. Note that run was on Fedora and needed psmouse.synaptics_intertouch=1 on the kernel command line — on Omarchy the module build should apply the allowlist directly.

Pairs well with / If you hate this, try

Pairs well with

• linux-omarchy-eevdf-headers if you’re also trying the EEVDF kernel flavor — DKMS needs the headers matching the kernel you’re actually booted into. Any ThinkPad power-management setup you already run is unaffected (this package touches only input modules).

If you hate this, try

• Living with the PS/2 fallback — no package, taps and two-finger gestures as the stock kernel leaves them (80 Hz / ~40 Hz reports). Or wait: the patches are all aimed upstream, and the package retires itself once a stock Omarchy or Arch kernel drives the pad over SMBus on its own (check with grep Phys /proc/bus/input/devices showing the Synaptics device on an rmi4- path, package removed).

Comparison: touchpad driver options for the T14 AMD

Verdict: Install this if your T14/P14s Gen 1–2 AMD touchpad misses taps and feels laggy on Linux — it’s the only path to the SMBus transport the pad was designed for, and it uninstalls cleanly if upstream ever catches up.