ADR-0032: Sweep peripheral commitment — 2× trackpoint adoption + LIS3DH I²C re-pinning

Followed by: ADR-0035 (Trackpoint cart-FFI surface — v0.1 cursor + event API; supersedes §5 “cart-FFI exposure — none in v0.1” by exposing the cursor to carts in v0.1). Related: CLAUDE.md Canonical Hardware Specification (Keys + Accelerometer rows); docs/influences/synthesis.md §10; docs/influences/prototype/trackpoint-module.md; docs/influences/prototype/keyboard-decision.md; docs/influences/prototype/ferris-sweep.md; docs/influences/prototype/holykeebs-buyers-guide.md; docs/influences/prototype/corne-crkbd.md (Corne+trackpoint community precedent).

---

Context

ADR-0031 adopted the Ferris Sweep as the v0.1 keyboard with two specific deferrals carried in §6 (Sweep OLED skipped) and §7 (Pointing device deferred). prototype/keyboard-decision.md had left the pointing-device choice “Open question; tracked in keyboard-decision.md” with four options listed: trackpoint, TPS43 touchpad, Pimoroni trackball, or none. The deferral let v0.1 ship without commitment.

Two things changed on 2026-06-07:

1. Josh ordered 2× trackpoints on the Sweep — one per index finger. This is a hardware-line commitment, not a software-side preference; the trackpoints are physical daughterboards that must be ordered alongside the Sweep Soldered kit. The decision needs to land in the corpus before the order leaves.
2. Batch 7 of the inspiration corpus added prototype/trackpoint-module.md, prototype/corne-crkbd.md, and prototype/sinclair-zx-spectrum.md — the first of which documents the holykeebs trackpoint module specifically and surfaces a pin conflict on the master half: the trackpoint shares I²C0 pins (D4/D5 = GP4/GP5) on the KB2040 silkscreen with the LIS3DH accelerometer per ADR-0023 / ADR-0024 / ADR-0031 §3. The trackpoint uses those pins for PS/2 protocol (clock + data); the LIS3DH uses them for I²C. The two protocols cannot share the physical pin pair. Both devices must be on the master, and one of them has to move.

This ADR ratifies the pointing-device commitment and resolves the pin conflict.

Forcing functions

1. Hardware order in flight. The Sweep Soldered kit + 2× trackpoint module order goes to holykeebs as soon as this ADR lands. Ordering ahead of the ADR risks a BOM that contradicts the canonical spec.
2. The canonical pin map in ADR-0031 §3 is wrong as-shipped if both trackpoint and LIS3DH stay on I²C0. Building the firmware against the wrong pin map costs a re-flash cycle at minimum; in the worst case it costs a fried sensor. Resolution must land in the canonical spec, not just in firmware code comments.
3. ADR-0031 §6 OLED skip was conditional. ADR-0031 §6 wrote that “Skipping the OLED preserves the option to add a pointing device later without re-spinning the build.” That option is now exercised; the OLED skip becomes permanent rather than conditional. The corpus needs to reflect that the OLED is not coming back in v0.x.
4. Click-gesture finalization. The trackpoint click semantics are not yet decided. The ADR can punt the specific gesture to firmware bring-up, but must set a hard constraint on which thumb keys are allowed to be re-purposed and which must not (EVAL, LSHIFT, 0, TERM all stay).

Constraints

• Two physical trackpoints, one per index finger, are decided. Quantity is not negotiable.
• Master half hosts both LIS3DH and a trackpoint. Resolving the pin conflict cannot involve “move the LIS3DH to the slave half” — the slave also hosts a trackpoint, same conflict; and the LIS3DH-on-master constraint from ADR-0023 (vendor HID report on the master’s USB HID interface to the Pi) is firm.
• No new MCU. The Pico 2 coprocessor (ADR-0017) has plenty of GPIO and could host the LIS3DH, but that’s a much larger architectural change (re-host sensor, re-define wire protocol from USB HID vendor report to UART command, re-author the nOSh ambient-glitch consumer). Out of scope; only consider after exhausting on-KB2040 options.
• No new bus protocol. SPI on the LIS3DH is supported by the chip but not by the existing ADR-0023 driver code path. Stay on I²C.
• Keep the OLED skipped. v0.1 commits to no Sweep OLED (ADR-0031 §6). The CIPHER-LINE 256×64 SSD1322 (ADR-0015) remains the authoritative auxiliary display. Adding the Sweep OLED later would require moving a trackpoint off one half, which is exactly the wrong direction.
• CLAUDE.md Spec Hygiene Rules 1, 2, 3 apply. Canonical values land in Keys + Accelerometer rows once; cascade grep sweep is a hard PR requirement.

