The 300 Millisecond Touchpad

Ten days of measuring what a Synaptics touchpad does after the laptop wakes up. Three symptoms, two of which turned out to be one fault, one fix that was quietly causing the next problem, and two kernel patches at the end of it.

1. Where this started

This machine's touchpad had been stuck in PS/2 fallback since the laptop was new, because AMD's SMBus controller does not advertise Host Notify and the RMI4 driver will not attach without it. An earlier write-up covers the fix: an out-of-tree i2c-piix4 that drives the chipset's ASF block for Host Notify, the same single-driver shape Intel uses. With that installed the pad runs natively over SMBus at a clean 15 ms per report, and three residual problems came into focus.

What follows is the order the facts were found in, because the order is the point. Each fix was measured, each one cleared its symptom, and two of them were wrong.

2. Measuring a touch-down

Every conclusion here rests on one number, so it is worth being precise about it. A capture is thirty seconds of raw evtest output while six slow single-finger drags are made, lifting fully between them. For each drag the analyser takes the distance the reported position moves between the first and second frame. On a healthy pad that is zero or near it: the finger has just landed and is barely moving. On a pad in the wake-jump state it is 60 to 140 units, 5 to 12 mm, in a single 15 ms frame, a speed no slow drag ever reaches.

Two things made the rig trustworthy. The interrupt counters along the pipeline, ASF hard interrupt, Host Notify into the RMI driver, F12 finger frames, and evtest reports, were snapshotted around every capture and always agreed, which ruled out host-side loss early. And a capture that needs hands is only accepted once it contains real drags; the script re-cues and retries, and a multi-step sequence aborts rather than advancing. That rule was added the hard way, after a night where a four-step bisect ran to completion on four empty captures.

3. Dropped taps and phantom pinches: doze

This was the clean thread. With the counters agreeing, the missing taps were missing at the source: the pad simply reported six of twenty quick taps, one frame each. Two-finger landings were reported with the objects in the wrong order, so libinput saw finger separation collapse from 165 to 78 units in one frame and called it a pinch, scale 2.45.

The pad's F01 doze registers explained it. Doze is the firmware's low-power scan mode between touches: interval 3, wakeup threshold 45, holdoff 0 on this pad, so it drops into doze the instant a finger lifts and samples too slowly to catch a short touch. Lenovo's Windows driver for this family sets RMIDozeInterval=6 for twelve pad IDs, LEN2073 among them, and does not disable doze. Measured with each configuration:

The Windows value keeps the power saving and fixes both. It goes upstream as a small table in the PS/2 Synaptics driver, passing the interval through platform data for the same twelve IDs. Two red herrings on the way, both cheap to rule out and worth naming: libinput's thumb pressure threshold (fingertips here report 50 to 70, well under it) and ASF bus collisions between the pad and the TrackPoint pass-through (the counters matched).

4. The resume fault, and the fix that caused the next bug

What the 80 Hz clock looked like from the driver

The SMBus transport's resume path does three things in order: reset its own register-mapping cache, run the RMI configuration pass, then wake the sensor. The configuration pass rewrites every function's control registers: the F01 device control byte, the three doze bytes, and the interrupt mask. Reading that order, the story wrote itself: configuring a sensor that is still asleep half-applies, wake it afterwards and you get the degraded clock. Moving the pass after the wake gave 0 degraded resumes in 8, where the stock order gave 8 in 8. A patch was drafted.

It was tested with a knob that ran the pass both before and after the wake, because that was the smallest change. That knob stayed loaded. Two days later the cursor started sticking after every sleep.

Chasing the wake jump

The jump looked like a firmware sleep state. The register dump was byte-identical to a healthy pad; the report clock was perfect; and it seemed to need hours of suspend, since 90-second probe cycles had never shown it. Every one of those impressions was wrong, and the sequence of experiments that dismantled them is the useful part of this document.

