holykeebs Trackpoint Module — KN-86 BOM Addition

What it is

The holykeebs trackpoint module is a small daughterboard that mounts under the keyboard controller of a holykeebs Sweep (or Corne) half, exposing a Sprintek SK8707-01 “FlexPoint” pressure-sensing pointing stick through the keyplate between the alpha keys. The stick is the same family of pointing-device hardware ThinkPad laptops have used since 1992 — operator pushes the rubber cap in any direction with a fingertip, the sensor reads X/Y pressure, the controller emits HID mouse-movement events. Click events come from a separate switch (the SK8707-01 itself is pressure-sense only; the click typically lives on a dedicated thumb key, programmed in QMK as a mouse button).

Three components per module:

Component	Role	Notes
Sprintek SK8707-01	The sensor — PS/2-protocol pressure-sensing pointing stick.	4.4–5.25 V VDD, ~890 µA idle, ~3.21 mA active. PS/2 clock + data lines = 2 GPIO from the host MCU.
Adapter PCB	Daughterboard that sits between the controller and the keyboard PCB; routes PS/2 lines to the controller’s I²C-pin pair (SDA/SCL) and provides the mechanical mount for the sensor.	Soldering is one-shot — the docs explicitly warn “After this soldering it’ll become extremely hard to separate the two PCBs.”
Red rubber cap	ThinkPad-style rubber nub the operator’s fingertip presses against.	Replaceable; multiple-pack spares are cheap.

The trackpoint shares the controller’s I²C-pin pair (D4/D5 on the KB2040 silkscreen = GP4/GP5 = I²C0 SDA/SCL). The Sweep PCB must be the post-August-2023 “modified-diode” revision that adds diodes to free those pins from the matrix scan; the stock 2022-or-earlier Sweep PCB hard-wires SDA/SCL into the switch matrix and cannot host a trackpoint. The current holykeebs Sweep PCB revision is the modified-diode one by default — confirmed in holykeebs-buyers-guide.md.

QMK ships a PS/2-mouse driver that decodes the SK8707-01’s stream into standard HID mouse movement. Click is bound to a dedicated thumb key (the canonical pattern on ThinkPads is “spacebar-thumb-press = click”; on the Sweep, it’s a free thumb slot or a chord).

Why 2× (one per index finger)

Most holykeebs Sweep trackpoint builds are 1×: a single trackpoint on the right half (operator’s dominant index finger), an OLED on the left half (status display). KN-86 is going 2× — one trackpoint on each half, with no OLED on either side. The 2× decision was made by Josh on 2026-06-07.

What 2× buys:

Two-handed pointing. Either index finger can drive the cursor. No “switch hands to point” tax during typing — the closer hand drives.
Dual-axis decomposition for specific cart UIs that want it. Future cart-FFI surface (not v0.1) could expose two trackpoints as pointer-a / pointer-b, letting a cart use one for cursor and the other for view-scroll, or two for gimbal-style aiming, or one for X-axis and the other for Y-axis on a coarse-input task.
Symmetry with the Lisp authoring model. The keyboard already has a strong left-half / right-half semantic split (function block / numpad per ADR-0031 §3.1). Adding a trackpoint per half preserves the symmetry — both hands have equivalent capability.
Accessibility hedge. A single-handed operator (injured wrist, repetitive-strain workaround) can still drive the deck from one hand entirely.

What 2× costs:

OLED is mutually excluded on both halves. The trackpoint shares the mount location with the OLED (one peripheral per half per holykeebs Buyer’s Guide). With trackpoint on both halves, the Sweep’s optional 128×32 SSD1306 OLED is not available. This is already the ADR-0031 §6 v0.1 commitment — the CIPHER-LINE 256×64 SSD1322 (ADR-0015) is the authoritative auxiliary display anyway, so the Sweep OLED was already skipped. The 2× trackpoint decision reinforces that skip permanently.
Pin conflict with the LIS3DH on master half (ADR-0023, ADR-0031 §5). LIS3DH was pinned to I²C0 (D4/D5 = GP4/GP5) per ADR-0024 §3 + ADR-0031 §3. The trackpoint also wants D4/D5 (PS/2 over those pins via holykeebs adapter). Two devices, one pin pair, two incompatible protocols (I²C vs PS/2). Resolution: move the LIS3DH on the master half to I²C1 (D6/D7 = GP6/GP7) — the KB2040 breaks out a second I²C peripheral on those pins. The originally-reserved INT1 line (D6 per ADR-0024 §3) is sacrificed to make room — INT1 was reserved for future interrupt-driven motion detection, not currently used; v1 LIS3DH is polling-only at 25 Hz, so losing INT1 costs nothing in v1. Tracked in ADR-0032.
Two PS/2 streams to decode. Each KB2040 runs its own QMK PS/2-mouse driver instance. The slave half’s trackpoint reports through QMK’s split-keyboard inter-half transport to the master, which forwards on the master’s USB HID interface as a second HID mouse-movement contribution. From the Pi’s perspective there’s one mouse device with movement events from either source — clean.
Soldering complexity. Each trackpoint module is a delicate one-shot solder per the docs. Two trackpoints = two opportunities to ruin a controller. Mitigated by careful prep and ordering one spare KB2040.
Click bindings consume thumb keys. ThinkPad-style click is “press the spacebar with your thumb.” KN-86 has 4 thumb keys per ADR-0031 §3.1 (LEFT [EVAL][LSHFT], RIGHT [0][TERM]). None of those four is free for click. Resolution: click semantics live on the SHIFT layer (LSHIFT held + trackpoint stem-direction = click variant), OR a long-press on the stem itself (some Sprintek configurations expose this), OR a single chord (EVAL+TERM = click). Tracked as a follow-up firmware decision in ADR-0032. The cleanest answer is probably “click = press-and-release stem within X ms” — handled in QMK PS/2 mouse driver as a tap-vs-drag threshold.