---

Decision

The KN-86 Ferris Sweep build commits to 2× holykeebs trackpoint modules (Sprintek SK8707-01 sensor + adapter PCB + red rubber cap, one per half — under each operator index finger). The Sweep OLED skip from ADR-0031 §6 becomes permanent for v0.x (no re-introduction without a new ADR). The master-half LIS3DH moves from I²C0 (D4/D5) to I²C1 (D6/D7) to resolve the trackpoint pin conflict; the originally-reserved INT1 line on D6 is released (v1 LIS3DH is polling-only).

Concrete commitments:

1. Hardware additions to the holykeebs Sweep Soldered kit order

Item	Qty	Source	Note
holykeebs trackpoint module	2	holykeebs.com/products/trackpoint-module	One per Sweep half. Includes Sprintek SK8707-01 sensor, adapter PCB, red rubber cap.
Red rubber cap spares (optional)	4-6	holykeebs.com/products/trackpoint-module	Caps wear faster than the sensors. Cheap spares are worth the order line.
KB2040 spare (recommended)	1 (additional to the 2 in ADR-0031)	Adafruit PID 5302 / DigiKey 1528-5302-ND	Trackpoint daughterboard soldering is one-shot per holykeebs docs (“After this soldering it’ll become extremely hard to separate the two PCBs”). One spare KB2040 across the two halves is cheap insurance.

The order target stays “holykeebs Soldered kit, current PCB revision (hot-swap + diodes — modified Sweep PCB per the post-Aug-2023 revision).” The trackpoint requires the modified-diode PCB to free SDA/SCL pins from the matrix scan — already the holykeebs default per prototype/holykeebs-buyers-guide.md.

2. OLED skip — permanent for v0.x

ADR-0031 §6 skipped the Sweep OLED with the conditional rationale “preserves the option to add a pointing device later.” That option is now exercised on both halves. The Sweep’s optional 128×32 SSD1306 mount is permanently skipped for v0.x. Re-introducing the Sweep OLED in any future revision requires:

• Removing one trackpoint (asymmetric build — one index has a pointer, the other doesn’t), or
• A new PCB revision from holykeebs that splits the OLED + pointing-device mount locations, or
• A new ADR that supersedes this one with an explicit rationale.

None of those is in scope for v0.x.

3. Pin assignment — per half, updated

The complete master + slave pin assignment, replacing the LIS3DH-on-I²C0 mapping in ADR-0031 §3:

Half	Function	KB2040 silkscreen	RP2040 pin	Notes
Both	Matrix rows + cols	per Sweep PCB	per Sweep PCB	Fixed by the modified-diode Sweep PCB. Not authored here.
Both	TRRS data	per Sweep PCB (typically GPIO1)	per Sweep PCB	QMK split-transport serial driver on RP2040.
LEFT (master) — TRACKPOINT	Trackpoint PS/2 clock	D4 (silk: SDA)	GP4	PS/2 clock over the holykeebs adapter — not I²C SDA in this configuration.
LEFT (master) — TRACKPOINT	Trackpoint PS/2 data	D5 (silk: SCL)	GP5	PS/2 data over the holykeebs adapter — not I²C SCL.
LEFT (master) — LIS3DH	LIS3DH SDA	D6	GP6	I²C1 SDA — moved from I²C0 D4/D5 by this ADR.
LEFT (master) — LIS3DH	LIS3DH SCL	D7	GP7	I²C1 SCL — moved from I²C0 D4/D5 by this ADR.
LEFT (master) — LIS3DH	LIS3DH INT1	(released)	(released)	Released by this ADR. ADR-0024 §3 reserved D6/GP6 for INT1; D6 is now I²C1 SDA. v1 LIS3DH is polling-only at 25 Hz per ADR-0023 §5, so the reservation costs nothing to release. If interrupt-driven motion detection is ever wanted in v2, a new ADR re-allocates the line.
LEFT (master) — USB	USB to Pi	USB-C	—	Master half USB-C → internal hub IC → Pi. Unchanged from ADR-0031.
RIGHT (slave) — TRACKPOINT	Trackpoint PS/2 clock	D4 (silk: SDA)	GP4	PS/2 clock over the holykeebs adapter (same pinout as master).
RIGHT (slave) — TRACKPOINT	Trackpoint PS/2 data	D5 (silk: SCL)	GP5	PS/2 data over the holykeebs adapter.
RIGHT (slave) — USB	USB-C	USB-C	—	Used only for flashing the slave KB2040. Not connected to Pi during operation.
Both	SWD	SWCLK / SWDIO	—	Test pads on PCB underside. Unchanged.

