Skip to content
KN-86 Deckline

KN-86 Keyboard Decision — Ferris Sweep, not custom

Decision date: 2026-06-06 Decided by: Josh

⭐ DECISION

Section titled “⭐ DECISION”

The KN-86 will use a Ferris Sweep rather than a fully custom keyboard.

Rationale: the Ferris Sweep gives us a proven 34-key split layout and a pre-designed, manufacturable PCB (hotswap + diodes on the current holykeebs revision), removing the risk and time cost of designing our own matrix / plate / PCB. The custom-keyboard research below is retained as background knowledge (plate manufacturing, matrix theory, firmware), not as the build path.

The Ferris Sweep is the single keyboard the KN-86 will be built around. Order target: holykeebs’ Ferris Sweep PCB set, configured per the BOM checklist in holykeebs-buyers-guide.md.

Implications for canonical hardware spec

Section titled “Implications for canonical hardware spec”

This decision changes two values currently locked in CLAUDE.md’s Canonical Hardware Specification and in ADR-0024. Both require a follow-up spec PR to align:

  1. Key count: 31 → 34. Canonical spec currently reads “31 physical keys (14 function + 16 numpad + 1 TERM, phone-layout).” The Ferris Sweep is a 34-key split. The key-layout planning — how the 14-FN / 16-numpad / 1-TERM functions distribute across the Sweep’s 34 split keys + layered firmware mappings — is its own follow-up scoping exercise.
  2. PCB path: custom 31-key (preferred) → Ferris Sweep (decided). ADR-0024 currently reads: “PCB path is custom-fab unified 31-key (preferred) or modified split layout (Corne / Ferris Sweep) reconnected under a single keyplate (fallback).” The preferred and fallback paths swap places. Ferris Sweep moves from fallback to decided; custom 31-key moves to background-knowledge-only.

Both updates land in a separate spec/ADR PR; this decision doc is the canonical reference the PR points back to.

What remains locked from prior decisions

Section titled “What remains locked from prior decisions”

The decision does not change these existing canonical commitments:

  • Kailh Choc v1 hotswap switches — Sweep’s current holykeebs PCB revision ships hotswap sockets + diodes; switch family stays Kailh Choc v1.
  • MBK low-profile keycaps — Sweep supports MBK; canonical keycap commitment unchanged.
  • RP2040-class controller — Sweep ships with RP2040 controllers as the holykeebs default; replaces ADR-0024’s Adafruit KB2040 / Sea-Picro fallback explicitly with the holykeebs RP2040 path.
  • 3D-printed enclosure — Sweep’s 3D-printed case integrates with the cyberdeck enclosure plan (cf. QRPπ Pelican-1170 build template; Adamow and TechNIK cyberdeck STLs for shell aesthetic).
  • Pelican 1170 chassis — unchanged; the Sweep is the input device inside the chassis, not a replacement for the chassis.

What gets archived

Section titled “What gets archived”

The custom-keyboard research from this batch and prior work moves to background-knowledge-only status. Everything below is reference material the team has learned from but is no longer building from:

Firmware decision

Section titled “Firmware decision”

Prefer QMK / Vial over KMK on the Sweep’s RP2040. Reasons:

  • KMK is on limited life support as of 2026 (per the KMK firmware repo README) — “no longer actively maintained / limited life support.” We don’t want to build the deck’s input substrate on a project in maintenance-mode wind-down.
  • QMK is the dominant ecosystem for the Sweep family — David Barr’s original Sweep and the holykeebs revisions both ship with QMK keymap defaults; community keymaps, layer-management idioms, and tap-dance / combo conventions all live in QMK.
  • Vial gives us a GUI-editable keymap layered over QMK, which simplifies the iterative key-layout work (mapping the 14-FN / 16-numpad / 1-TERM canonical functions onto the Sweep’s 34 split keys + layers) without rebuilding firmware on each iteration.

Retain the KMK guides and the KMK firmware entry for two specific reasons even though we’re not using KMK:

  1. The drag-drop CircuitPython workflow (no compile; copy code.py to the CIRCUITPY USB drive) is a useful contrast — knowing the workflow exists informs the QMK firmware-flash UX we’ll document for KN-86 owners.
  2. The NeoPixel diagnostic color codes documented in the KMK guide (rainbow = factory state, 2 red flashes = code error, green = no code.py, etc.) are independently useful as a “deck status LED” idea for the KN-86 hardware — a single NeoPixel on the deck that surfaces system state through a documented color vocabulary. Worth carrying forward.

