Skip to content

Keyboard Variants

PolyKybd ships in two hardware variants. They run one firmware codebase, so a feature added to the keyboard lands on both at once.

split72 vs split42

split72split42
Keys7242
FootprintPolyKybd full-size splitCRKBD / Corne 42-key
RGB matrixYes (72 LEDs)No
Pointing deviceCirque trackpadNo
Status OLED128×64128×32
Per-keycap OLEDs72×40 px monochrome72×40 px monochrome
Build targetpolykybd/split72polykybd/split42

A split72 half — 36 keys, the 128×64 status OLED (here naming the active layout, Colemak DH), and a rotary encoder fitted in the expansion slot:

An assembled split72 left half, each keycap OLED showing its Colemak-DH legend, with the status display reading "2 LEFT / Colemak DH"

The split42 board, which carries 21 keys per half and no RGB or pointing device (KiCad render of the PolyCorne Split42 rev1.0 left side):

KiCad 3D render of the split42 left PCB, silkscreened "PolyCorne Split42, rev1.0"

One shared keymap

All behaviour lives in the keyboard-level poly_keymap.c (compiled for both variants via rules.mk’s SRC): rendering, HID/overlay handling, language selection, idle/suspend, split-sync glue, the firmware-update state machine, and the QMK *_user / *_kb callbacks.

Each variant’s default keymap file is data only — it holds the keymaps[] array, the encoder_map[], and (on RGB variants) the LED config:

keyboards/polykybd/
├── poly_keymap.c ← shared logic, both variants
├── split72/
│ └── keymaps/default/keymap.c ← split72 data only
└── split42/
└── keymaps/default/keymap.c ← split42 data only

Variant differences resolve at compile time: polykybd.h includes the active variant header (selected by QMK’s -DKEYBOARD_polykybd_<variant>), and RGB_MATRIX_ENABLE / POINTING_DEVICE_ENABLE guard the RGB and trackpad code paths.

Building a specific variant

The build target selects the variant:

Terminal window
qmk compile -kb polykybd/split72 -km default
# or
qmk compile -kb polykybd/split42 -km default

See Firmware Development for the full toolchain setup.