KMK firmware

Source: https://github.com/KMKfw/kmk_firmware
Category: research — firmware fallback option; not the chosen path
Role for KN-86: archived background. KN-86 uses QMK + Vial on the Ferris Sweep, per keyboard-decision.md. KMK is here as the fallback reference and for the workflow-UX contrast.
License / caveats: GPL v3 (firmware code). Docs and hardware files: CC-BY-SA 4.0. Repo explicitly forbids Copilot-derived contributions. ⚠️ Project is on limited life support — README states “no longer actively maintained / limited life support.”

What it is

KMK is a CircuitPython-based keyboard firmware. The pitch: write your entire keymap in a single Python file (code.py) sitting on the controller’s CircuitPython USB drive, drop the KMK directory in alongside it, and the board runs the keymap. No compile step, no toolchain install, drag-drop iteration. Features include split-keyboard support (two halves connected via UART/TRRS, dynamic key-position remapping per half), chainable / tap-dance keys, Unicode and emoji macros, RGB matrix support, and Bluetooth HID on supported boards. Requires CircuitPython ≥ 8.0.

Why this isn’t the chosen firmware

Per keyboard-decision.md:

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

KMK is on limited life support as of 2026

QMK is the dominant ecosystem for the Sweep family

Vial gives us a GUI-editable keymap layered over QMK

KMK’s “no compile, edit Python on the USB drive” workflow is meaningfully friendlier than QMK’s compile-and-flash cycle. The trade-off the KN-86 project is making: community gravity + active maintenance > developer-friendlier iteration UX. QMK + Vial together close most of the iteration-UX gap (Vial lets you edit the keymap from a GUI without rebuilding firmware); the maintenance and community-support deltas don’t close.

What’s worth keeping from this entry

The Bluetooth HID feature is worth knowing about. The KN-86’s deck is wired — the Sweep connects to the host Pi Zero 2 W via USB inside the Pelican-1170 chassis, not over BT. But if a future KN-9x sister product wants a wireless input device (the KN-90T Toneline or KN-90S Statline could plausibly want this), KMK is the cleaner Bluetooth HID story than QMK (whose BT support is much more limited).
The “edit Python on a USB drive” iteration model is the right reference for KN-86’s cart-authoring iteration UX (not the deck firmware). When we document the KN-86 cart-authoring workflow, the bar to clear is “as approachable as KMK’s drag-drop Python.” The cart actually runs KEC Lisp inside the nOSh runtime, not CircuitPython, so the literal mechanism differs — but the UX target is the same.

License notes

GPL v3 for the firmware code itself. KN-86 isn’t vendoring or distributing KMK, so the GPL terms don’t propagate to the project — but worth being explicit that the KN-86 firmware path (QMK) is also GPL, so there’s no license-incompatibility surprise if we ever cross-pollinate ideas between QMK and KMK.
CC-BY-SA 4.0 for the docs and hardware files. Citable with attribution + share-alike for derivative documentation.
No Copilot-derived contributions policy from the repo. Worth noting because some KN-86 contributors may be using Copilot or similar coding assistants; if anyone is reading the KMK source to inform KN-86 firmware decisions, they should be aware that KMK’s own contribution model forbids assistant-derived code. (This doesn’t constrain KN-86’s own contribution policies, just notes the upstream stance.)

Image

No image downloaded.

Notes

Cross-link keyboard-decision.md — the decision that places KMK in fallback-only status.
Cross-link golem-kmk-firmware.md — the GOLEM walkthrough using KMK on a KB2040, including the NeoPixel-status-LED idea we are lifting.
Cross-link ferris-sweep.md — the keyboard this would have been the firmware for in an alternate-path scenario.
Re-evaluate periodically. “Limited life support” can swing back to active development; if KMK ever revives, the firmware decision is worth revisiting. Quarterly check.