summaryrefslogtreecommitdiff
path: root/docs/custom_quantum_functions.md
diff options
context:
space:
mode:
authorNick Brassel <nick@tzarc.org>2025-02-26 22:25:41 +1100
committerGitHub <noreply@github.com>2025-02-26 22:25:41 +1100
commit1efc82403bebe759272d1ba7a79d9dfa0d5df506 (patch)
treec356ae7afeb0849926534beb5dd4515f693abf99 /docs/custom_quantum_functions.md
parent63b095212b157c4522bdeda3de144fb87213085d (diff)
Community modules (#24848)
Diffstat (limited to 'docs/custom_quantum_functions.md')
-rw-r--r--docs/custom_quantum_functions.md11
1 files changed, 9 insertions, 2 deletions
diff --git a/docs/custom_quantum_functions.md b/docs/custom_quantum_functions.md
index 1479eb53f6..c69beb055e 100644
--- a/docs/custom_quantum_functions.md
+++ b/docs/custom_quantum_functions.md
@@ -9,12 +9,19 @@ This page does not assume any special knowledge about QMK, but reading [Understa
9We have structured QMK as a hierarchy: 9We have structured QMK as a hierarchy:
10 10
11* Core (`_quantum`) 11* Core (`_quantum`)
12 * Community Module (`_<module>`)
13 * Community Module -> Keyboard/Revision (`_<module>_kb`)
14 * Community Module -> Keymap (`_<module>_user`)
12 * Keyboard/Revision (`_kb`) 15 * Keyboard/Revision (`_kb`)
13 * Keymap (`_user`) 16 * Keymap (`_user`)
14 17
15Each of the functions described below can be defined with a `_kb()` suffix or a `_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level. 18Each of the functions described below can be defined with a `_kb()` suffix or a `_user()` suffix. We intend for you to use the `_kb()` suffix at the Keyboard/Revision level, while the `_user()` suffix should be used at the Keymap level.
16 19
17When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` before executing anything else- otherwise the keymap level function will never be called. 20When defining functions at the Keyboard/Revision level it is important that your `_kb()` implementation call `_user()` at an appropriate location, otherwise the keymap level function will never be called.
21
22Functions at the `_<module>_xxx()` level are intended to allow keyboards or keymaps to override or enhance the processing associated with a [community module](/features/community_modules).
23
24When defining module overrides such as `process_record_<module>()`, the same pattern should be used; the module must invoke `process_record_<module>_kb()` as appropriate.
18 25
19# Custom Keycodes 26# Custom Keycodes
20 27
@@ -99,7 +106,7 @@ These are the three main initialization functions, listed in the order that they
99* `keyboard_post_init_*` - Happens at the end of the firmware's startup process. This is where you'd want to put "customization" code, for the most part. 106* `keyboard_post_init_*` - Happens at the end of the firmware's startup process. This is where you'd want to put "customization" code, for the most part.
100 107
101::: warning 108::: warning
102For most people, the `keyboard_post_init_user` function is what you want to call. For instance, this is where you want to set up things for RGB Underglow. 109For most people, the `keyboard_post_init_user` function is what you want to implement. For instance, this is where you want to set up things for RGB Underglow.
103::: 110:::
104 111
105## Keyboard Pre Initialization code 112## Keyboard Pre Initialization code