4. QMK firmware — trackpoint driver integration

• Driver: stock QMK PS/2-mouse driver (pointing_device_driver = ps2_mouse in rules.mk). Compiled for both halves; each half drives its own trackpoint.
• Inter-half pointing event transport: stock QMK split-keyboard pointing-device transport on the TRRS link. The slave’s mouse movement events flow to the master, which emits them on the master’s USB HID interface alongside the master’s own trackpoint events. From the Pi’s perspective there is one mouse cursor; either operator hand can drive it.
• Click semantics — interim default: tap-vs-drag threshold in the QMK PS/2-mouse driver (press-and-release the stem within ~150 ms → click; longer press → drag). Final click gesture deferred to firmware bring-up (ADR-0032 Implementation Queue below). Hard constraint: none of the existing four KN-86 thumb keys (LT0 EVAL, LT1 LSHIFT, RT0 0, RT1 TERM) is reassigned to mouse-click. Click must come from the stem itself, or from a chord that doesn’t sacrifice any of the four canonical thumb bindings.
• Click button mapping: trackpoint button #1 (primary) only in v0.1. Right-click + middle-click bindings deferred to v0.2 with a [SHIFT]+stem-press chord convention as the leading candidate.
• Acceleration / sensitivity: QMK stock defaults. Operator-tunable via nosh-config.toml post-v0.1.

5. cart-FFI exposure — none in v0.1

Cart-FFI for pointer state is deferred. v0.1 cart authors see no (pointer-x) / (pointer-y) / (pointer-button) primitives. Mouse cursor input is consumed by the nOSh runtime only (nEmacs click-to-position cursor, REPL output click-to-copy, future Bare Deck Terminal cursor-driven nav). Cart-side pointer access is queued as v2 cart-FFI work — would expose both trackpoints individually as (pointer-a) and (pointer-b) per prototype/trackpoint-module.md §“What this leaves open.”

Update — deferral closed by ADR-0035 (2026-06-07): the v0.1 cart-FFI exposure decision flipped from “deferred to v2” to “exposed in v0.1” — three Tier 1 primitives (cursor-position, on-trackpoint-move, on-trackpoint-click) plus a visibility toggle (cursor-visible!) land in ADR-0005 Tier 1 under a new “Pointing / Trackpoint” sub-section. The cursor is exposed in cell coordinates on the main 80×25 grid, clamped to cartridge content rows (1–23), visible by default with manifest + FFI hide paths. Per-trackpoint differentiation (pointer-a / pointer-b) and right-click / middle-click remain v2 questions. The pre-amendment text above is preserved as design history; ADR-0035 is canonical going forward.

6. Power envelope — no change

LIS3DH on I²C1 vs I²C0 has zero power difference (same I²C peripheral block on the RP2040). 2× trackpoint adds ~6.5 mA active typical (2 × ~3.21 mA per Sprintek SK8707-06 spec; SK8707-01 in the holykeebs module is similar within ±15%) and ~1.8 mA idle (2 × ~890 µA). The 145-235 mA typical envelope from CLAUDE.md Battery row is unaffected at the percentage level — adding ~3-4% to the active band is well within bring-up measurement noise.

7. Sweep build implications

• Soldering complexity — each trackpoint module is a delicate one-shot solder onto the KB2040 underside per holykeebs docs. Order one spare KB2040 to absorb potential build-side failure.
• Assembly sequence — trackpoint daughterboards must be installed before the keyboard PCB is screwed into the case (the trackpoint sensor protrudes through the keyplate between the alpha keys; alignment depends on case fit).
• Bezel insert — the Pelican 1170 inset panel for the keyboard area (ADR-0031 §Consequences > Bezel insert) needs 2× cutouts for the trackpoint stems to protrude through the keyplate. Tracked as a bezel-design follow-up in F2 below.

---

Options Considered

Option A: 2× trackpoint + LIS3DH on I²C1 (D6/D7) (ACCEPTED)

Described above. Both halves carry a trackpoint; LIS3DH moves to the KB2040’s second I²C peripheral.

Option B: 1× trackpoint (right index only) + LIS3DH stays on I²C0 (REJECTED)

