<spanclass="line"><span> 0 /___________/ V low 0 `--------------------------</span></span></code></pre></div><p>Sometimes, the action code stored in keymap may be referred as keycode in some documents due to the TMK history.</p><h3id="keymap-layer-status"tabindex="-1">Keymap Layer Status <aclass="header-anchor"href="#keymap-layer-status"aria-label="Permalink to "Keymap Layer Status {#keymap-layer-status}""></a></h3><p>The state of the Keymap layer is determined by two 32 bit parameters:</p><ul><li><strong><code>default_layer_state</code></strong> indicates a base keymap layer (0-31) which is always valid and to be referred (the default layer).</li><li><strong><code>layer_state</code></strong> has current on/off status of each layer in its bits.</li></ul><p>Keymap layer '0' is usually the <code>default_layer</code>, with other layers initially off after booting up the firmware, although this can configured differently in <code>config.h</code>. It is useful to change <code>default_layer</code> when you completely switch a key layout, for example, if you want to switch to Colemak instead of Qwerty.</p><divclass="language- vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang"></span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><span>Initial state of Keymap Change base layout</span></span>
<spanclass="line"><span> layer_state = 0x00000001 layer_state = 0x00000002</span></span></code></pre></div><p>On the other hand, you can change <code>layer_state</code> to overlay the base layer with other layers for features such as navigation keys, function keys (F1-F12), media keys, and/or special actions.</p><divclass="language- vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang"></span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><span>Overlay feature layer</span></span>
<spanclass="line"><span> layer_state = 0x60000002 <-'</span></span></code></pre></div><h3id="layer-precedence-and-transparency"tabindex="-1">Layer Precedence and Transparency <aclass="header-anchor"href="#layer-precedence-and-transparency"aria-label="Permalink to "Layer Precedence and Transparency""></a></h3><p>Note that <em><strong>higher layers have higher priority within the stack of layers</strong></em>. The firmware works its way down from the highest active layers to look up keycodes. Once the firmware locates a keycode other than <code>KC_TRNS</code> (transparent) on an active layer, it stops searching, and lower layers aren't referenced.</p><divclass="language- vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang"></span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><span> ____________</span></span>
<spanclass="line"><span>/___________/</span></span></code></pre></div><p>In the above scenario, the non-transparent keys on the higher layer would be usable, but whenever <code>KC_TRNS</code> (or equivalent) is defined, the keycode (<code>KC_A</code>) on the lower level would be used.</p><p><strong>Note:</strong> Valid ways to denote transparency on a given layer:</p><ul><li><code>KC_TRANSPARENT</code></li><li><code>KC_TRNS</code> (alias)</li><li><code>_______</code> (alias)</li></ul><p>These keycodes allow the processing to fall through to lower layers in search of a non-transparent keycode to process.</p><h2id="anatomy-of-a-keymap-c"tabindex="-1">Anatomy of a <code>keymap.c</code><aclass="header-anchor"href="#anatomy-of-a-keymap-c"aria-label="Permalink to "Anatomy of a `keymap.c`""></a></h2><p>For this example we will walk through an <ahref="https://github.com/qmk/qmk_firmware/blob/ca01d94005f67ec4fa9528353481faa622d949ae/keyboards/clueboard/keymaps/default/keymap.c"target="_blank"rel="noreferrer">older version of the default Clueboard 66% keymap</a>. You'll find it helpful to open that file in another browser window so you can look at everything in context.</p><p>There are 2 main sections of a <code>keymap.c</code> file you'll want to concern yourself with:</p><ul><li><ahref="#definitions">The Definitions</a></li><li><ahref="#layers-and-keymaps">The Layer/Keymap Datastructure</a></li></ul><h3id="definitions"tabindex="-1">Definitions <aclass="header-anchor"href="#definitions"aria-label="Permalink to "Definitions""></a></h3><p>At the top of the file you'll find this:</p><divclass="language-c vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang">c</span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">#include</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> QMK_KEYBOARD_H</span></span>
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">};</span></span></code></pre></div><p>These are some handy definitions we can use when building our keymap and our custom function. The <code>GRAVE_MODS</code> definition will be used later in our custom function, and the following <code>_BL</code>, <code>_FL</code>, and <code>_CL</code> defines make it easier to refer to each of our layers.</p><p>Note: You may also find some older keymap files may also have a define(s) for <code>_______</code> and/or <code>XXXXXXX</code>. These can be used in place for <code>KC_TRNS</code> and <code>KC_NO</code> respectively, making it easier to see what keys a layer is overriding. These definitions are now unnecessary, as they are included by default.</p><h3id="layers-and-keymaps"tabindex="-1">Layers and Keymaps <aclass="header-anchor"href="#layers-and-keymaps"aria-label="Permalink to "Layers and Keymaps""></a></h3><p>The main part of this file is the <code>keymaps[]</code> definition. This is where you list your layers and the contents of those layers. This part of the file begins with this definition:</p><divclass="language-c vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang">c</span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">const</span><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;"> uint16_t</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> PROGMEM keymaps</span><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">[]</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">[MATRIX_ROWS][MATRIX_COLS] </span><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">=</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> {</span></span></code></pre></div><p>After this you'll find the layer definitions. Typically you'll have one or more "base layers" (such as QWERTY, Dvorak, or Colemak) and then you'll layer on top of that one or more "function" layers. Due to the way layers are processed you can't overlay a "lower" layer on top of a "higher" layer.</p><p><code>keymaps[][MATRIX_ROWS][MATRIX_COLS]</code> in QMK holds the 16 bit action code (sometimes referred as the quantum keycode) in it. For the keycode representing typical keys, its high byte is 0 and its low byte is the USB HID usage ID for keyboard.</p><divclass="info custom-block"><pclass="custom-block-title">INFO</p><p>TMK from which QMK was forked uses <code>const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS]</code> instead and holds the 8 bit keycode.</p></div><h4id="base-layer"tabindex="-1">Base Layer <aclass="header-anchor"href="#base-layer"aria-label="Permalink to "Base Layer""></a></h4><p>Here is an example of the Clueboard's base layer:</p><divclass="language-c vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang">c</span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">[_BL] </span><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">=</span><spanstyle="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> LAYOUT</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span></span>
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">),</span></span></code></pre></div><p>Some interesting things to note about this:</p><ul><li>The layer is defined using the LAYOUT macro, traditionally defined in the keyboard's <code>.h</code> file.</li><li>The LAYOUT macro takes a single list of keycodes, but we have written it in the C source using embedded whitespace and newlines to visualize where each key is on the physical device.</li><li>The LAYOUT macro hides and handles the mapping to the hardware's key scan matrix.</li><li>Plain keyboard scancodes are prefixed with KC_, while "special" keys are not.</li><li>The upper left key activates custom function 0 (<code>F(0)</code>)</li><li>The "Fn" key is defined with <code>MO(_FL)</code>, which moves to the <code>_FL</code> layer while that key is being held down.</li></ul><h4id="function-overlay-layer"tabindex="-1">Function Overlay Layer <aclass="header-anchor"href="#function-overlay-layer"aria-label="Permalink to "Function Overlay Layer""></a></h4><p>Our function layer is, from a code point of view, no different from the base layer. Conceptually, however, you will build that layer as an overlay, not a replacement. For many people this distinction does not matter, but as you build more complicated layering setups it matters more and more.</p><divclass="language-c vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang">c</span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">[_FL] </span><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">=</span><spanstyle="--shiki-light:#6F42C1;--shiki-dark:#B392F0;"> LAYOUT</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">(</span></span>
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">),</span></span></code></pre></div><p>Some interesting things to note:</p><ul><li>We have used our <code>_______</code> definition to turn <code>KC_TRNS</code> into <code>_______</code>. This makes it easier to spot the keys that have changed on this layer.</li><li>While in this layer if you press one of the <code>_______</code> keys it will activate the key in the next lowest active layer.</li></ul><h1id="nitty-gritty-details"tabindex="-1">Nitty Gritty Details <aclass="header-anchor"href="#nitty-gritty-details"aria-label="Permalink to "Nitty Gritty Details""></a></h1><p>This should have given you a basic overview for creating your own keymap. For more details see the following resources:</p><ul><li><ahref="./keycodes">Keycodes</a></li><li><ahref="./faq_keymap">Keymap FAQ</a></li></ul><p>We are actively working to improve these docs. If you have suggestions for how they could be made better please <ahref="https://github.com/qmk/qmk_firmware/issues/new"target="_blank"rel="noreferrer">file an issue</a>!</p></div></div></main><footerclass="VPDocFooter"data-v-39a288b8data-v-09de1c0f><!--[--><!--]--><divclass="edit-info"data-v-09de1c0f><divclass="edit-link"data-v-09de1c0f><aclass="VPLink link vp-external-link-icon no-icon edit-link-button"href="https://github.com/qmk/qmk_firmware/edit/master/docs/keymap.md"target="_blank"rel="noreferrer"data-v-09de1c0f><!--[--><spanclass="vpi-square-pen edit-link-icon"data-v-09de1c0f></span> Edit this page<!--]--></a></div><!----></div><navclass="prev-next"data-v-09de1c0f><divclass="pager"data-v-09de1c0f><aclass="VPLink link pager-link prev"href="/driver_installation_zadig"data-v-09de1c0f><!--[--><spanclass="desc"data-v-09de1c0f>Previous page</span><spanclass="title"data-v-09de1c0f>Driver Installation with Zadig</span><!--]--></a></div><divclass="pager"data-v-09de1c0f><aclass="VPLink link pager-link next"href="/getting_started_docker"data-v-09de1c0f><!--[--><spanclass="desc"data-v-09de1c0f>Next page</span><spanclass="title"data-v-09de1c0f>Docker Guide</span><!--]--></a></div></nav></footer><!--[--><!--]--></div></div></div><!--[--><!--]--></div></div><!----><!--[--><!--]--></div></div>
