Include bottom row outer keys in the generated keymaps?

[opulpo]

On a Planck layout, the generated keymaps do not allow mapping the outer keys of the bottom row. While they’re not in Arsenik’s spec, they could perhaps be mapped to KC_NO by default, so that users can still map them afterwards.

As a dirty workaround, I edited layouts.h in my config to have them included, adding k57~k5c to the base Arsenik/OneDeadKey layouts. Was there a cleaner way to do this?

[severindupouy]

XX is already KC_NO (see definition in shared/keycodes.h).

aekeynox won't support those extra keys. The intent is to project one fixed logical layout onto many physical boards — keys outside that model are left dead on purpose.

The right way to use them is what you found: overriding layouts.h in your own config. Per-user, not upstreamed.

Two ways to do it, depending on how much you want.

Easy — fixed keys (1 edit). Same keycode across all layers. In your layouts.h geometry block (LAYOUT_planck_grid / LAYOUT_ortho_4x12), swap the corner XX for the keycode you want:

KC_TAB, KC_LGUI, XX,  k53, k51, k52,  k55, k56, k54,  XX, KC_VOLU, KC_VOLD

Advanced — layer-aware (3 edits). Each layer binds those keys independently. They need real slots threaded through the macro:

1. layouts.h — add k57…k5c to the ARSENIK_LAYOUT signature (and forward them to ONEDEADKEY_LAYOUT).
2. layouts.h — in your geometry block, map them physically (replace the corner XX with k57…k5c).
3. keymap.c — pass 6 extra values in every ARSENIK_LAYOUT(...) layer

More work, but it's the only way to get per-layer bindings.

But honestly, the advanced path is almost pointless under aekeynox's philosophy. The layout already exposes every keycode you'd want across its layers — that's the whole design. Adding per-layer corners just duplicates access you already have, so the extra keys are largely useless here. Fixed keys is the right path: in practice you'll bind those corners to keycodes that already live in the keymap anyway.

[opulpo]

Thanks for the feedback. I did not realize I could do it the easy way.

These keys do have their uses when not in a touch-typing position, but indeed having per-layer bindings for them is probably overkill.