Edit the Keymap

This HowTo changes what the keys do. There are two routes — pick by how permanent the change is and how much it changes:

Route	Best for	Recompile?	Survives a reflash?
1. PolyKybdHost Layout Editor	Remapping individual keys, quickly	No	Yes — kept in the keyboard’s EEPROM*
2. QMK firmware source	Permanent keymaps, layers, macros — and behaviour beyond the keymap	Yes	Yes — it is the compiled default

Background on layers and the dynamic keymap is on Keymaps & Layers.

Caution

There is no QMK Configurator or keymap.json route for PolyKybd. The Configurator lists only mainline QMK keyboards, and qmk c2json cannot parse the firmware’s custom keycodes. Use one of the two routes below.

Route 1 — PolyKybdHost Layout Editor (runtime)

The fastest route. Right-click the PolyKybdHost tray icon → Configure Keymap, click a key, pick a keycode, and it’s written to the keyboard over HID immediately — no recompile. It writes a single key at a time (ID_DYNAMIC_KEYMAP_SET_KEYCODE) and the change persists across power cycles.

Full walkthrough and limitations: Keymap Editor.

Note

* The Layout Editor writes to the keyboard’s EEPROM, which is separate from the firmware image, so remaps survive a normal reflash. They revert to the compiled defaults only when a firmware update changes the EEPROM layout or you clear the EEPROM.

Route 2 — QMK firmware source

Editing the firmware does much more than remap keys: new layers, macros, tap-dance, encoder behaviour and any custom QMK logic. It also makes your change the compiled default, so it is on a fresh board and is what you share or submit to the main project.

The keymap data — the keymaps[] array, g_led_config, and encoder_map[] — is stored per variant:

keyboards/polykybd/split72/keymaps/default/keymap.c
keyboards/polykybd/split42/keymaps/default/keymap.c

The shared keymap logic (rendering, HID handling, the QMK callbacks) is in keyboards/polykybd/poly_keymap.c. Both are in the qmk_firmware fork; see Keyboard Variants for why the logic is shared but the data is per-variant.

1. Start from a copy so you can fall back to the default:

   qmk new-keymap -kb polykybd/split72 -km my_keymap    # or /split42

2. Make the change in keymaps[] (each layer is a LAYOUT_left_right_stacked(...) of keycodes):

   Remap / add a layer

   Replace a keycode, or add another [n] = LAYOUT_left_right_stacked(...) entry plus a key that reaches it: MO(n) (momentary) or TG(n) (toggle). The keymap already uses all 12 layers that DYNAMIC_KEYMAP_LAYER_COUNT allows (in the variant’s config.h), so a new layer also needs that count raised. Only layers 0–7 can be changed later in the Keymap Editor. QMK’s keycode reference is at docs.qmk.fm/keycodes.

   Macro / tap-dance / custom

   These need firmware logic, not just data — implement them via the QMK callbacks and reference them from keymaps[]. This is the main reason to use route 2. See Firmware Development.

3. Rebuild and flash per Build & Flash from Source:

   qmk compile -kb polykybd/split72 -km my_keymap

A keymap change appears on the per-key displays automatically — the firmware re-derives every legend from the active layer.

See Contributing if you want to submit a keymap change to the main project.