chore(tasks): file the MT7925 Bluetooth bug and the AX210 swapHEADmain

Three headsets drop HFP call audio on velox's MT7925, and the kernel's sentinel-handle errors match a pending upstream firmware report, so I'm replacing the card with an Intel AX210. I also filed the net doctor captive-portal task and archived two aged completed tasks.

1 files changed, 136 insertions, 0 deletions

diff --git a/archive/task-archive.org b/archive/task-archive.org
index 4f2fdaa..dfd273d 100644
--- a/archive/task-archive.org
+++ b/archive/task-archive.org
@@ -2968,3 +2968,139 @@ ratio and absent on velox; full evidence and rationale in
 
 Scope: installer step + rule file + tests per existing shapes, and apply both
 live to velox over tailscale (daily-driver sync — neither exists there today).
+** DONE [#B] Velox touchpad interrupt line is dead — needs a part or a BIOS fix :bug:velox:hardware:
+CLOSED: [2026-08-15 Sat]
+:PROPERTIES:
+:CREATED: [2026-08-15 Sat]
+:LAST_REVIEWED: 2026-08-15
+:END:
+*Fixed 2026-08-15 23:05 by reseating the correct connector* — a seating fault
+all along, no part needed. Verified at the kernel level on the 23:05 boot: the
+=did not ack reset within 1000 ms= message is gone (clean handshake), and the
+interrupt count went 0 → 1795. Power-key events also zero, so both faults from
+the mainboard swap are closed.
+
+What made this take three attempts is worth keeping: two of the connectors on
+that board were decoys. The input-cover ribbon looked like the obvious suspect
+and fixing it *did* resolve the power button, which made it look like the whole
+answer. Then the 4-pin connector next to the printed =TOUCHPAD= label looked
+like the touchpad's own — and its cable is silkscreened =PIN 1-2 - GND /
+PIN 3-4 - VCC=, four contacts of pure power, incapable of carrying i2c or an
+interrupt. Reading that silkscreen off the photo is what ruled it out and sent
+the search to the ribbon that actually crosses to the mainboard.
+
+The ordered touchpad becomes a spare, which is what Craig wanted from it anyway.
+The diagnostic path below is left intact — it is the reusable part: =dmesg=
+for the i2c-HID reset message and the interrupt count in =/proc/interrupts=
+together separate "device absent" from "device present but its interrupt line is
+open", and a live USB separates hardware from software in two minutes.
+Split from the ribbon-reseat task 2026-08-15 once the reseat fixed the power
+button and left this untouched — they are two faults, not one.
+
+*Diagnosed to the interrupt line specifically, with software eliminated.*
+- The i2c *data* path works. =i2c_hid_acpi= read the HID descriptor, returned
+  the right product ID (=093A:0274=), =hid-multitouch= bound, and input6/7/8/9
+  were created. A descriptor read is a real bus transaction, so the device is
+  electrically present and answering.
+- The *interrupt* path never fires. IRQ 81, =amd_gpio= hwirq 8, level-triggered,
+  =actions=PIXA3854:00= — the handler is correctly registered on the pin the
+  firmware names. Count is 0 across all 24 CPUs, including during active
+  swiping.
+- =dmesg=: =i2c_hid_acpi i2c-PIXA3854:00: device did not ack reset within 1000 ms=.
+  The i2c-HID reset handshake is acknowledged *by the device asserting the
+  interrupt*, so the first operation needing that line already failed at boot,
+  before anything touched the pad. That is why the fault reproduces on any boot
+  in ten seconds.
+- *Software ruled out by live USB.* Same "did not ack reset" message and no
+  pointer movement under Ubuntu's kernel (2026-08-15). Not a driver, not
+  libinput, not Hyprland, not this install.
+
+Three candidates remain, all needing a part or firmware:
+1. Open conductor on the touchpad's own cable or a bad contact at either end.
+   Framework sells "Touchpad Cable" as a discrete spare, so it is separately
+   replaceable — and the input-cover ribbon reseat would not have touched it.
+2. The touchpad module's interrupt output is dead while its i2c slave still
+   answers. Indistinguishable from 1 without swapping parts.
+3. Firmware naming the wrong GPIO. The DSDT says =amd_gpio= pin 8; if this
+   board revision routes the interrupt elsewhere, the kernel watches a pin that
+   never toggles. Plausible because the mainboard is days old to this machine
+   and its firmware already needed the PSR workaround. BIOS is 03.05
+   (2025-10-30); kernel 6.18.44-1-lts.
+
+*The connector that was reseated is NOT the touchpad's — confirmed from the
+board photo.* Craig reseated the 4-pin connector near the printed word
+=TOUCHPAD=. Its cable is silkscreened =PIN 1-2 - GND / PIN 3-4 - VCC= — four
+contacts, all of them power. No clock, no data, no interrupt; almost certainly
+the keyboard backlight feed. An i2c-HID touchpad cannot run through it, so that
+reseat could never have fixed this, and *the free retry remains untried*.
+Photo: [[file:working/velox-touchpad-interrupt/touchpad-module-underside-2026-08-15.jpg][working/velox-touchpad-interrupt/touchpad-module-underside-2026-08-15.jpg]].
+
+Visible on that board: the controller IC marked =PCT3854= (matching the kernel's
+=PIXA3854=), a larger =CON3= carrying a blue-backed ribbon with "26" marked
+beside it, a white ZIF past the Framework QR label, and a further connector at
+the board's end. The one that matters is whichever ribbon physically *leaves the
+input cover and reaches the mainboard* — that is the touchpad cable, and its far
+end is the press-fit connector at the board. Reseat both ends of that one before
+fitting any new part.
+
+*BIOS 04.02 exists but does not look relevant.* Checked 2026-08-15 with velox
+on AC at 90%: fwupd offers 0.0.3.5 → 0.0.4.2. Read the changelog — the only
+touchpad line is haptic-touchpad support for the Laptop 13 *Pro* chassis, and
+this machine has a conventional PixArt =PIXA3854=. The rest is BIOS Setup
+layout, option naming, TPM behavior, iGPU defaults, PMF slider. Nothing about
+GPIO routing or interrupt configuration. So candidate 3's cheap test is weaker
+than it looked when it was filed sight-unseen; still worth doing (unlisted
+fixes happen, and ACPI tables change), just no longer the front-runner.
+Deliberately deferred past the flight — a cleared NVRAM is the failure that
+started this whole rebuild. Boot-entry recovery reference captured at
+[[file:docs/2026-08-15-velox-uefi-boot-entry-reference.org][docs/2026-08-15-velox-uefi-boot-entry-reference.org]].
+
+Order of attack on return, cheapest first: reseat the touchpad's *own* press
+connector at the mainboard (free, untried) → BIOS 04.02 → fit the replacement
+touchpad. Craig's call 2026-08-15: order the parts now anyway, since they are
+worth holding as spares regardless of which candidate wins.
+
+*What to order.* The replacement *Touchpad* ships with the Touchpad Cable
+pre-installed, so that single part covers candidates 1 and 2 together — no need
+to buy both to cover both. A bare Touchpad Cable is worth adding only as a cheap
+spare. The *Input Cover* is a different and more expensive part, and nothing
+points at it: the keyboard works, so the input-cover ribbon is carrying signal.
+Framework's marketplace renders its catalogue in JavaScript, so prices could not
+be read programmatically — search "Touchpad" under Laptop 13 parts.
+
+*Also worth a Framework support ticket* — the touchpad died coincident with
+their mainboard swap, which may put it inside whatever recourse that carries.
+
+Grading: Major severity (a laptop's built-in pointer is entirely dead — the
+counter-argument is that an external mouse is a complete workaround, which
+would make it Minor; I took Major because losing the integrated pointer degrades
+the machine's portability, which is the whole point of the laptop) x every user,
+every time = P1 = [#A]. Filed [#B] rather than [#A] only because an [#A] must
+carry a date and Craig's return date isn't known yet — date it and raise it to
+[#A] when it is.
+
+Workaround in the meantime: Bluetooth mouse, already in use.
+** DONE [#C] hypridle.conf is generated per-machine but tracked :refactor:dotfiles:
+CLOSED: [2026-08-14 Fri]
+:PROPERTIES:
+:CREATED: [2026-08-14 Fri]
+:LAST_REVIEWED: 2026-08-14
+:END:
+Fixed in dotfiles 83ae7aa. The render is untracked and gitignored; the
+store is the only source of truth; hypridle-start renders at session start
+and owns the fallback ordering. Both machines reconciled and re-stowed:
+velox's tree is clean for the first time today and still carries its own
+policy (dim 5, lock 10, suspend-then-hibernate 30), ratio's config is
+byte-unchanged.
+=hyprland/.config/hypr/hypridle.conf= is rendered by the settings panel
+from each machine's own stage config, and it is also a tracked file stowed
+to every machine. So a machine whose idle policy differs from the
+committed default carries permanent working-tree dirt, and every pull
+there needs a stash/pop dance (velox, twice on 2026-08-14). Worse, the
+committed copy is whichever machine last committed it, which is how a
+desktop ended up tracking a laptop's suspend-then-hibernate line.
+Options to weigh: gitignore the rendered file and track only a template or
+the stage defaults; render to a non-stowed path and have hypridle read
+that; or keep it tracked but commit a machine-neutral render. The first
+looks right — the store already holds the real source of truth, and the
+rendered file is a build artifact.