diff options
Diffstat (limited to 'docs/custom_quantum_functions.md')
| -rw-r--r-- | docs/custom_quantum_functions.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/custom_quantum_functions.md b/docs/custom_quantum_functions.md index 9c8f89ae1..84ae589ed 100644 --- a/docs/custom_quantum_functions.md +++ b/docs/custom_quantum_functions.md | |||
| @@ -4,7 +4,7 @@ For a lot of people a custom keyboard is about more than sending button presses | |||
| 4 | 4 | ||
| 5 | This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk.md) will help you understand what is going on at a more fundamental level. | 5 | This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk.md) will help you understand what is going on at a more fundamental level. |
| 6 | 6 | ||
| 7 | ## A Word on Core vs Keyboards vs Keymap | 7 | ## A Word on Core vs Keyboards vs Keymap :id=a-word-on-core-vs-keyboards-vs-keymap |
| 8 | 8 | ||
| 9 | We have structured QMK as a hierarchy: | 9 | We have structured QMK as a hierarchy: |
| 10 | 10 | ||
| @@ -34,7 +34,7 @@ enum my_keycodes { | |||
| 34 | }; | 34 | }; |
| 35 | ``` | 35 | ``` |
| 36 | 36 | ||
| 37 | ## Programming the Behavior of Any Keycode | 37 | ## Programming the Behavior of Any Keycode :id=programming-the-behavior-of-any-keycode |
| 38 | 38 | ||
| 39 | When you want to override the behavior of an existing key, or define the behavior for a new key, you should use the `process_record_kb()` and `process_record_user()` functions. These are called by QMK during key processing before the actual key event is handled. If these functions return `true` QMK will process the keycodes as usual. That can be handy for extending the functionality of a key rather than replacing it. If these functions return `false` QMK will skip the normal key handling, and it will be up to you to send any key up or down events that are required. | 39 | When you want to override the behavior of an existing key, or define the behavior for a new key, you should use the `process_record_kb()` and `process_record_user()` functions. These are called by QMK during key processing before the actual key event is handled. If these functions return `true` QMK will process the keycodes as usual. That can be handy for extending the functionality of a key rather than replacing it. If these functions return `false` QMK will skip the normal key handling, and it will be up to you to send any key up or down events that are required. |
| 40 | 40 | ||
| @@ -313,7 +313,7 @@ void suspend_wakeup_init_user(void) { | |||
| 313 | * Keyboard/Revision: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)` | 313 | * Keyboard/Revision: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)` |
| 314 | * Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)` | 314 | * Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)` |
| 315 | 315 | ||
| 316 | # Layer Change Code | 316 | # Layer Change Code :id=layer-change-code |
| 317 | 317 | ||
| 318 | This runs code every time that the layers get changed. This can be useful for layer indication, or custom layer handling. | 318 | This runs code every time that the layers get changed. This can be useful for layer indication, or custom layer handling. |
| 319 | 319 | ||