What KN-86 buys from this addition

A cursor. The KN-86’s prior framing was “the device has no pointer; everything dispatches via keys.” That’s still true philosophically — the deck’s cart-authoring + REPL surface is keyboard-only — but 2× trackpoints quietly unlock:
- Mouse-cursor input for cart UIs that want it. A cart that renders a map, a stat sheet with selectable cells, or a list with hover-preview can use mouse coordinates without the operator hunting for arrow keys. Optional, cart-side.
- nEmacs mouse-select. Click-to-position-cursor inside nEmacs becomes a native gesture. The cursor model (ADR-0016 §3) stays Lisp-primitive-driven for editing; the click is just a fast jump.
- REPL output click-to-copy. Click on a REPL output line to copy it into the input prompt — Emacs-style. Real quality-of-life.
A genre-anchor. Trackpoints are specifically the ThinkPad / vintage-laptop / cyberdeck idiom. Adding one (let alone two) puts the KN-86 firmly in the operator-deck aesthetic family alongside the Cyberdeck Cafe gallery and the QRPπ Pelican build template. Trackpoints read as “this is a serious working machine,” not “this is a toy.”
Aesthetic match for the Pelican 1170 + amber CRT story. Two red rubber nubs on a low-profile choc keyplate, framed in matte 3D-printed inset panels, with an amber primary display behind: this is the Deckline identity in three components. The trackpoints are the missing color accent.

What this leaves open

Click gesture finalization. Press-and-release vs SHIFT-chord vs dedicated chord vs long-press. v1 firmware decision; not blocking the order.
Cart-FFI exposure of pointer events. v0.1 is firmware-only (mouse events flow to nOSh runtime; carts see normal mouse-cursor semantics if they opt in). A future cart-FFI primitive (pointer-state) returning (x y buttons) for cart-side custom handling is a v2 question. Closed by ADR-0035 (2026-06-07): cart-FFI exposure committed for v0.1. Three Tier 1 primitives (cursor-position, on-trackpoint-move, on-trackpoint-click) plus a visibility toggle (cursor-visible!) land in ADR-0005. Surface is cell coordinates on the main 80×25 grid, not pixels; cursor clamps at Row 0 / Row 24 boundaries; visible by default with manifest + FFI hide paths. Right-click and middle-click remain v0.2 questions.
Dual-trackpoint differentiation in cart-FFI. v0.1 merges both into one mouse stream — confirmed by ADR-0035 (cart-FFI exposes the merged cursor only). v2 could expose them as (pointer-a) / (pointer-b) for carts that want dual-pointer input. Still not committed.
Sensitivity calibration. ThinkPad-style trackpoints have a huge range of perceived feel based on the speed/acceleration curves applied in firmware. v1 default: QMK’s stock PS/2-mouse acceleration. Operators may want to tune; expose via nosh-config.toml post-v0.1.

Notes

Cross-link keyboard-decision.md — the original Batch 5 doc deferred the pointing-device commitment. This entry closes that deferral as 2× trackpoint (one per index finger).
Cross-link holykeebs-buyers-guide.md — the BOM checklist gets a “Pointing device: 2× trackpoint (one per half)” line. The OLED line stays “skip for v0.1.”
Cross-link ferris-sweep.md — the Sweep product entry notes the trackpoint as an integrated build option; this entry is the dedicated reference for it.
Cross-link ADR-0032 — the ADR that ratifies the 2× trackpoint adoption + LIS3DH I²C re-pinning.
Cross-link crkbd-trackpoint — community Corne+trackpoint reference for build-pattern cross-checking.