docs/custom_quantum_functions.md

   1 # How to Customize Your Keyboard's Behavior
   2
   3 For a lot of people a custom keyboard is about more than sending button presses to your computer. You want to be able to do things that are more complex than simple button presses and macros. QMK has hooks that allow you to inject code, override functionality, and otherwise customize how your keyboard behaves in different situations.
   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.
   6
   7 ## A Word on Core vs Keyboards vs Keymap
   8
   9 We have structured QMK as a hierarchy:
  10
  11 * Core (`_quantum`)
  12   * Keyboard/Revision (`_kb`)
  13     * Keymap (`_user`)
  14
  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.
  16
  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.
  18
  19 # Custom Keycodes
  20
  21 By far the most common task is to change the behavior of an existing keycode or to create a new keycode. From a code standpoint the mechanism for each is very similar.
  22
  23 ## Defining a New Keycode
  24
  25 The first step to creating your own custom keycode(s) is to enumerate them. This means both naming them and assigning a unique number to that keycode. Rather than limit custom keycodes to a fixed range of numbers QMK provides the `SAFE_RANGE` macro. You can use `SAFE_RANGE` when enumerating your custom keycodes to guarantee that you get a unique number.
  26
  27
  28 Here is an example of enumerating 2 keycodes. After adding this block to your `keymap.c` you will be able to use `FOO` and `BAR` inside your keymap.
  29
  30 ```
  31 enum my_keycodes {
  32   FOO = SAFE_RANGE,
  33   BAR
  34 };
  35 ```
  36
  37 ## Programming the Behavior of Any Keycode
  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.
  40
  41 These function are called every time a key is pressed or released.
  42
  43 ### Example `process_record_user()` Implementation
  44
  45 This example does two things. It defines the behavior for a custom keycode called `FOO`, and it supplements our Enter key by playing a tone whenever it is pressed.
  46
  47 ```
  48 bool process_record_user(uint16_t keycode, keyrecord_t *record) {
  49   switch (keycode) {
  50     case FOO:
  51       if (record->event.pressed) {
  52         // Do something when pressed
  53       } else {
  54         // Do something else when release
  55       }
  56       return false; // Skip all further processing of this key
  57     case KC_ENTER:
  58       // Play a tone when enter is pressed
  59       if (record->event.pressed) {
  60         PLAY_NOTE_ARRAY(tone_qwerty);
  61       }
  62       return true; // Let QMK send the enter press/release events
  63     default:
  64       return true; // Process all other keycodes normally
  65   }
  66 }
  67 ```
  68
  69 ### `process_record_*` Function Documentation
  70
  71 * Keyboard/Revision: `bool process_record_kb(uint16_t keycode, keyrecord_t *record)`
  72 * Keymap: `bool process_record_user(uint16_t keycode, keyrecord_t *record)`
  73
  74 The `keycode` argument is whatever is defined in your keymap, eg `MO(1)`, `KC_L`, etc. You should use a `switch...case` block to handle these events.
  75
  76 The `record` argument contains information about the actual press:
  77
  78 ```
  79 keyrecord_t record {
  80 +-keyevent_t event {
  81 | +-keypos_t key {
  82 | | +-uint8_t col
  83 | | +-uint8_t row
  84 | | }
  85 | +-bool     pressed
  86 | +-uint16_t time
  87 | }
  88 }
  89 ```
  90
  91 # LED Control
  92
  93 This allows you to control the 5 LED's defined as part of the USB Keyboard spec. It will be called when the state of one of those 5 LEDs changes.
  94
  95 * `USB_LED_NUM_LOCK`
  96 * `USB_LED_CAPS_LOCK`
  97 * `USB_LED_SCROLL_LOCK`
  98 * `USB_LED_COMPOSE`
  99 * `USB_LED_KANA`
 100
 101 ### Example `led_set_user()` Implementation
 102
 103 ```
 104 void led_set_user(uint8_t usb_led) {
 105     if (usb_led & (1<<USB_LED_NUM_LOCK)) {
 106         PORTB |= (1<<0);
 107     } else {
 108         PORTB &= ~(1<<0);
 109     }
 110     if (usb_led & (1<<USB_LED_CAPS_LOCK)) {
 111         PORTB |= (1<<1);
 112     } else {
 113         PORTB &= ~(1<<1);
 114     }
 115     if (usb_led & (1<<USB_LED_SCROLL_LOCK)) {
 116         PORTB |= (1<<2);
 117     } else {
 118         PORTB &= ~(1<<2);
 119     }
 120     if (usb_led & (1<<USB_LED_COMPOSE_LOCK)) {
 121         PORTB |= (1<<3);
 122     } else {
 123         PORTB &= ~(1<<3);
 124     }
 125     if (usb_led & (1<<USB_LED_KANA_LOCK)) {
 126         PORTB |= (1<<4);
 127     } else {
 128         PORTB &= ~(1<<4);
 129     }
 130 }
 131 ```
 132
 133 ### `led_set_*` Function Documentation
 134
 135 * Keyboard/Revision: `void led_set_kb(uint8_t usb_led)`
 136 * Keymap: `void led_set_user(uint8_t usb_led)`
 137
 138 # Matrix Initialization Code
 139
 140 Before a keyboard can be used the hardware must be initialized. QMK handles initialization of the keyboard matrix itself, but if you have other hardware like LED's or i&#xb2;c controllers you will need to set up that hardware before it can be used.
 141
 142 ### Example `matrix_init_user()` Implementation
 143
 144 This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
 145
 146 ```
 147 void matrix_init_user(void) {
 148   // Call the keymap level matrix init.
 149
 150   // Set our LED pins as output
 151   DDRB |= (1<<1);
 152   DDRB |= (1<<2);
 153   DDRB |= (1<<3);
 154 }
 155 ```
 156
 157 ### `matrix_init_*` Function Documentation
 158
 159 * Keyboard/Revision: `void matrix_init_kb(void)`
 160 * Keymap: `void matrix_init_user(void)`
 161
 162 # Matrix Scanning Code
 163
 164 Whenever possible you should customize your keyboard by using `process_record_*()` and hooking into events that way, to ensure that your code does not have a negative performance impact on your keyboard. However, in rare cases it is necessary to hook into the matrix scanning. Be extremely careful with the performance of code in these functions, as it will be called at least 10 times per second.
 165
 166 ### Example `matrix_scan_*` Implementation
 167
 168 This example has been deliberately omitted. You should understand enough about QMK internals to write this without an example before hooking into such a performance sensitive area. If you need help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) or [chat with us on gitter](https://gitter.im/qmk/qmk_firmware).
 169
 170 ### `matrix_scan_*` Function Documentation
 171
 172 * Keyboard/Revision: `void matrix_scan_kb(void)`
 173 * Keymap: `void matrix_scan_user(void)`
 174
 175 This function gets called at every matrix scan, which is basically as often as the MCU can handle. Be careful what you put here, as it will get run a lot.
 176
 177 You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LED's or a display) or other functionality that you want to trigger regularly even when the user isn't typing.
 178
 179
 180 # Layer Change Code
 181
 182 Thir runs code every time that the layers get changed.  This can be useful for layer indication, or custom layer handling.
 183
 184 ### Example `layer_state_set_*` Implementation
 185
 186 This example shows how to set the [RGB Underglow](feature_rgblight.md) lights based on the layer, using the Planck as an example
 187
 188 ```
 189 uint32_t layer_state_set_user(uint32_t state) {
 190     switch (biton32(state)) {
 191     case _RAISE:
 192         rgblight_setrgb (0x00,  0x00, 0xFF);
 193         break;
 194     case _LOWER:
 195         rgblight_setrgb (0xFF,  0x00, 0x00);
 196         break;
 197     case _PLOVER:
 198         rgblight_setrgb (0x00,  0xFF, 0x00);
 199         break;
 200     case _ADJUST:
 201         rgblight_setrgb (0x7A,  0x00, 0xFF);
 202         break;
 203     default: //  for any other layers, or the default layer
 204         rgblight_setrgb (0x00,  0xFF, 0xFF);
 205         break;
 206     }
 207   return state;
 208 }
 209 ```
 210 ### `matrix_init_*` Function Documentation
 211
 212 * Keyboard/Revision: `void uint32_t layer_state_set_kb(uint32_t state)`
 213 * Keymap: `uint32_t layer_state_set_user(uint32_t state)`
 214
 215 The `state` is the bitmask of the active layers, as explained in the [Keymap Overview](keymap.md#keymap-layer-status)