Merge remote-tracking branch 'upstream/master'

.github/workflows/auto_tag.yml

@@ -27,7 +27,7 @@ jobs:
  fetch-depth: 0
 
  - name: Bump version and push tag
- uses: anothrNick/github-tag-action@1.39.0
+ uses: anothrNick/github-tag-action@1.50.0
  env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  DEFAULT_BUMP: 'patch'

.github/workflows/stale.yml

@@ -12,7 +12,7 @@ jobs:
  stale:
  runs-on: ubuntu-latest
  steps:
- - uses: actions/stale@v5
+ - uses: actions/stale@v6
  with:
  repo-token: ${{ secrets.GITHUB_TOKEN }}
 

builddefs/common_features.mk

@@ -271,7 +271,7 @@ ifneq ($(strip $(WEAR_LEVELING_DRIVER)),none)
  POST_CONFIG_H += $(DRIVER_PATH)/wear_leveling/wear_leveling_flash_spi_config.h
  else ifeq ($(strip $(WEAR_LEVELING_DRIVER)), rp2040_flash)
  SRC += wear_leveling_rp2040_flash.c
- POST_CONFIG_H += $(DRIVER_PATH)/wear_leveling/wear_leveling_rp2040_flash_config.h
+ POST_CONFIG_H += $(PLATFORM_PATH)/$(PLATFORM_KEY)/$(DRIVER_PATH)/wear_leveling/wear_leveling_rp2040_flash_config.h
  else ifeq ($(strip $(WEAR_LEVELING_DRIVER)), legacy)
  COMMON_VPATH += $(PLATFORM_PATH)/$(PLATFORM_KEY)/$(DRIVER_DIR)/flash
  SRC += flash_stm32.c wear_leveling_legacy.c

docs/_summary.md

@@ -79,6 +79,7 @@
  * [Caps Word](feature_caps_word.md)
  * [Combos](feature_combo.md)
  * [Debounce API](feature_debounce_type.md)
+ * [EEPROM](feature_eeprom.md)
  * [Key Lock](feature_key_lock.md)
  * [Key Overrides](feature_key_overrides.md)
  * [Layers](feature_layers.md)

docs/api_docs.md