Asymmetric build — right half has trackpoint + no LIS3DH; left half has LIS3DH on I²C0 + no trackpoint. The original holykeebs default config.

Rejected because: Josh’s decision is 2×. The asymmetric build sacrifices the two-handed-pointing affordance, the left/right Lisp-authoring symmetry, and the accessibility hedge (single-handed operator). The pin-conflict resolution path (Option A) is cheap; the asymmetric build is not.

Option C: 2× trackpoint + LIS3DH moves to Pico 2 coprocessor (REJECTED)

Re-host the LIS3DH on the Pico 2 coprocessor’s I²C bus. Motion events route from Pico 2 → Pi via the existing UART command link (ADR-0017).

Rejected because: much larger change than necessary. Re-defining the LIS3DH wire protocol from USB HID vendor report (ADR-0023 §6) to UART command + extending the Pico 2 firmware to handle a new I²C peripheral + amending ADR-0017 and ADR-0020 is a four-ADR cascade. Option A solves the conflict with a single pin re-allocation on the same MCU. Save Option C for a v2 architecture where the LIS3DH host is genuinely contested.

Option D: 2× trackpoint + LIS3DH dropped from v0.1 (REJECTED)

Drop the LIS3DH-driven ambient CRT-glitch system from v0.1; reintroduce in v0.2 once the trackpoint integration is shipping.

Rejected because: the ambient-glitch system is a gameplay-identity feature (ADR-0023 Context — diegetic “the device is old and the CRT is misbehaving”). Dropping it from v0.1 weakens the deck’s Deckline identity at launch. The KB2040’s I²C1 exists; using it is free.

Option E: 2× trackpoint + LIS3DH on SPI instead of I²C (REJECTED)

The LIS3DH chip supports both I²C and SPI (ADR-0023 §1). Move it to KB2040 SPI pins.

Rejected because: the QMK community LIS3DH driver path is I²C; the SPI path would require writing or porting a driver. Option A keeps the existing driver code unchanged. The KB2040’s SPI pins are also used by the matrix scan on the Sweep PCB (silkscreen MOSI = D3 = ROW3 per ADR-0024 §3) — moving the LIS3DH to SPI would also require freeing SPI pins from the matrix, which means another modified PCB.

---

Trade-off Analysis

Against Option B (1× trackpoint, asymmetric build): Option A wins decisively on operator affordance (two-handed pointing), left/right symmetry, accessibility, and the cleanliness of the build. The cost paid (one pin re-allocation, one extra trackpoint module’s BOM line) is trivial.

Against Option C (LIS3DH on Pico 2): Option A wins on minimum-disruption — one pin re-allocation on an MCU that’s already host to LIS3DH vs four-ADR cascade re-hosting sensor on a different MCU. Option C is the correct long-term answer if cart-FFI motion access ever stress-tests the USB HID vendor report path; not the right answer today.

Against Option D (drop LIS3DH from v0.1): Option A wins on launch-identity preservation. The ambient-glitch system is part of the deck’s identity, not a v0.2 polish feature.

Against Option E (LIS3DH on SPI): Option A wins on minimum-driver-disruption. SPI path would require driver authoring + another PCB modification.

Cost the chosen option pays:

• One pin re-allocation (LIS3DH I²C0 → I²C1 on master). Minimal — KB2040 silkscreen labels D6/D7 are clearly marked; documentation update is one table.
• INT1 reservation released. ADR-0024 §3 reserved D6 for INT1 (interrupt-driven motion detection). Released because v1 LIS3DH is polling-only. v2 interrupt-driven motion would need a new pin (D8/GP8 is free). Acceptable.
• OLED skip becomes permanent for v0.x. The conditional rationale in ADR-0031 §6 (“preserves the option”) is consumed. Acceptable — CIPHER-LINE covers the same use cases at higher fidelity.
• Click gesture is firmware-deferred. v0.1 ships with the QMK PS/2-mouse stock tap-vs-drag threshold; final gesture decision lands during bring-up. Acceptable — the gesture doesn’t affect the BOM order or the hardware build.
• Two-shot soldering risk on the trackpoint daughterboards. Mitigated by ordering one spare KB2040.

---

Consequences

Positive

