diff options
| -rw-r--r-- | docs/keymap.md | 20 |
1 files changed, 16 insertions, 4 deletions
diff --git a/docs/keymap.md b/docs/keymap.md index ba358edbe0..ef476e87f5 100644 --- a/docs/keymap.md +++ b/docs/keymap.md @@ -71,10 +71,22 @@ On the other hand, you can change `layer_state` to overlay the base layer with o ### Layer Precedence and Transparency -Note that ***higher layer has higher priority on stack of layers***, namely firmware falls down from top layer to bottom to look up keycode. Once it spots keycode other than **`KC_TRNS`**(transparent) on a layer it stops searching and lower layers aren't referred. - -You can place `KC_TRANS` on overlay layer changes just part of layout to fall back on lower or base layer. -Key with `KC_TRANS` (`KC_TRNS` and `_______` are the alias) doesn't has its own keycode and refers to lower valid layers for keycode, instead. +Note that ***higher layers have higher priority within the stack of layers***. The firmware works its way down from the highest active layers to look up keycodes. Once the firmware locates a keycode other than `KC_TRNS` (transparent) on an active layer, it stops searching, and lower layers aren't referenced. + + ____________ + / / <--- Higher layer + / KC_TRNS // + /___________// <--- Lower layer (KC_A) + /___________/ + + In the above scenario, the non-transparent keys on the higher layer would be usable, but whenever `KC_TRNS` (or equivalent) is defined, the keycode (`KC_A`) on the lower level would be used. + +**Note:** Valid ways to denote transparency on a given layer: +* `KC_TRANSPARENT` +* `KC_TRNS` (alias) +* `_______` (alias) + +These keycodes allow the processing to fall through to lower layers in search of a non-transparent keycode to process. ## Anatomy of a `keymap.c` |