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 ```c
  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 ```c
  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 ```c
  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 ```c
 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)) {
 121         PORTB |= (1<<3);
 122     } else {
 123         PORTB &= ~(1<<3);
 124     }
 125     if (usb_led & (1<<USB_LED_KANA)) {
 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
 139 # Matrix Initialization Code
 140
 141 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.
 142
 143
 144 ### Example `matrix_init_user()` Implementation
 145
 146 This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
 147
 148 ```c
 149 void matrix_init_user(void) {
 150   // Call the keymap level matrix init.
 151
 152   // Set our LED pins as output
 153   DDRB |= (1<<1);
 154   DDRB |= (1<<2);
 155   DDRB |= (1<<3);
 156 }
 157 ```
 158
 159 ### `matrix_init_*` Function Documentation
 160
 161 * Keyboard/Revision: `void matrix_init_kb(void)`
 162 * Keymap: `void matrix_init_user(void)`
 163
 164 # Matrix Scanning Code
 165
 166 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.
 167
 168 ### Example `matrix_scan_*` Implementation
 169
 170 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 Discord](https://discord.gg/Uq7gcHh).
 171
 172 ### `matrix_scan_*` Function Documentation
 173
 174 * Keyboard/Revision: `void matrix_scan_kb(void)`
 175 * Keymap: `void matrix_scan_user(void)`
 176
 177 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.
 178
 179 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.
 180
 181
 182 # Keyboard Idling/Wake Code
 183
 184 If the board supports it, it can be "idled", by stopping a number of functions.  A good example of this is RGB lights or backlights.   This can save on power consumption, or may be better behavior for your keyboard.
 185
 186 This is controlled by two functions: `suspend_power_down_*` and `suspend_wakeup_init_*`, which are called when the system is board is idled and when it wakes up, respectively.
 187
 188
 189 ### Example suspend_power_down_user() and suspend_wakeup_init_user() Implementation
 190
 191 This example, at the keyboard level, sets up B1, B2, and B3 as LED pins.
 192
 193 ```c
 194 void suspend_power_down_user(void)
 195 {
 196     rgb_matrix_set_suspend_state(true);
 197 }
 198
 199 void suspend_wakeup_init_user(void)
 200 {
 201     rgb_matrix_set_suspend_state(false);
 202 }
 203
 204 ```
 205
 206 ### `keyboard_init_*` Function Documentation
 207
 208 * Keyboard/Revision: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
 209 * Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
 210
 211 # Layer Change Code
 212
 213 This runs code every time that the layers get changed.  This can be useful for layer indication, or custom layer handling.
 214
 215 ### Example `layer_state_set_*` Implementation
 216
 217 This example shows how to set the [RGB Underglow](feature_rgblight.md) lights based on the layer, using the Planck as an example
 218
 219 ```c
 220 uint32_t layer_state_set_user(uint32_t state) {
 221     switch (biton32(state)) {
 222     case _RAISE:
 223         rgblight_setrgb (0x00,  0x00, 0xFF);
 224         break;
 225     case _LOWER:
 226         rgblight_setrgb (0xFF,  0x00, 0x00);
 227         break;
 228     case _PLOVER:
 229         rgblight_setrgb (0x00,  0xFF, 0x00);
 230         break;
 231     case _ADJUST:
 232         rgblight_setrgb (0x7A,  0x00, 0xFF);
 233         break;
 234     default: //  for any other layers, or the default layer
 235         rgblight_setrgb (0x00,  0xFF, 0xFF);
 236         break;
 237     }
 238   return state;
 239 }
 240 ```
 241 ### `layer_state_set_*` Function Documentation
 242
 243 * Keyboard/Revision: `void uint32_t layer_state_set_kb(uint32_t state)`
 244 * Keymap: `uint32_t layer_state_set_user(uint32_t state)`
 245
 246 The `state` is the bitmask of the active layers, as explained in the [Keymap Overview](keymap.md#keymap-layer-status)
 247
 248
 249 # Persistent Configuration (EEPROM)
 250
 251 This allows you to configure persistent settings for your keyboard.  These settings are stored in the EEPROM of your controller, and are retained even after power loss. The settings can be read with `eeconfig_read_kb` and `eeconfig_read_user`, and can be written to using `eeconfig_update_kb` and `eeconfig_update_user`. This is useful for features that you want to be able to toggle (like toggling rgb layer indication).  Additionally, you can use `eeconfig_init_kb` and `eeconfig_init_user` to set the default values for the EEPROM.
 252
 253 The complicated part here, is that there are a bunch of ways that you can store and access data via EEPROM, and there is no "correct" way to do this.  However, you only have a DWORD (4 bytes) for each function.
 254
 255 Keep in mind that EEPROM has a limited number of writes. While this is very high, it's not the only thing writing to the EEPROM, and if you write too often, you can potentially drastically shorten the life of your MCU.
 256
 257 * If you don't understand the example, then you may want to avoid using this feature, as it is rather complicated.
 258
 259 ### Example  Implementation
 260
 261 This is an example of how to add settings, and read and write it. We're using the user keymap for the example here.  This is a complex function, and has a lot going on.  In fact, it uses a lot of the above functions to work!
 262
 263
 264 In your keymap.c file, add this to the top:
 265 ```
 266 typedef union {
 267   uint32_t raw;
 268   struct {
 269     bool     rgb_layer_change :1;
 270   };
 271 } user_config_t;
 272
 273 user_config_t user_config;
 274 ```
 275
 276 This sets up a 32 bit structure that we can store settings with in memory, and write to the EEPROM. Using this removes the need to define variables, since they're defined in this structure. Remember that `bool` (boolean) values use 1 bit, `uint8_t` uses 8 bits, `uint16_t` uses up 16 bits.  You can mix and match, but changing the order can cause issues, as it will change the values that are read and written.
 277
 278 We're using `rgb_layer_change`, for the `layer_state_set_*` function, and use `matrix_init_user` and `process_record_user` to configure everything.
 279
 280 Now, using the `matrix_init_user` code above, you want to add `eeconfig_read_user()` to it, to populate the structure you've just created. And you can then immediately use this structure to control functionality in your keymap.  And It should look like:
 281 ```
 282 void matrix_init_user(void) {
 283   // Call the keymap level matrix init.
 284
 285   // Read the user config from EEPROM
 286   user_config.raw = eeconfig_read_user();
 287
 288   // Set default layer, if enabled
 289   if (user_config.rgb_layer_change) {
 290     rgblight_enable_noeeprom();
 291     rgblight_sethsv_noeeprom_cyan();
 292     rgblight_mode_noeeprom(1);
 293   }
 294 }
 295 ```
 296 The above function will use the EEPROM config immediately after reading it, to set the default layer's RGB color. The "raw" value of it is converted in a usable structure based on the "union" that you created above.
 297
 298 ```
 299 uint32_t layer_state_set_user(uint32_t state) {
 300     switch (biton32(state)) {
 301     case _RAISE:
 302         if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_magenta(); rgblight_mode_noeeprom(1); }
 303         break;
 304     case _LOWER:
 305         if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_red(); rgblight_mode_noeeprom(1); }
 306         break;
 307     case _PLOVER:
 308         if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_green(); rgblight_mode_noeeprom(1); }
 309         break;
 310     case _ADJUST:
 311         if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_white(); rgblight_mode_noeeprom(1); }
 312         break;
 313     default: //  for any other layers, or the default layer
 314         if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_cyan(); rgblight_mode_noeeprom(1); }
 315         break;
 316     }
 317   return state;
 318 }
 319 ```
 320 This will cause the RGB underglow to be changed ONLY if the value was enabled.  Now to configure this value, create a new keycode for `process_record_user` called `RGB_LYR` and `EPRM`. Additionally, we want to make sure that if you use the normal RGB codes, that it turns off  Using the example above, make it look this:
 321 ```
 322
 323 bool process_record_user(uint16_t keycode, keyrecord_t *record) {
 324   switch (keycode) {
 325     case FOO:
 326       if (record->event.pressed) {
 327         // Do something when pressed
 328       } else {
 329         // Do something else when release
 330       }
 331       return false; // Skip all further processing of this key
 332     case KC_ENTER:
 333         // Play a tone when enter is pressed
 334         if (record->event.pressed) {
 335             PLAY_NOTE_ARRAY(tone_qwerty);
 336         }
 337         return true; // Let QMK send the enter press/release events
 338     case EPRM:
 339         if (record->event.pressed) {
 340             eeconfig_init(); // resets the EEPROM to default
 341         }
 342         return false;
 343     case RGB_LYR:  // This allows me to use underglow as layer indication, or as normal
 344         if (record->event.pressed) {
 345             user_config.rgb_layer_change ^= 1; // Toggles the status
 346             eeconfig_update_user(user_config.raw); // Writes the new status to EEPROM
 347             if (user_config.rgb_layer_change) { // if layer state indication is enabled,
 348                 layer_state_set(layer_state);   // then immediately update the layer color
 349             }
 350         }
 351         return false; break;
 352     case RGB_MODE_FORWARD ... RGB_MODE_GRADIENT: // For any of the RGB codes (see quantum_keycodes.h, L400 for reference)
 353         if (record->event.pressed) { //This disables layer indication, as it's assumed that if you're changing this ... you want that disabled
 354             if (user_config.rgb_layer_change) {        // only if this is enabled
 355                 user_config.rgb_layer_change = false;  // disable it, and
 356                 eeconfig_update_user(user_config.raw); // write the setings to EEPROM
 357             }
 358         }
 359         return true; break;
 360     default:
 361       return true; // Process all other keycodes normally
 362   }
 363 }
 364 ```
 365 And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. For example, if you want to set rgb layer indication by default, and save the default valued.
 366
 367 ```
 368 void eeconfig_init_user(void) {  // EEPROM is getting reset!
 369   user_config.rgb_layer_change = true; // We want this enabled by default
 370   eeconfig_update_user(user_config.raw); // Write default value to EEPROM now
 371
 372   // use the non noeeprom versions, to write these values to EEPROM too
 373   rgblight_enable(); // Enable RGB by default
 374   rgblight_sethsv_cyan();  // Set it to CYAN by default
 375   rgblight_mode(1); // set to solid by default
 376 }
 377 ```
 378
 379 And you're done.  The RGB layer indication will only work if you want it to. And it will be saved, even after unplugging the board. And if you use any of the RGB codes, it will disable the layer indication, so that it stays on the mode and color that you set it to.
 380
 381 ### 'EECONFIG' Function Documentation
 382
 383 * Keyboard/Revision: `void eeconfig_init_kb(void)`, `uint32_t eeconfig_read_kb(void)` and `void eeconfig_update_kb(uint32_t val)`
 384 * Keymap: `void eeconfig_init_user(void)`, `uint32_t eeconfig_read_user(void)` and `void eeconfig_update_user(uint32_t val)`
 385
 386 The `val` is the value of the data that you want to write to EEPROM.  And the `eeconfig_read_*` function return a 32 bit (DWORD) value from the EEPROM.