[matrix] defines the physical key matrix on your board, while [layout] section contains the layout and the default keymap for the keyboard:
The matrix_map is a string built from (row, col) coordinate pairs, listed in the same order as you want to define your keys in your key map. The (row, col) coordinates are using zero based indexing and referring to the position in the "electronic matrix" of your keyboard. As you can see in matrix configuration, even the direct pin based keyboards are represented with a matrix. In case of split keyboards, the positions refer to the position in the "big unified matrix" of all split parts. With the help of this matrix map, the configuration of non-regular key matrices can be intuitively arranged in your key maps. (Triple quote mark """ is used to limit multi-line strings
Once the layout is defined, the key mapping can be described for each layer:
The number and order of entries on each defined layers must be identical with the number and order of entries in matrix_map. White spaces, line breaks are free to vary, but its worth to keep a consistent arrangement with the real keyboard.
If the number of defined layers is smaller than what was defined in layout.layers, RMK will fill empty layers automatically (so you can configure them freely in Vial). But the empty layers still consumes flash and RAM, so if you don't have a enough space for them, it's not recommended to use a big layer count.
In each layer.keys, the keys are bound to various key actions. Due to the limitation of toml file, this is done in a string. RMK parses the string and fill the to actual keymap initializer, like what's in keymap.rs
The layer.keys string should follow several rules:
For a simple keycode(aka keys in RMK's KeyCode enum), just fill its name.
For example, if you set a keycode Backspace, it will be turned to KeyCode::Backspace. So you have to ensure that the keycode string is valid, or RMK wouldn't compile! However, to make things easier a number of alternative key names (see alias column in KeyCode table) were added and also case-insensitive search is used to find the valid KeyCode.
For simple keycodes with modifiers active, you can use WM(key, modifier) to create a keypress with modifier action. Modifiers can be chained together like LShift | RGui to have multiple modifiers active.
You may use aliases, prefixed with @, like @my_copy in the above example. The alias names are case sensitive. The definition of aliases is described below.
You may use layer names instead of layer numbers, like TO(base_layer) in the above example.
::: warning
Please note that layer name if used like this, may not contain white spaces and may not be a number. Layer names are case sensitive.
:::
For no-key (KeyAction::No), use No
For transparent key (KeyAction::Transparent), use _ or __ (you can put any number of _)
RMK supports many advanced layer operations:
DF(n) to create a switch default layer action, n is the layer numberMO(n) to create a layer activate action, n is the layer numberLM(n, modifier) to create layer activate with modifier action. The modifier can be chained in the same way as WMLT(n, key) to create a layer activate action or tap key(tap/hold). The key here is the RMK KeyCodeOSL(n) to create a one-shot layer action, n is the layer numberOSM(modifier) to create a one-shot modifier action. The modifier can be chained in the same way as WMTT(n) to create a layer activate or tap toggle action, n is the layer numberTG(n) to create a layer toggle action, n is the layer numberTO(n) to create a layer toggle only action (activate layer n and deactivate all other layers), n is the layer numberThe definitions of those operations are same with QMK, you can found here. If you want other actions, please fire an issue.
For modifier-tap-hold, use MT(key, modifier) where the modifier can be a chain like explained on point 1. For example for a Home row modifier config you can use MT(F, LShift)
For generic key tap-hold, use TH(key-tap, key-hold)
For shifted key, use SHIFTED(key)
The [aliases] section contains a table of user defined names and an associated replacement string, which can be used in the layer.keys:
Please note that alias names may not contain white spaces and they are case sensitive.