@@ -16,7 +16,7 @@ This service is an asynchronous API for compiling custom keymaps. You POST some
  "layers": [
  ["KC_GRV","KC_1","KC_2","KC_3","KC_4","KC_5","KC_6","KC_7","KC_8","KC_9","KC_0","KC_MINS","KC_EQL","KC_GRV","KC_BSPC","KC_PGUP","KC_TAB","KC_Q","KC_W","KC_E","KC_R","KC_T","KC_Y","KC_U","KC_I","KC_O","KC_P","KC_LBRC","KC_RBRC","KC_BSLS","KC_PGDN","KC_CAPS","KC_A","KC_S","KC_D","KC_F","KC_G","KC_H","KC_J","KC_K","KC_L","KC_SCLN","KC_QUOT","KC_NUHS","KC_ENT","KC_LSFT","KC_NUBS","KC_Z","KC_X","KC_C","KC_V","KC_B","KC_N","KC_M","KC_COMM","KC_DOT","KC_SLSH","KC_RO","KC_RSFT","KC_UP","KC_LCTL","KC_LGUI","KC_LALT","KC_MHEN","KC_SPC","KC_SPC","KC_HENK","KC_RALT","KC_RCTL","MO(1)","KC_LEFT","KC_DOWN","KC_RIGHT"],
  ["KC_ESC","KC_F1","KC_F2","KC_F3","KC_F4","KC_F5","KC_F6","KC_F7","KC_F8","KC_F9","KC_F10","KC_F11","KC_F12","KC_TRNS","KC_DEL","BL_STEP","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","_______","KC_TRNS","KC_PSCR","KC_SLCK","KC_PAUS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(2)","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_PGUP","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(1)","KC_LEFT","KC_PGDN","KC_RGHT"],
- ["KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","RESET","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(2)","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(1)","KC_TRNS","KC_TRNS","KC_TRNS"]
+ ["KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","QK_BOOT","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(2)","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(1)","KC_TRNS","KC_TRNS","KC_TRNS"]
  ]
 }
 ```

docs/config_options.md

@@ -2,7 +2,17 @@
 
 QMK is nearly infinitely configurable. Wherever possible we err on the side of allowing users to customize their keyboard, even at the expense of code size. That level of flexibility makes for a daunting configuration experience, however.
 
-There are two main types of configuration files in QMK- `config.h` and `rules.mk`. These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:
+There are three main types of configuration files in QMK:
+
+* `config.h`, which contains various preprocessor directives (`#define`, `#ifdef`)
+* `rules.mk`, which contains additional variables
+* `info.json`, which is utilized for [data-driven configuration](https://docs.qmk.fm/#/data_driven_config)
+
+This page will only discuss the first two types, `config.h` and `rules.mk`.
+
+?> While not all settings have data-driven equivalents yet, keyboard makers are encouraged to utilize the `info.json` file to set the metadata for their boards when possible. See the [`info.json` Format](https://docs.qmk.fm/#/reference_info_json) page for more details.
+
+These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:
 
 * QMK Default
 * Keyboard

docs/configurator_default_keymaps.md

@@ -56,7 +56,7 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
  [1] = LAYOUT_all(
  KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, RGB_TOG, RGB_MOD, RGB_HUD, RGB_HUI, RGB_SAD, RGB_SAI, RGB_VAD, RGB_VAI, BL_TOGG, BL_DEC, BL_INC,
  KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_VOLU,
- KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, RESET,  KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_MPLY, KC_MNXT, KC_VOLD,
+ KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, QK_BOOT, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_MPLY, KC_MNXT, KC_VOLD,
  KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,
  KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,
  KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS),
@@ -84,7 +84,7 @@ The default keymap uses the `LAYOUT_all` macro, so that will be the value of the
  [
  "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "RGB_TOG", "RGB_MOD", "RGB_HUD", "RGB_HUI", "RGB_SAD", "RGB_SAI", "RGB_VAD", "RGB_VAI", "BL_TOGG", "BL_DEC", "BL_INC",
  "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_VOLU",
- "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "RESET",  "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_MPLY", "KC_MNXT", "KC_VOLD",
+ "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "QK_BOOT", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_MPLY", "KC_MNXT", "KC_VOLD",
  "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",
  "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",
  "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS"

docs/custom_quantum_functions.md

@@ -102,11 +102,11 @@ These are the three main initialization functions, listed in the order that they
 
 ## Keyboard Pre Initialization code
 
-This runs very early during startup, even before the USB has been started. 
+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. 
+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).
 
@@ -134,9 +134,9 @@ 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 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. 
+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
@@ -227,185 +227,6 @@ void suspend_wakeup_init_user(void) {
 * 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](feature_rgblight.md) lights based on the layer, using the Planck as an example.
-
-```c
-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](keymap.md#keymap-layer-status)
-
-
-# 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:
-```c
-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: 
-```c
-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. 
-
-```c
-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:
-```c
-
-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](feature_bootmagic.md) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
-
-```c
-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.
@@ -471,3 +292,15 @@ If registrations fail, then you can increase this value in your keyboard or keym
 ```c
 #define MAX_DEFERRED_EXECUTORS 16
 ```
+
+# Advanced topics :id=advanced-topics
+
+This page used to encompass a large set of features. We have moved many sections that used to be part of this page to their own pages. Everything below this point is simply a redirect so that people following old links on the web find what they're looking for.
+
+## Layer Change Code :id=layer-change-code
+
+[Layer change code](feature_layers.md#layer-change-code)
+
+## Persistent Configuration (EEPROM) :id=persistent-configuration-eeprom
+
+[Persistent Configuration (EEPROM)](feature_eeprom.md)