skylark-qmk/docs/custom_quantum_functions.md

How to Customize Your Keyboard's Behavior

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.

This page does not assume any special knowledge about QMK, but reading Understanding QMK will help you understand what is going on at a more fundamental level.

A Word on Core vs Keyboards vs Keymap :id=a-word-on-core-vs-keyboards-vs-keymap

We have structured QMK as a hierarchy:

• Core (_quantum)
  • Keyboard/Revision (_kb)
    • Keymap (_user)

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.

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.

Custom Keycodes

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.

Defining a New Keycode

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.

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.

enum my_keycodes {
  FOO = SAFE_RANGE,
  BAR
};

Programming the Behavior of Any Keycode :id=programming-the-behavior-of-any-keycode

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.

These function are called every time a key is pressed or released.

Example process_record_user() Implementation

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.

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
  switch (keycode) {
    case FOO:
      if (record->event.pressed) {
        // Do something when pressed
      } else {
        // Do something else when release
      }
      return false; // Skip all further processing of this key
    case KC_ENTER:
      // Play a tone when enter is pressed
      if (record->event.pressed) {
        PLAY_SONG(tone_qwerty);
      }
      return true; // Let QMK send the enter press/release events
    default:
      return true; // Process all other keycodes normally
  }
}

process_record_* Function Documentation

• Keyboard/Revision: bool process_record_kb(uint16_t keycode, keyrecord_t *record)
• Keymap: bool process_record_user(uint16_t keycode, keyrecord_t *record)

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.

The record argument contains information about the actual press:

keyrecord_t record {
  keyevent_t event {
    keypos_t key {
      uint8_t col
      uint8_t row
    }
    bool     pressed
    uint16_t time
  }
}

Keyboard Initialization Code

There are several steps in the keyboard initialization process. Depending on what you want to do, it will influence which function you should use.

These are the three main initialization functions, listed in the order that they're called.

• keyboard_pre_init_* - Happens before most anything is started. Good for hardware setup that you want running very early.
• matrix_init_* - Happens midway through the firmware's startup process. Hardware is initialized, but features may not be yet.
• 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.

!> 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.

Keyboard Pre Initialization code

This runs very early during startup, even before the USB has been started.

Shortly after this, the matrix is initialized.

For most users, this shouldn't be used, as it's primarily for hardware oriented initialization.

However, if you have hardware stuff that you need initialized, this is the best place for it (such as initializing LED pins).

Example keyboard_pre_init_user() Implementation

This example, at the keyboard level, sets up B0, B1, B2, B3, and B4 as LED pins.

void keyboard_pre_init_user(void) {
  // Call the keyboard pre init code.

  // Set our LED pins as output
  setPinOutput(B0);
  setPinOutput(B1);
  setPinOutput(B2);
  setPinOutput(B3);
  setPinOutput(B4);
}

keyboard_pre_init_* Function Documentation

• Keyboard/Revision: void keyboard_pre_init_kb(void)
• Keymap: void keyboard_pre_init_user(void)

Matrix Initialization Code

This is called when the matrix is initialized, and after some of the hardware has been set up, but before many of the features have been initialized.

This is useful for setting up stuff that you may need elsewhere, but isn't hardware related nor is dependant on where it's started.

matrix_init_* Function Documentation

• Keyboard/Revision: void matrix_init_kb(void)
• Keymap: void matrix_init_user(void)

Low-level Matrix Overrides Function Documentation :id=low-level-matrix-overrides

• GPIO pin initialisation: void matrix_init_pins(void)
  • This needs to perform the low-level initialisation of all row and column pins. By default this will initialise the input/output state of each of the GPIO pins listed in MATRIX_ROW_PINS and MATRIX_COL_PINS, based on whether or not the keyboard is set up for ROW2COL, COL2ROW, or DIRECT_PINS. Should the keyboard designer override this function, no initialisation of pin state will occur within QMK itself, instead deferring to the keyboard's override.
