summaryrefslogtreecommitdiff
path: root/docs/reference_configurator_support.md
diff options
context:
space:
mode:
authorNick Brassel <nick@tzarc.org>2024-05-30 12:00:41 +1000
committerGitHub <noreply@github.com>2024-05-30 12:00:41 +1000
commit6ef97172889ccd5db376b2a9f8825489e24fdac4 (patch)
tree334e3bf41c8554d4bee73a140822f95f60eb64e9 /docs/reference_configurator_support.md
parent395766657ff98a4b1fd0dcba5917557f8acbb9e4 (diff)
Vitepress conversion of docs. (#23795)
Diffstat (limited to 'docs/reference_configurator_support.md')
-rw-r--r--docs/reference_configurator_support.md16
1 files changed, 12 insertions, 4 deletions
diff --git a/docs/reference_configurator_support.md b/docs/reference_configurator_support.md
index db6cd80a20..dffed5c0c3 100644
--- a/docs/reference_configurator_support.md
+++ b/docs/reference_configurator_support.md
@@ -21,7 +21,9 @@ To understand how the Configurator understands keyboards, first one must underst
21|---------------| 21|---------------|
22``` 22```
23 23
24?> For more on layout macros, see [Understanding QMK: Matrix Scanning](understanding_qmk.md?id=matrix-scanning) and [Understanding QMK: Matrix to Physical Layout Map](understanding_qmk.md?id=matrix-to-physical-layout-map). 24::: tip
25For more on layout macros, see [Understanding QMK: Matrix Scanning](understanding_qmk#matrix-scanning) and [Understanding QMK: Matrix to Physical Layout Map](understanding_qmk#matrix-to-physical-layout-map).
26:::
25 27
26The Configurator's API reads the keyboard's `.h` file from `qmk_firmware/keyboards/<keyboard>/<keyboard>.h`. For our numpad, this file would be `qmk_firmware/keyboards/numpad/numpad.h`: 28The Configurator's API reads the keyboard's `.h` file from `qmk_firmware/keyboards/<keyboard>/<keyboard>.h`. For our numpad, this file would be `qmk_firmware/keyboards/numpad/numpad.h`:
27 29
@@ -65,9 +67,13 @@ QMK uses `KC_NO` to designate places in the switch matrix where there is no swit
65} 67}
66``` 68```
67 69
68!> This usage differs from that of keymap macros, which almost always use `XXXXXXX` (seven capital X's) for `KC_NO` and `_______` (seven underscores) for `KC_TRNS`. 70::: warning
71This usage differs from that of keymap macros, which almost always use `XXXXXXX` (seven capital X's) for `KC_NO` and `_______` (seven underscores) for `KC_TRNS`.
72:::
69 73
70!> To prevent user confusion, using `KC_NO` is preferred. 74::: warning
75To prevent user confusion, using `KC_NO` is preferred.
76:::
71 77
72The layout macro tells the Configurator that our keyboard has 17 keys, arranged in five rows of four columns each. Our switch positions are named `k<row><column>`, counting from 0. The names themselves actually don't matter, as long as they match between the top section, which receives the keycodes from the keymap, and the bottom half which designates where each key is in the matrix. 78The layout macro tells the Configurator that our keyboard has 17 keys, arranged in five rows of four columns each. Our switch positions are named `k<row><column>`, counting from 0. The names themselves actually don't matter, as long as they match between the top section, which receives the keycodes from the keymap, and the bottom half which designates where each key is in the matrix.
73 79
@@ -141,7 +147,9 @@ The `layouts` object contains the data that represents the physical layout of th
141 147
142Some objects will also have `"w"` and `"h"` keys, which represent a key's width and height, respectively. 148Some objects will also have `"w"` and `"h"` keys, which represent a key's width and height, respectively.
143 149
144?> For more on the `info.json` files, see [`info.json` Format](reference_info_json.md). 150::: tip
151For more on the `info.json` files, see [`info.json` Format](reference_info_json).
152:::
145 153
146 154
147## How the Configurator Programs Keys 155## How the Configurator Programs Keys