Order configuration — key decisions

Section titled “Order configuration — key decisions”

Pulled from holykeebs-buyers-guide.md and confirmed here for the order:

OptionChoiceReasoning
Build tierSoldered kit (not just PCB-and-diodes, not fully assembled)Surface-mount components pre-soldered; switch hotswap socket population + plate/case assembly remain ours, so we control switch and keycap selection. Saves the SMD soldering risk; preserves the customization we need.
ControllerRP2040 (holykeebs default)More flash storage than Pro Micro; QMK + Vial support; matches the rest of the KN-86 RP2040-family commitment (the Pi Pico 2 coprocessor on ADR-0017 is also RP-family).
Controller socketCustom low-profile headers (5mm stack) — NOT machine headers (7.5mm)Slim-deck commitment; the 2.5mm height delta matters in the Pelican-1170 internal volume budget.
Switch socketsHotswap (current holykeebs revision default)Don’t commit to a switch family for v0.1 — the operator can swap Kailh Choc v1 family within the deck without desoldering.
Key spacingChoc 18×17mm (not MX 19×19mm)Matches the Kailh Choc v1 switch commitment; compact-deck silhouette.
KeycapsMBK low-profileAlready canonical; matches the existing decision.
Pointing deviceTrackpoint (left side) OR no pointing deviceTrackpoint is laptop-recognizable, keyboard-home-row-stays-home. Pointing device and OLED share one mounting location per side, so if we want both they must be on opposite halves of the split. Open question: do we want any pointing device at all on a Deckline-style cyberpunk handheld? Park; can be deferred since hotswap PCB doesn’t preclude either choice.
OLED128×32 OLED (right side, if pointing device on left)Layer indicator / WPM display / status surface. Composes with the keyboard-status-LED idea into a small KN-86-deck-side state vocabulary.
PlatesTop, middle, bottom — TBD per holykeebs Buyer’s Guide pageSpecify when finalizing the order; depends on whether we want acoustic dampening (gasket-mount style) or low-profile slim. Slim is the canonical Deckline direction.
Case3D-printed (holykeebs supplied OR our own print)Match the Pelican-1170 internal-bezel color/finish. Can substitute our own STL per the Adamow / TechNIK cyberdeck aesthetic lineage.

What this resolves

Section titled “What this resolves”
  • Risk: designing a custom PCB carries fab-iteration risk, plate-cutout-tolerance risk, matrix-debouncing-firmware risk. All gone — Sweep is a manufacturable, shipping product on its current revision.
  • Time: designing, fabbing, testing, and iterating a custom PCB is 2-4 months of bring-up time the project doesn’t need to spend. Order from holykeebs, build, move on.
  • Community knowledge: the Sweep has an active community, working QMK firmware, dozens of published builds, well-understood quirks. Lower long-tail debugging cost than custom-fab.
  • Open-hardware ethos preserved: the Sweep is open-source hardware (David Barr’s original; holykeebs revisions also open). KN-86 inherits the open-hardware lineage (x0xb0x, Cyberdeck Cafe) without authoring our own PCB.

What this leaves open

Section titled “What this leaves open”
  • Key-mapping layer design. 14 function + 16 numpad + 1 TERM = 31 canonical KN-86 functions onto Sweep’s 34 split keys + QMK layers. Needs scoping. The phone-layout numpad commitment (per ADR-0016) doesn’t survive the split geometry literally; the spirit (numpad as a recognizable cluster) needs translation. Open question.
  • Pointing device commitment. Trackpoint vs. none. Park; hotswap PCB defers the decision. Closed by ADR-0032 (2026-06-07): 2× holykeebs trackpoint modules (Sprintek SK8707-01), one per index finger. See trackpoint-module.md for the operator-facing capability description. OLED option permanently skipped for v0.x as a consequence (mutually exclusive with trackpoint on the same half).
  • Top-plate aesthetic. Slim low-profile is the direction; specific plate material (FR4, PC, aluminum) and color TBD.
  • Sweep-as-input-device + Pelican-1170-as-chassis integration. The Sweep mounts inside the Pelican on its 3D-printed bezel insert (per the QRPπ structural template). Bezel design — keyplate cutout dimensions, depth tolerance, retention strategy — is its own bring-up task.

References

Section titled “References”