• COL2ROW-based row reads: void matrix_read_cols_on_row(matrix_row_t current_matrix[], uint8_t current_row)
• ROW2COL-based column reads: void matrix_read_rows_on_col(matrix_row_t current_matrix[], uint8_t current_col, matrix_row_t row_shifter)
• DIRECT_PINS-based reads: void matrix_read_cols_on_row(matrix_row_t current_matrix[], uint8_t current_row)
  • These three functions need to perform the low-level retrieval of matrix state of relevant input pins, based on the matrix type. Only one of the functions should be implemented, if needed. By default this will iterate through MATRIX_ROW_PINS and MATRIX_COL_PINS, configuring the inputs and outputs based on whether or not the keyboard is set up for ROW2COL, COL2ROW, or DIRECT_PINS. Should the keyboard designer override this function, no manipulation of matrix GPIO pin state will occur within QMK itself, instead deferring to the keyboard's override.

Keyboard Post Initialization code

This is ran as the very last task in the keyboard initialization process. This is useful if you want to make changes to certain features, as they should be initialized by this point.

Example keyboard_post_init_user() Implementation

This example, running after everything else has initialized, sets up the rgb underglow configuration.

void keyboard_post_init_user(void) {
  // Call the post init code.
  rgblight_enable_noeeprom(); // enables Rgb, without saving settings
  rgblight_sethsv_noeeprom(180, 255, 255); // sets the color to teal/cyan without saving
  rgblight_mode_noeeprom(RGBLIGHT_MODE_BREATHING + 3); // sets mode to Fast breathing without saving
}

keyboard_post_init_* Function Documentation

• Keyboard/Revision: void keyboard_post_init_kb(void)
• Keymap: void keyboard_post_init_user(void)

Matrix Scanning Code

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.

Example matrix_scan_* Implementation

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 or chat with us on Discord.

matrix_scan_* Function Documentation

• Keyboard/Revision: void matrix_scan_kb(void)
• Keymap: void matrix_scan_user(void)

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.

You should use this function if you need custom matrix scanning code. It can also be used for custom status output (such as LEDs or a display) or other functionality that you want to trigger regularly even when the user isn't typing.

Keyboard housekeeping

• Keyboard/Revision: void housekeeping_task_kb(void)
• Keymap: void housekeeping_task_user(void)

This function gets called at the end of all QMK processing, before starting the next iteration. You can safely assume that QMK has dealt with the last matrix scan at the time that these functions are invoked -- layer states have been updated, USB reports have been sent, LEDs have been updated, and displays have been drawn.

Similar to matrix_scan_*, these are called as often as the MCU can handle. To keep your board responsive, it's suggested to do as little as possible during these function calls, potentially throtting their behaviour if you do indeed require implementing something special.

Keyboard Idling/Wake Code

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.

This is controlled by two functions: suspend_power_down_* and suspend_wakeup_init_*, which are called when the system board is idled and when it wakes up, respectively.

Example suspend_power_down_user() and suspend_wakeup_init_user() Implementation

void suspend_power_down_user(void) {
    // code will run multiple times while keyboard is suspended
}

void suspend_wakeup_init_user(void) {
    // code will run on keyboard wakeup
}

Keyboard suspend/wake Function Documentation

• Keyboard/Revision: void suspend_power_down_kb(void) and void suspend_wakeup_init_user(void)
• Keymap: void suspend_power_down_kb(void) and void suspend_wakeup_init_user(void)

Layer Change Code :id=layer-change-code

This runs code every time that the layers get changed. This can be useful for layer indication, or custom layer handling.

Example layer_state_set_* Implementation

This example shows how to set the RGB Underglow lights based on the layer, using the Planck as an example.

