Touchpad tooling carries superseded theories and duplicated machinery; tidy once the pad has been stable a week

[jappeace-sloth]

Problem

The lenovo-tablet touchpad work of 22 and 23 sep 2026 (PRs #63 to #70) was done one dump at a time, and the code still reads like that. Three files (nix/touchpad.nix, nix/touchpad-ssdt.nix, nix/touchpad-rescue.nix) each open with a long narrative, and parts of those narratives describe theories the later dumps disproved: the touchpad dying when a bluetooth mouse connects, the lenovo_ymc tablet-mode switch, the i2c "lost arbitration". A reader who opens the first file gets the wrong story before reaching the right one in the third.

The tooling also has pieces built on those wrong theories that are still installed on every boot: the sway-level touchpad-keep-enabled watcher (which can never see a firmware-level failure and has logged nothing useful since it was added) and the lenovo_ymc blacklist on both laptops. Whether either earns its keep is unknown; they were never evaluated after the real cause turned out to sit in the BIOS probe.

touchpad-diagnose has grown to some fifteen sections and takes about a minute, including a five-second capture that asks for a finger on the pad and an ACPI table decompile that leaves files in /tmp. Several sections exist only to answer questions that are now answered.

Use case

Jappie runs this tablet daily and, while the problem was live, could not use chat, copy or a mouse; the dump was the only channel. That constraint is gone once the pad is reliable, but the next hardware problem on this machine will start from these files, and they should tell the true story in one read.

Current behaviour

• Decision comments in three files contradict each other on the cause; the corrected version lives only in nix/touchpad-rescue.nix and the lenovo-tablet.nix header.
• Two mitigations from disproven theories are still active without evidence they help.
• A diagnose run produces ~50 KB and requires interaction, even when only the two or three sections that discriminate good from bad are wanted.

Expected behaviour

• One place states the root cause, the evidence, and what each installed piece is for; the rest refers to it.
• Every installed touchpad mitigation is either shown to matter on this machine or removed.
• The diagnose tool answers "is the pad present, does it answer at 0x15, what did the BIOS and EC record" quickly and without interaction, with the deep sections available but not default.

Not before the touchpad has behaved for a week under the current setup, including at least one warm reboot that started bad and was recovered by the rescue service; the tooling is the only eyes on it until then.