summaryrefslogtreecommitdiffstats
path: root/docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md')
-rw-r--r--docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md4
1 files changed, 2 insertions, 2 deletions
diff --git a/docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md b/docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md
index 50d291a23..c32c428cf 100644
--- a/docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md
+++ b/docs/porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md
@@ -54,10 +54,10 @@ This is where all of the custom logic for your keyboard goes - you may not need
## `/keyboards/<keyboard>/<keyboard>.h`
-Here is where you can (optionally) define your `KEYMAP` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accommodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
+Here is where you can (optionally) define your `LAYOUT` function to remap your matrix into a more readable format. With ortholinear boards, this isn't always necessary, but it can help to accommodate the dead spots on your matrix, where there are keys that take up more than one space (2u, staggering, 6.25u, etc). The example shows the difference between the physical keys, and the matrix design:
```
-#define KEYMAP( \
+#define LAYOUT( \
k00, k01, k02, \
k10, k11 \
) \