• Closes the deferred pointing-device question from ADR-0031 §7 + prototype/keyboard-decision.md. The corpus no longer carries a “TBD” on this line.
• Two-handed pointing is a real operator affordance. Either index drives the cursor; no hand-switch tax during typing.
• Genre lock-in. Two red ThinkPad-style trackpoint nubs on a low-profile choc keyplate, framed in 3D-printed matte panels, with an amber CRT-style primary display: this is the Deckline identity in three concrete components.
• LIS3DH pin re-allocation is clean. Moving to I²C1 uses an existing KB2040 peripheral; QMK driver code unchanged; ADR-0023 functional behavior unchanged.
• OLED-skip-as-permanent removes a hedged commitment. Less ambiguity in the spec; the CIPHER-LINE 256×64 is canonically the only auxiliary display.
• Cart-FFI deferral preserves design space. v0.1 doesn’t commit to a pointer cart API; v2 can do dual-pointer ((pointer-a) / (pointer-b)) or merged-pointer or neither depending on what cart authors actually want.

Negative / Accepted costs

• OLED skip is now permanent for v0.x — small loss; CIPHER-LINE covers the use cases.
• LIS3DH INT1 line released — small loss; v1 is polling-only, v2 needs a new pin if interrupt-driven motion is ever wanted.
• Two-shot trackpoint soldering risk — mitigated by ordering one spare KB2040.
• One extra BOM line item per half (~$25-$45 per trackpoint module).
• Bezel insert needs 2× cutouts for trackpoint stems.
• Click gesture is not finalized — v0.1 ships with QMK stock; refinement in bring-up.

Follow-on work this ADR creates

• F1 — Order amendment. Add 2× trackpoint modules + spare red caps + 1× spare KB2040 to the holykeebs Sweep Soldered kit order from ADR-0031 §F1. Owner: Josh.
• F2 — Bezel insert design update. Pelican 1170 inset panel for the keyboard area gains 2× cutouts for trackpoint stems. Owner: Hardware. Blocks F1’s kit arrival? No — bezel can be designed in parallel from holykeebs PCB dimensions + Sprintek SK8707-01 datasheet.
• F3 — QMK keymap update. rules.mk gains pointing_device_driver = ps2_mouse; config.h gets the trackpoint pin map per §3; LIS3DH driver init updates from I²C0 to I²C1 base address. Owner: Platform Engineering. Blocked by F1 (need hardware to validate).
• F4 — Click gesture finalization. Tap-vs-drag threshold tuning + decide whether v0.2 right-click is [SHIFT]+stem-press or a different chord. Owner: Platform Engineering. Blocked by F1 + F3.
• F5 — Bring-up validation. Enumerate mouse events on the Pi via evtest (or equivalent); confirm both halves’ trackpoints contribute to the same cursor; validate click works; validate LIS3DH on I²C1 reports motion events via existing vendor HID report path; validate ambient-glitch system still drives correctly. Owner: Hardware + Platform Engineering.

---

Documentation Updates (REQUIRED — part of the decision, not aspirational)

This ADR lands in a single PR (this one) including the following updates per CLAUDE.md Spec Hygiene Rule 3:

• docs/adr/ADR-0032-sweep-peripheral-commitment.md — this file.
• docs/adr/README.md — append ADR-0032 to the top of the chronological index. Update ADR-0023, ADR-0024, ADR-0031 status notes to reflect amendment by ADR-0032.
• docs/adr/ADR-0023-accelerometer-ambient-glitch.md — add footnote at §5 (sample rate / threshold / pin) noting the I²C peripheral move from I²C0 to I²C1 per ADR-0032 §3; INT1 reservation released. Add footnote at §6 (USB HID transport) noting nothing changes — vendor HID report path is preserved.
• docs/adr/ADR-0024-keyboard-mcu-rp2040-selection.md — second amendment footnote at §3 (after the existing ADR-0031 amendment) noting the master-half LIS3DH I²C peripheral move from I²C0 (D4/D5) to I²C1 (D6/D7); INT1 reservation on D6/GP6 released.
• docs/adr/ADR-0031-ferris-sweep-keyboard-adoption.md — footnotes at §3 (pin map updated for trackpoint + LIS3DH re-pin), §5 (LIS3DH on I²C1 not I²C0), §6 (OLED skip is permanent for v0.x), §7 (pointing device decided: 2× trackpoint, supersedes deferral).
• CLAUDE.md — Canonical Hardware Specification:
  • Keys row: append a clause “Plus 2× trackpoint (Sprintek SK8707-01 modules, one per index finger, mounted between the alpha keys on each half) per ADR-0032.” (Keyboard description is otherwise per ADR-0031.)
  • Accelerometer row: change “I²C0 (KB2040 silkscreen D4/D5, RP2040 GP4/GP5)” to “I²C1 (KB2040 silkscreen D6/D7, RP2040 GP6/GP7) per ADR-0032 §3. Originally I²C0 per ADR-0024 §3 + ADR-0031 §3; moved by ADR-0032 to resolve trackpoint pin conflict.”
