diff options
| author | Nick Brassel <nick@tzarc.org> | 2025-02-26 22:25:41 +1100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-02-26 22:25:41 +1100 |
| commit | 1efc82403bebe759272d1ba7a79d9dfa0d5df506 (patch) | |
| tree | c356ae7afeb0849926534beb5dd4515f693abf99 /docs/custom_quantum_functions.md | |
| parent | 63b095212b157c4522bdeda3de144fb87213085d (diff) | |
Community modules (#24848)
Diffstat (limited to 'docs/custom_quantum_functions.md')
| -rw-r--r-- | docs/custom_quantum_functions.md | 11 |
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 | |||
| 9 | We have structured QMK as a hierarchy: | 9 | We 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 | ||
| 15 | Each 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. | 18 | Each 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 | ||
| 17 | When 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. | 20 | When 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 | |||
| 22 | Functions 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 | |||
| 24 | When 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 |
| 102 | For 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. | 109 | For 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 |
