Public bug reported: Please help triage this RMI4 touchpad problem and assess whether a narrowly scoped F01 power-management quirk, or a better underlying fix, belongs upstream. This report contains observations from one Intel laptop and an experimental diagnostic patch, not a claim that the patch is ready for merging.
The same findings and selected kernel messages have been shared with the original workaround developer: https://github.com/SpencerMichaels/t14-amd-gen2-rmi/issues/3 Environment ----------- Lenovo ThinkPad T14 Gen 2i; DMI vendor LENOVO, product 20W1SF7K00, product_version ThinkPad T14 Gen 2i. BIOS N34ET71W (1.71), BIOS date 05/09/2026. Synaptics TM3471-030, manufacturer ID 1, firmware ID 3942087. Intel Tiger Lake-LP SMBus controller 8086:a0a3, Lenovo subsystem 17aa:22c9, using i801_smbus / i2c_i801 and the stock rmi_smbus transport. Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic, source package 7.0.0-38.38. GNOME Shell 50.1-0ubuntu1.3 on Wayland; libinput10 1.31.1-1ubuntu1.2. Relevant boot argument: psmouse.synaptics_intertouch=1. Suspend mode: s2idle. Symptoms and reproduction before the workaround ---------------------------------------------- With native RMI/SMBus input, tapping generally works after boot. After closing the lid / suspending and waking, light taps become unreliable. During one manual 10-tap check, approximately two taps registered. Pointer movement, two-finger scrolling, and physical clicking continued to work, although ordinary interaction could also produce unwanted browser zooms. GNOME's saved tap-to-click setting remained true. Reapplying that preference, temporarily disabling disable-while-typing, typing and waiting for suppression to expire, toggling touchpad events off/on, and reloading the stock RMI stack while awake did not reliably fix the problem. An existing sleep-time driver reload hook was disabled; the problem still occurred. During one manually coordinated recording interval, only two short contacts were identified in the evdev capture, and both produced BTN_LEFT events in a separate libinput context. The alignment was manual, so this is supporting evidence rather than an automated count of lost physical taps. It suggests the failure is below GNOME's saved tapping preference; it does not by itself prove a firmware mechanism. Switching temporarily to psmouse.synaptics_intertouch=0 restored tapping, but normal-speed three-finger switching degraded and worked only slowly. Related investigation and local experimental change -------------------------------------------------- The investigation at https://github.com/SpencerMichaels/t14-amd-gen2-rmi describes post-resume false pinch geometry on the same sensor and firmware in an AMD T14 Gen 2. Its F01 NoSleep idea motivated this Intel-only experiment. The detailed geometry jumps and firmware trigger described there have NOT been independently measured on this Intel machine. Only drivers/input/rmi4/rmi_f01.c from the exact Ubuntu source was changed. No AMD controller, IRQ, or F03 service patches from that project were used. The diagnostic patch adds a default-off tm3471_nosleep module parameter and checks the exact DMI identity, manufacturer, product, and firmware above. When opted in, it sets RMI_F01_CTRL0_NOSLEEP_BIT in the cached F01 control byte and writes that control byte during initialization after reading the identity. Existing suspend/resume code remains unchanged: it clears NoSleep for suspend and restores the saved bit on resume. There was no firmware flashing. The locally built rmi_core.ko was signed with an enrolled local MOK and loaded under Secure Boot, with the stock transport and other drivers. It is an out-of-tree module, so the kernel records the expected out-of-tree taint. Observed results, October 29-30, 2026 ----------------------------------- - After loading the candidate: light taps, normal-speed three-finger swipes, two-finger scrolling, and TrackPoint operation were reported normal. - One logged short s2idle cycle: tapping, gestures, and scrolling remained normal afterward, without unwanted zooms. - After a normal reboot and automatic candidate loading: tapping, gestures, and scrolling were again reported normal. - A second logged s2idle cycle lasted approximately 13 hours 51 minutes. Tapping, gestures, and scrolling remained normal afterward; the module parameter still read Y. The observed workaround activation message was "TM3471 awake-doze workaround enabled (local opt-in)". Configuration and limits ------------------------ A pre-existing boot driver-reload service remains enabled. Automatic candidate loading occurs after it and before the display manager. The old sleep reload hook and the attempted userspace tap-toggle recovery service are disabled. An existing libinput pressure quirk (AttrPressureRange=10:8, matching Synaptics TM3471-030) was unchanged across the native-mode comparisons. These local customizations are disclosed because this is not a pristine distribution configuration. The stock driver logged "rmi_driver_clear_irq_bits: Failed to change enabled interrupts!" during module teardown, both in the boot reload path and during the switch to the candidate. The candidate then initialized successfully. This is one machine and two successful actual suspend cycles, not long-term reliability proof. A subsequent lid check with no suspend log was not counted. No current mainline kernel, full power-off cold start, hibernation, intentional pinch accuracy, all individual TrackPoint buttons, or power-consumption comparison has been tested. No first-bad kernel or regression range is known. The NOSLEEP=0 case using the same patched binary has not been tested. Please advise what additional captures or controlled tests would be most useful, and whether the existing RMI power-management property mechanism is preferable to a device-specific quirk. The patch is supplied for diagnosis and review, not as a formal signed-off kernel submission. Investigation, patch preparation, and report drafting were assisted by OpenAI Codex; physical input results were confirmed by the laptop owner. No Signed-off-by or Tested-by trailer is asserted by this report. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 resolute suspend-resume touchpad -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2172601 Title: ThinkPad T14 Gen 2i: TM3471-030 misses taps / produces false zooms after suspend; F01 NoSleep workaround tested To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172601/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
