ahoneybun/qmk_firmware
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Vitepress conversion of docs. (#23795)

Browse source
This commit is contained in:
Nick Brassel 2024-05-30 12:00:41 +10:00 • committed by GitHub
parent 395766657f
commit 6ef9717288
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
357 changed files with 3611 additions and 24208 deletions
Download patch file Download diff file Expand all files Collapse all files

18
docs/configurator_default_keymaps.md
View file

@ -1,9 +1,9 @@
# Adding Default Keymaps to QMK Configurator :id=adding-default-keymaps
# Adding Default Keymaps to QMK Configurator {#adding-default-keymaps}
This page covers how to add a default keymap for a keyboard to QMK Configurator.
## Technical Information :id=technical-information
## Technical Information {#technical-information}
QMK Configurator uses JSON as its native file format for keymaps. As much as possible, these should be kept such that they behave the same as running `make <keyboard>:default` from `qmk_firmware`.
@ -27,7 +27,7 @@ f14629ed1cd7c7ec9089604d64f29a99981558e8 Remove/migrate action_get_macro()s from
In this example, `f14629ed1cd7c7ec9089604d64f29a99981558e8` is the value that should be used for `commit`.
## Example :id=example
## Example {#example}
If one wished to add a default keymap for the H87a by Hineybush, one would run the `git log` command above against the H87a's default keymap in `qmk_firmware`:
@ -96,9 +96,9 @@ The default keymap uses the `LAYOUT_all` macro, so that will be the value of the
The white space in the `layers` arrays have no effect on the functionality of the keymap, but are used to make these files easier for humans to read.
## Caveats :id=caveats
## Caveats {#caveats}
### Layers can only be referenced by number :id=layer-references
### Layers can only be referenced by number {#layer-references}
A common QMK convention is to name layers using a series of `#define`s, or an `enum` statement:
@ -112,11 +112,11 @@ enum layer_names {
This works in C, but for Configurator, you *must* use the layer's numeric index – `MO(_FN)` would need to be `MO(2)` in the above example.
### No support for custom code of any kind :id=custom-code
### No support for custom code of any kind {#custom-code}
Features that require adding functions to the keymap.c file, such as Tap Dance or Unicode, can not be compiled in Configurator **at all**. Even setting `TAP_DANCE_ENABLE = yes` in the `qmk_firmware` repository at the keyboard level will prevent Configurator from compiling **any** firmware for that keyboard. This is limited both by the API and the current spec of our JSON keymap format.
### Limited Support for Custom keycodes :id=custom-keycodes
### Limited Support for Custom keycodes {#custom-keycodes}
There is a way to support custom keycodes: if the logic for a custom keycode is implemented at the keyboard level instead of the keymap level in qmk_firmware, that keycode *can* be used in Configurator and it *will* compile and work. Instead of using the following in your `keymap.c`:
@ -186,6 +186,6 @@ bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
Note the call to `process_record_user()` at the end.
## Additional Reading :id=additional-reading
## Additional Reading {#additional-reading}
For QMK Configurator to support your keyboard, your keyboard must be present in the `master` branch of the `qmk_firmware` repository. For instructions on this, please see [Supporting Your Keyboard in QMK Configurator](reference_configurator_support.md).
For QMK Configurator to support your keyboard, your keyboard must be present in the `master` branch of the `qmk_firmware` repository. For instructions on this, please see [Supporting Your Keyboard in QMK Configurator](reference_configurator_support).