Public · Embedded input systems
QMK userspace
A production-oriented Vial/QMK firmware environment for a compact split keyboard, treating layers, encoders, display state, persistence and releases as one embedded product rather than a collection of key mappings.
- Niche
- High-capability compact ergonomic input
- Core stack
- C · QMK · Vial · split firmware
- Hardware
- Halcyon Ferris · TFT + encoder halves
- Focus
- Deterministic behavior and persistent configuration
The niche
A 34-key split keyboard only works well when layers and gestures stop feeling like compromises and start behaving like a coherent input language.
The firmware is designed around everyday editing rather than showing off the maximum number of QMK features. The normal alpha layer stays stable while short holds, home-row chords and encoders expose numbers, navigation, modifiers, function keys and controls without requiring persistent mode switching.
What is different
The keyboard is treated as a small stateful embedded system.
Repeat/Alternate Repeat direction remains tied to Vial pair orientation instead of reversing based on whichever key happened to be pressed last.
The TFT communicates layer identity, animated state and diagnostics instead of functioning as a static logo screen.
Per-layer, modifier and chord lighting behavior is modeled as configuration rather than one global effect.
Canonical Vial configuration, firmware defaults, pinned dependencies, regression checks and exact UF2 artifacts are kept auditable.
Product & design thinking
The layout is optimized for brief transitions away from the home typing state.
Numbers arrive under a thumb hold; navigation and function keys arrive through momentary chords; frequent Escape and Enter actions stay on the alpha layer. The goal is to preserve spatial memory and minimize the cognitive cost of a small key count.
Visual and encoder behavior follow the same principle: state should be understandable and direction should remain predictable even when the underlying firmware feature is history-sensitive.
Development approach
Human-editable configuration and compiled defaults have one source of truth.
The committed Vial profile feeds generated firmware defaults; fork-specific Vial-QMK changes remain ordered patches instead of disappearing into a vendor tree. Source regression, firmware build success and physical hardware acceptance are treated as separate evidence classes.
This makes the firmware easier to evolve without confusing “it compiled” with “the keyboard still behaves correctly after suspend, split reconnection or module changes.”