[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, <hand>) tuples, 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)
The <hand> is optional, it should only be used when unilateral_tap = true. By assigning L or R to <hand>, each key can be associated with either the left or right hand.
Once the layout is defined, the key mapping can be described for each layer:
The number and order of entries on each defined layer must be identical with the number and order of entries in matrix_map. White spaces and line breaks are free to vary, but it's worth keeping 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 consume flash and RAM, so if you don't have 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 the toml file format, this is done in a string. RMK parses the string and fills in the actual keymap initializer, like what's in keymap.rs
The layer.keys string should follow several rules:
For a simple keycode (i.e., keys in RMK's KeyCode enum), just fill in 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, <profile_name>) to create a layer activate action or tap key(tap/hold). The key here is the RMK KeyCode, The profile_name is optional, which defines the key's profileOSL(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 these operations are the same as QMK's; you can find them here. If you want other actions, please file an issue.
MT(key, modifier, <profile_name>) where the modifier can be a chain like explained on point 1. The profile_name is optional, which defines the key's profileFor generic key tap-hold, use TH(key-tap, key-hold, <profile_name>), The profile_name is optional, which defines the key's profile
For shifted key, use SHIFTED(key)
For Morse/Tap Dance, use TD(n) or Morse(n), they are same
For keyboard macros, use Macro(n)
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.