layer_state_t layer_state_set_user(layer_state_t state) {
    switch (get_highest_layer(state)) {
    case _RAISE:
        rgblight_setrgb (0x00,  0x00, 0xFF);
        break;
    case _LOWER:
        rgblight_setrgb (0xFF,  0x00, 0x00);
        break;
    case _PLOVER:
        rgblight_setrgb (0x00,  0xFF, 0x00);
        break;
    case _ADJUST:
        rgblight_setrgb (0x7A,  0x00, 0xFF);
        break;
    default: //  for any other layers, or the default layer
        rgblight_setrgb (0x00,  0xFF, 0xFF);
        break;
    }
  return state;
}

Use the IS_LAYER_ON_STATE(state, layer) and IS_LAYER_OFF_STATE(state, layer) macros to check the status of a particular layer.

Outside of layer_state_set_* functions, you can use the IS_LAYER_ON(layer) and IS_LAYER_OFF(layer) macros to check global layer state.

layer_state_set_* Function Documentation

• Keyboard/Revision: layer_state_t layer_state_set_kb(layer_state_t state)
• Keymap: layer_state_t layer_state_set_user(layer_state_t state)

The state is the bitmask of the active layers, as explained in the Keymap Overview

Persistent Configuration (EEPROM)

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.

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.

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.

• If you don't understand the example, then you may want to avoid using this feature, as it is rather complicated.

Example Implementation

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!

In your keymap.c file, add this to the top:

typedef union {
  uint32_t raw;
  struct {
    bool     rgb_layer_change :1;
  };
} user_config_t;

user_config_t user_config;

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.

We're using rgb_layer_change, for the layer_state_set_* function, and use keyboard_post_init_user and process_record_user to configure everything.

Now, using the keyboard_post_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:

void keyboard_post_init_user(void) {
  // Call the keymap level matrix init.

  // Read the user config from EEPROM
  user_config.raw = eeconfig_read_user();

  // Set default layer, if enabled
  if (user_config.rgb_layer_change) {
    rgblight_enable_noeeprom();
    rgblight_sethsv_noeeprom_cyan();
    rgblight_mode_noeeprom(1);
  }
}

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.

layer_state_t layer_state_set_user(layer_state_t state) {
    switch (get_highest_layer(state)) {
    case _RAISE:
        if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_magenta(); rgblight_mode_noeeprom(1); }
        break;
    case _LOWER:
        if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_red(); rgblight_mode_noeeprom(1); }
        break;
    case _PLOVER:
        if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_green(); rgblight_mode_noeeprom(1); }
        break;
    case _ADJUST:
        if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_white(); rgblight_mode_noeeprom(1); }
        break;
    default: //  for any other layers, or the default layer
        if (user_config.rgb_layer_change) { rgblight_sethsv_noeeprom_cyan(); rgblight_mode_noeeprom(1); }
        break;
    }
  return state;
}

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. 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:

bool process_record_user(uint16_t keycode, keyrecord_t *record) {
  switch (keycode) {
    case FOO:
      if (record->event.pressed) {
        // Do something when pressed
      } else {
        // Do something else when release
      }
      return false; // Skip all further processing of this key
    case KC_ENTER:
        // Play a tone when enter is pressed
        if (record->event.pressed) {
            PLAY_SONG(tone_qwerty);
        }
        return true; // Let QMK send the enter press/release events
    case RGB_LYR:  // This allows me to use underglow as layer indication, or as normal
        if (record->event.pressed) {
            user_config.rgb_layer_change ^= 1; // Toggles the status
            eeconfig_update_user(user_config.raw); // Writes the new status to EEPROM
            if (user_config.rgb_layer_change) { // if layer state indication is enabled,
                layer_state_set(layer_state);   // then immediately update the layer color
            }
        }
        return false;
    case RGB_MODE_FORWARD ... RGB_MODE_GRADIENT: // For any of the RGB codes (see quantum_keycodes.h, L400 for reference)
        if (record->event.pressed) { //This disables layer indication, as it's assumed that if you're changing this ... you want that disabled
            if (user_config.rgb_layer_change) {        // only if this is enabled
                user_config.rgb_layer_change = false;  // disable it, and
                eeconfig_update_user(user_config.raw); // write the setings to EEPROM
            }
        }
        return true; break;
    default:
      return true; // Process all other keycodes normally
  }
}

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. To force an EEPROM reset, use the EEP_RST keycode or Bootmagic Lite functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.