• docs/influences/prototype/keyboard-decision.md — annotate the “What this leaves open” item “Pointing device commitment. Trackpoint vs. none. Park; hotswap PCB defers the decision.” with: Closed by ADR-0032 (2026-06-07): 2× trackpoint (one per index finger).
• docs/influences/prototype/holykeebs-buyers-guide.md — update the BOM checklist line for “Pointing device” from the four-option deferral to the decided: “2× trackpoint (Sprintek SK8707-01 modules from holykeebs — one per half, one per index finger). Per ADR-0032.”
• docs/influences/prototype/ferris-sweep.md — annotate the “Pointing device + OLED share one location” section with the resolved choice: 2× trackpoint, OLED permanently skipped.
• docs/device/hardware/keyboard.md — banner already-pending from ADR-0031 §F3; extend the banner to note that ADR-0032 also folds into the pending rewrite (trackpoint + LIS3DH I²C1).
• Project-wide grep sweep for stale claims:
  • “pointing device deferred” / “trackpoint TBD” / “pointing device: open” — must update to reflect 2× trackpoint commitment. Permitted to remain: ADR-0031 design history, this ADR’s options-considered section, _archive/.
  • “LIS3DH on I²C0” / “LIS3DH on D4” / “LIS3DH on GP4” — must update to I²C1 / D6 / GP6 references with this ADR cited. Permitted to remain: ADR-0023 design history (pre-amendment), ADR-0024 §3 historical pin map (with amendment footnote pointing here), ADR-0031 §3 historical pin map (with amendment footnote).
  • “Sweep OLED option” / “128×32 SSD1306 on the Sweep” / “Sweep auxiliary display” — must annotate the permanent skip.

A PR that lands this ADR without ticking the above fails review per CLAUDE.md Spec Hygiene Rule 3.

---

Implementation Queue

Tracked in Notion Tasks DB under the KN86 tag:

Task	Owner	Priority	Depends on
Amend holykeebs Sweep order with 2× trackpoint modules + spare red caps + 1 spare KB2040	Josh	P0	ADR merge
Update bezel insert design for trackpoint stem cutouts (2× cutouts, between alpha keys per half)	Hardware	P0	ADR merge; can be designed in parallel from datasheets
QMK keymap update — pointing_device_driver = ps2_mouse, pin map, LIS3DH I²C1 init	Platform Engineering	P0	Hardware in hand (post F1)
Click-gesture finalization in QMK PS/2-mouse driver	Platform Engineering	P1	Hardware in hand
Bring-up validation: 2× trackpoint → one cursor, LIS3DH on I²C1, ambient-glitch system intact	Hardware + Platform Engineering	P0	F3 + F4
ADR-0031 keyboard.md rewrite (already F3 in ADR-0031) — fold in ADR-0032 changes	Hardware agent	P0	Bring-up complete

---

Narrative (for the design history)

ADR-0031 closed every keyboard-shape question except two: would the Sweep OLED ship, and would there be a pointing device? Both were deferred to “let the operator add later if they want.” A day later, Josh closed both. The OLED stays skipped — permanently, not conditionally; the CIPHER-LINE 256×64 covers what the Sweep’s 128×32 SSD1306 would have. The pointing device commits to 2× trackpoints, one per index finger. Two ThinkPad-style red rubber nubs on a low-profile choc keyplate is the cyberdeck silhouette, and the KN-86 just bought it. The only hardware cost was a pin-map adjustment: both trackpoints want their host MCUs’ I²C0 pins for the holykeebs adapter’s PS/2 protocol, and the master MCU was already hosting the LIS3DH accelerometer on those exact pins per ADR-0023. The KB2040 conveniently exposes a second I²C peripheral on D6/D7; the LIS3DH moves there, an originally-reserved-but-never-used interrupt line is released, and the conflict resolves with one row of the pin table changing. v1 motion handling is polling-only at 25 Hz so the interrupt release costs nothing in v1. A future reader should care because this ADR sets the pattern for how to absorb a hardware add-on after the keyboard ADR has shipped: identify the pin conflict, find the cheapest re-allocation that preserves canonical behavior, and update all the affected docs in the same PR rather than letting the conflict slowly poison the canonical spec.