1. Nothing over SMBus touched it. The config pass alone, and a full unbind and re-probe of the SMBus driver, both left it in place. A reload of the PS/2 driver stack cleared it every time. So the cure was on the PS/2 side.
2. Bisecting PS/2 commands with a trigger added to the experimental driver: the disable that stock resume sends did nothing; the identify-and-capability query sequence cured it; then a single Get ID cured it. The minimal cure was one PS/2 command.
3. Get ID put into the resume path did not work. It ran, the log showed it, the pad still came back jumping. Minutes later, the same command in place cured it.
4. Every PS/2 command is a firmware reset. This was the turn. After Get ID the pad's interrupt mask read 00 00 and its doze interval was back to 3. Get ID was not waking anything; it was wiping the host's configuration. The disable at resume does exactly the same, which the SMBus driver copes with only because it reconfigures afterwards, and because its resume happens to run after the PS/2 one.
5. The "hours" threshold was false. A four-minute timed suspend produced the jump. Nobody had captured positions after a short cycle before; the earlier probes recorded timing only.
6. Stock order, no jump. With the config pass back in its original place before the wake, a four-minute suspend gave drags from rest, and the 80 Hz clock. The after-wake fix was creating the jump.
7. Per-register bisect, twice. Every write of the config pass, applied alone to a freshly reset pad, was clean. So was every write applied after the control byte. A second full pass after a first one jumped, and so did a pass whose only predecessor was the doze write. For an evening that looked like "writing the doze registers twice".
8. The suspend log killed that theory. A build that skipped unchanged doze writes still jumped after a real resume, with the log proving the doze bytes had been written exactly once.
9. What was left was time. Every clean in-place sequence had slept two seconds after the reset before writing anything. At resume, the pass followed the reset within milliseconds.

5. What the pad taught us on the way

• Any PS/2 command to the pad resets its RMI side: interrupt mask cleared, doze registers to defaults, and the SMBus register mapping invalidated. Reads fail with error -6 until the transport re-runs its reset, which clears the host's mapping cache and re-reads the SMBus version register; the cache clear alone is not enough.
• An RMI4 device reset over SMBus (F01 command) kills the transport outright under the current driver, which never re-initialises the mapping from its reset handler. Do not use it as a cure primitive.
• Unbinding and re-probing the SMBus driver leaves the TrackPoint dead. The F03 pass-through port registers, but its interrupt bit is never set again until a psmouse reload. Every re-probe that week did this; it was noticed on the fourth night.
• The register dump cannot see either resume fault. Before and after, the bytes are identical. Both states are firmware-internal and only visible in what the pad reports.
• libinput's jitter hysteresis was a red herring. Hyprland's log showed it enabled for the pad, but the dead-band is resolution/4, a quarter millimetre, and it had fired before the first bad suspend. Worth knowing: that state lives inside the compositor process and a separate libinput debug-events can never show it.
• The resume-order fixes were self-inflicting. Two symptoms with different fingerprints came from one timing fault, and each "fix" moved the timing enough to swap one for the other.

6. Harness notes

• Root work runs in a dedicated pane; everything else is unprivileged. Experimental modules are out-of-tree and vanish on reboot; the only installed piece is the ASF transport.
• Captures that need hands are gated: a sound and a notification cue the drags, the capture repeats until it holds at least 100 frames, and a step sequence aborts on an empty one. Timed suspends use rtcwake so no stopwatch is involved.
• A pad that is dead or jumping recovers with one command, the psmouse reload, which also restores the TrackPoint. It is the safe fallback at the end of every sequence.
• A background wait in the harness that spans a suspend simply resumes with it, since monotonic time stops; the scripts do not need to know.

7. Timeline

• Sep 4–5T5, bisect
  8/8 resumes degraded on stock order; manual config passes at 60/30/10/3/1 s after wake all clean, so no timing window on that side. Cause traced to the pass running before the sensor wake.
• Sep 7T10, doze
  In-driver after-wake pass: 0/8 degraded. Same evening the doze thread resolves: 6/20 taps become 20/20 with NoSleep, and with the Windows interval. Patches 0001 (reorder) and 0002 (doze) drafted.
• Sep 8wake jump
  After a 4.7 h suspend the cursor sticks on touch-down. First-frame metric built; libinput hysteresis ruled out; F01 device reset kills the transport; reload cures.
• Sep 9–10separation
  Reload alone cures. Stepwise sequence shows nothing on the SMBus side helps; the PS/2 side does. A run lost to unanswered cues; captures made gated.
• Sep 11–12PS/2 bisect
  Trigger param added. Disable: no. E8 queries: yes. Get ID: yes. Every command kills the SMBus mapping. Get ID put in the resume hook; fails at real resume. Four-minute suspends reproduce the jump with the hook off.
• Sep 13resolution
  Stock order: no jump, bad clock. Get ID shown to be a reset. Two register bisects, the doze-twice theory, its refutation by the suspend log, then the delay series: 0/30/100 ms jump, 300 ms clean, and 300 ms across a real suspend gives a flat clock and drags from rest.

8. Patches and what is left

Still to do before sending: a few more natural resumes including an overnight one under the settle delay; narrowing the threshold between 100 and 300 ms if a reviewer asks; real names in the sign-offs. The upstream RFC for the ASF transport itself, which all of this depends on, is a separate piece of work. One unexplained observation remains and is moot for the fix: in place, a second config pass issued a second or more after a clean first one also produced the jump, as if a doze rewrite on an awake sensor is itself a small reset.