void eeconfig_init_user(void) {  // EEPROM is getting reset!
  user_config.raw = 0;
  user_config.rgb_layer_change = true; // We want this enabled by default
  eeconfig_update_user(user_config.raw); // Write default value to EEPROM now

  // use the non noeeprom versions, to write these values to EEPROM too
  rgblight_enable(); // Enable RGB by default
  rgblight_sethsv_cyan();  // Set it to CYAN by default
  rgblight_mode(1); // set to solid by default
}

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.

'EECONFIG' Function Documentation

• Keyboard/Revision: void eeconfig_init_kb(void), uint32_t eeconfig_read_kb(void) and void eeconfig_update_kb(uint32_t val)
• Keymap: void eeconfig_init_user(void), uint32_t eeconfig_read_user(void) and void eeconfig_update_user(uint32_t val)

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.

Deferred Execution :id=deferred-execution

QMK has the ability to execute a callback after a specified period of time, rather than having to manually manage timers. To enable this functionality, set DEFERRED_EXEC_ENABLE = yes in rules.mk.

Deferred executor callbacks

All deferred executor callbacks have a common function signature and look like:

uint32_t my_callback(uint32_t trigger_time, void *cb_arg) {
    /* do something */
    bool repeat = my_deferred_functionality();
    return repeat ? 500 : 0;
}

The first argument trigger_time is the intended time of execution. If other delays prevent executing at the exact trigger time, this allows for "catch-up" or even skipping intervals, depending on the required behaviour.

The second argument cb_arg is the same argument passed into defer_exec() below, and can be used to access state information from the original call context.

The return value is the number of milliseconds to use if the function should be repeated -- if the callback returns 0 then it's automatically unregistered. In the example above, a hypothetical my_deferred_functionality() is invoked to determine if the callback needs to be repeated -- if it does, it reschedules for a 500 millisecond delay, otherwise it informs the deferred execution background task that it's done, by returning 0.

?> Note that the returned delay will be applied to the intended trigger time, not the time of callback invocation. This allows for generally consistent timing even in the face of occasional late execution.

Deferred executor registration

Once a callback has been defined, it can be scheduled using the following API:

deferred_token my_token = defer_exec(1500, my_callback, NULL);

The first argument is the number of milliseconds to wait until executing my_callback -- in the case above, 1500 milliseconds, or 1.5 seconds.

The third parameter is the cb_arg that gets passed to the callback at the point of execution. This value needs to be valid at the time the callback is invoked -- a local function value will be destroyed before the callback is executed and should not be used. If this is not required, NULL should be used.

The return value is a deferred_token that can consequently be used to cancel the deferred executor callback before it's invoked. If a failure occurs, the returned value will be INVALID_DEFERRED_TOKEN. Usually this will be as a result of supplying 0 to the delay, or a NULL for the callback. The other failure case is if there are too many deferred executions "in flight" -- this can be increased by changing the limit, described below.

Extending a deferred execution

The deferred_token returned by defer_exec() can be used to extend a the duration a pending execution waits before it gets invoked:

// This will re-delay my_token's future execution such that it is invoked 800ms after the current time
extend_deferred_exec(my_token, 800);

Cancelling a deferred execution

The deferred_token returned by defer_exec() can be used to cancel a pending execution before it gets invoked:

// This will cancel my_token's future execution
cancel_deferred_exec(my_token);

Once a token has been canceled, it should be considered invalid. Reusing the same token is not supported.

Deferred callback limits

There are a maximum number of deferred callbacks that can be scheduled, controlled by the value of the define MAX_DEFERRED_EXECUTORS.

If registrations fail, then you can increase this value in your keyboard or keymap config.h file, for example to 16 instead of the default 8:

#define MAX_DEFERRED_EXECUTORS 16