Merge c474099e2f into 0351b598f9

Co-authored-by: Moritz <moritz.plattner@gmx.net>

.github/workflows/api.yml

@@ -25,7 +25,7 @@ jobs:
     if: github.repository == 'qmk/qmk_firmware'
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         fetch-depth: 1
         persist-credentials: false

.github/workflows/auto_tag.yml

@@ -28,7 +28,7 @@ jobs:
     if: github.repository == 'qmk/qmk_firmware'
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         fetch-depth: 0
 

.github/workflows/ci_build_major_branch.yml

@@ -45,7 +45,7 @@ jobs:
           git config --global --add safe.directory '*'
 
       - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
 
       - name: Determine concurrency
         id: generate_slice_length
@@ -83,12 +83,12 @@ jobs:
           git config --global --add safe.directory '*'
 
       - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
         with:
           fetch-depth: 0
 
       - name: Download firmwares
-        uses: actions/download-artifact@v4
+        uses: actions/download-artifact@v5
         with:
           pattern: firmware-*
           path: .

.github/workflows/ci_build_major_branch_keymap.yml

@@ -37,7 +37,7 @@ jobs:
           git config --global --add safe.directory '*'
 
       - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
 
       - name: Generate build targets
         id: generate_targets
@@ -89,10 +89,10 @@ jobs:
           git config --global --add safe.directory '*'
 
       - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
 
       - name: Get target definitions
-        uses: actions/download-artifact@v4
+        uses: actions/download-artifact@v5
         with:
           name: targets-${{ inputs.keymap }}
           path: .
@@ -136,10 +136,10 @@ jobs:
 
     steps:
       - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
 
       - name: Download firmwares
-        uses: actions/download-artifact@v4
+        uses: actions/download-artifact@v5
         with:
           pattern: firmware-${{ inputs.keymap }}-*
           path: .

.github/workflows/cli.yml

@@ -24,7 +24,7 @@ jobs:
     - name: Disable safe.directory check
       run : git config --global --add safe.directory '*'
 
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         submodules: recursive
 

.github/workflows/develop_update.yml

@@ -15,7 +15,7 @@ jobs:
     if: github.repository == 'qmk/qmk_firmware'
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         token: ${{ secrets.QMK_BOT_TOKEN }}
         fetch-depth: 0

.github/workflows/docs.yml

@@ -30,7 +30,7 @@ jobs:
     container: ghcr.io/qmk/qmk_cli
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         fetch-depth: 1
 

.github/workflows/feature_branch_update.yml

@@ -21,7 +21,7 @@ jobs:
         - riot
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         token: ${{ secrets.QMK_BOT_TOKEN }}
         fetch-depth: 0

.github/workflows/format.yml

@@ -26,7 +26,7 @@ jobs:
     - name: Disable safe.directory check
       run : git config --global --add safe.directory '*'
 
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         fetch-depth: 0
 

.github/workflows/format_push.yml

@@ -19,7 +19,7 @@ jobs:
     - name: Disable safe.directory check
       run : git config --global --add safe.directory '*'
 
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         fetch-depth: 0
 

.github/workflows/labeler.yml

@@ -10,4 +10,4 @@ jobs:
       pull-requests: write
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/labeler@v5
+    - uses: actions/labeler@v6

.github/workflows/lint.yml

@@ -18,7 +18,7 @@ jobs:
     - name: Disable safe.directory check
       run : git config --global --add safe.directory '*'
 
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         fetch-depth: 0
 

.github/workflows/regen.yml

@@ -19,7 +19,7 @@ jobs:
     - name: Disable safe.directory check
       run : git config --global --add safe.directory '*'
 
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
 
     - name: Run qmk generators
       run: |

.github/workflows/regen_push.yml

@@ -19,7 +19,7 @@ jobs:
     - name: Disable safe.directory check
       run : git config --global --add safe.directory '*'
 
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
 
     - name: Run qmk generators
       run: |

.github/workflows/unit_test.yml

@@ -26,7 +26,7 @@ jobs:
     container: ghcr.io/qmk/qmk_cli
 
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
       with:
         submodules: recursive
     - name: Install dependencies

.gitignore

@@ -64,6 +64,7 @@ build/
 cmake-build-debug
 CMakeLists.txt
 *.pdf
+*.zip
 
 # Let these ones be user specific, since we have so many different configurations
 *.code-workspace

Makefile

@@ -115,7 +115,7 @@ endef
 TRY_TO_MATCH_RULE_FROM_LIST = $(eval $(call TRY_TO_MATCH_RULE_FROM_LIST_HELPER,$1))$(RULE_FOUND)
 
 # As TRY_TO_MATCH_RULE_FROM_LIST_HELPER, but with additional
-# resolution of DEFAULT_FOLDER and keyboard_aliases.hjson for provided rule 
+# resolution of keyboard_aliases.hjson for provided rule 
 define TRY_TO_MATCH_RULE_FROM_LIST_HELPER_KB
     # Split on ":", padding with empty strings to avoid indexing issues
     TOKEN1:=$$(shell python3 -c "import sys; print((sys.argv[1].split(':',1)+[''])[0])" $$(RULE))
@@ -255,7 +255,7 @@ endef
 # if we are going to compile all keyboards, match the rest of the rule
 # for each of them
 define PARSE_ALL_KEYBOARDS
-    $$(eval $$(call PARSE_ALL_IN_LIST,PARSE_KEYBOARD,$(shell $(QMK_BIN) list-keyboards --no-resolve-defaults)))
+    $$(eval $$(call PARSE_ALL_IN_LIST,PARSE_KEYBOARD,$(shell $(QMK_BIN) list-keyboards)))
 endef
 
 # Prints a list of all known keymaps for the given keyboard
@@ -447,7 +447,7 @@ git-submodules: git-submodule
 
 .PHONY: list-keyboards
 list-keyboards:
-	$(QMK_BIN) list-keyboards --no-resolve-defaults | tr '\n' ' '
+	$(QMK_BIN) list-keyboards | tr '\n' ' '
 
 .PHONY: list-tests
 list-tests:
@@ -455,7 +455,7 @@ list-tests:
 
 .PHONY: generate-keyboards-file
 generate-keyboards-file:
-	$(QMK_BIN) list-keyboards --no-resolve-defaults
+	$(QMK_BIN) list-keyboards
 
 .PHONY: clean
 clean:

builddefs/build_test.mk

@@ -62,6 +62,7 @@ include $(BUILDDEFS_PATH)/common_features.mk
 include $(BUILDDEFS_PATH)/generic_features.mk
 include $(PLATFORM_PATH)/common.mk
 include $(TMK_PATH)/protocol.mk
+include $(QUANTUM_PATH)/battery/tests/rules.mk
 include $(QUANTUM_PATH)/debounce/tests/rules.mk
 include $(QUANTUM_PATH)/encoder/tests/rules.mk
 include $(QUANTUM_PATH)/os_detection/tests/rules.mk

builddefs/common_features.mk

@@ -29,6 +29,8 @@ QUANTUM_SRC += \
     $(QUANTUM_DIR)/logging/debug.c \
     $(QUANTUM_DIR)/logging/sendchar.c \
     $(QUANTUM_DIR)/process_keycode/process_default_layer.c \
+    $(QUANTUM_DIR)/process_keycode/process_oneshot.c \
+    $(QUANTUM_DIR)/process_keycode/process_quantum.c \
 
 include $(QUANTUM_DIR)/nvm/rules.mk
 
@@ -123,7 +125,7 @@ ifeq ($(strip $(MOUSEKEY_ENABLE)), yes)
     MOUSE_ENABLE := yes
 endif
 
-VALID_POINTING_DEVICE_DRIVER_TYPES := adns5050 adns9800 analog_joystick azoteq_iqs5xx cirque_pinnacle_i2c cirque_pinnacle_spi paw3204 pmw3320 pmw3360 pmw3389 pimoroni_trackball custom
+VALID_POINTING_DEVICE_DRIVER_TYPES := adns5050 adns9800 analog_joystick azoteq_iqs5xx cirque_pinnacle_i2c cirque_pinnacle_spi paw3204 pmw3320 pmw3360 pmw3389 pimoroni_trackball blackberry_trackball custom
 ifeq ($(strip $(POINTING_DEVICE_ENABLE)), yes)
     ifeq ($(filter $(POINTING_DEVICE_DRIVER),$(VALID_POINTING_DEVICE_DRIVER_TYPES)),)
         $(call CATASTROPHIC_ERROR,Invalid POINTING_DEVICE_DRIVER,POINTING_DEVICE_DRIVER="$(POINTING_DEVICE_DRIVER)" is not a valid pointing device type)
@@ -157,6 +159,8 @@ ifeq ($(strip $(POINTING_DEVICE_ENABLE)), yes)
             SRC += $(QUANTUM_DIR)/pointing_device/pointing_device_gestures.c
         else ifeq ($(strip $(POINTING_DEVICE_DRIVER)), pimoroni_trackball)
             I2C_DRIVER_REQUIRED = yes
+        else ifeq ($(strip $(POINTING_DEVICE_DRIVER)), blackberry_trackball)
+            SRC += drivers/sensors/blackberry_trackball.c
         else ifneq ($(filter $(strip $(POINTING_DEVICE_DRIVER)),pmw3360 pmw3389),)
             SPI_DRIVER_REQUIRED = yes
             SRC += drivers/sensors/pmw33xx_common.c
@@ -633,6 +637,9 @@ ifeq ($(strip $(VIA_ENABLE)), yes)
     RAW_ENABLE := yes
     BOOTMAGIC_ENABLE := yes
     TRI_LAYER_ENABLE := yes
+    ifeq ($(strip $(VIA_INSECURE)), yes)
+        OPT_DEFS += -DVIA_INSECURE
+    endif
 endif
 
 ifeq ($(strip $(RAW_ENABLE)), yes)
@@ -940,21 +947,25 @@ ifeq ($(strip $(DIP_SWITCH_ENABLE)), yes)
     endif
 endif
 
+ifeq ($(strip $(BATTERY_ENABLE)), yes)
+    BATTERY_DRIVER_REQUIRED := yes
+endif
+
 VALID_BATTERY_DRIVER_TYPES := adc custom vendor
 
-BATTERY_DRIVER ?= adc
+BATTERY_DRIVER ?= none
 ifeq ($(strip $(BATTERY_DRIVER_REQUIRED)), yes)
     ifeq ($(filter $(BATTERY_DRIVER),$(VALID_BATTERY_DRIVER_TYPES)),)
         $(call CATASTROPHIC_ERROR,Invalid BATTERY_DRIVER,BATTERY_DRIVER="$(BATTERY_DRIVER)" is not a valid battery driver)
     endif
 
-    OPT_DEFS += -DBATTERY_DRIVER
-    OPT_DEFS += -DBATTERY_$(strip $(shell echo $(BATTERY_DRIVER) | tr '[:lower:]' '[:upper:]'))
+    OPT_DEFS += -DBATTERY_DRIVER_$(strip $(shell echo $(BATTERY_DRIVER) | tr '[:lower:]' '[:upper:]'))
 
     COMMON_VPATH += $(DRIVER_PATH)/battery
 
-    SRC += battery.c
-    SRC += battery_$(strip $(BATTERY_DRIVER)).c
+    ifneq ($(strip $(BATTERY_DRIVER)), custom)
+        SRC += battery_$(strip $(BATTERY_DRIVER)).c
+    endif
 
     # add extra deps
     ifeq ($(strip $(BATTERY_DRIVER)), adc)

builddefs/converters.mk

@@ -1,8 +1,3 @@
-ifneq (,$(filter $(MCU),atmega32u4))
-    # TODO: opt in rather than assume everything uses a pro micro
-    PIN_COMPATIBLE ?= promicro
-endif
-
 # Remove whitespace from any rule.mk provided vars
 #   - env cannot be overwritten but cannot have whitespace anyway
 CONVERT_TO:=$(strip $(CONVERT_TO))

builddefs/generic_features.mk

@@ -21,6 +21,7 @@ SPACE_CADET_ENABLE ?= yes
 GENERIC_FEATURES = \
     AUTO_SHIFT \
     AUTOCORRECT \
+    BATTERY \
     BOOTMAGIC \
     CAPS_WORD \
     COMBO \

builddefs/testlist.mk

@@ -1,6 +1,7 @@
 TEST_LIST = $(sort $(patsubst %/test.mk,%, $(shell find $(ROOT_DIR)tests -type f -name test.mk)))
 FULL_TESTS := $(notdir $(TEST_LIST))
 
+include $(QUANTUM_PATH)/battery/tests/testlist.mk
 include $(QUANTUM_PATH)/debounce/tests/testlist.mk
 include $(QUANTUM_PATH)/encoder/tests/testlist.mk
 include $(QUANTUM_PATH)/os_detection/tests/testlist.mk

data/mappings/info_config.hjson

@@ -43,6 +43,14 @@
     "BOOTMAGIC_ROW": {"info_key": "bootmagic.matrix.0", "value_type": "int"},
     "BOOTMAGIC_ROW_RIGHT": {"info_key": "split.bootmagic.matrix.0", "value_type": "int"},
 
+    // Battery
+    "BATTERY_SAMPLE_INTERVAL": {"info_key": "battery.sample_interval", "value_type": "int"},
+    "BATTERY_ADC_PIN": {"info_key": "battery.adc.pin"},
+    "BATTERY_ADC_REF_VOLTAGE_MV": {"info_key": "battery.adc.reference_voltage", "value_type": "int"},
+    "BATTERY_ADC_VOLTAGE_DIVIDER_R1": {"info_key": "battery.adc.divider_r1", "value_type": "int"},
+    "BATTERY_ADC_VOLTAGE_DIVIDER_R2": {"info_key": "battery.adc.divider_r2", "value_type": "int"},
+    "BATTERY_ADC_RESOLUTION": {"info_key": "battery.adc.resolution", "value_type": "int"},
+
     // Caps Word
     "BOTH_SHIFTS_TURNS_ON_CAPS_WORD": {"info_key": "caps_word.both_shifts_turns_on", "value_type": "flag"},
     "CAPS_WORD_IDLE_TIMEOUT": {"info_key": "caps_word.idle_timeout", "value_type": "int"},
@@ -120,6 +128,7 @@
     "MATRIX_HAS_GHOST": {"info_key": "matrix_pins.ghost", "value_type": "flag"},
     "MATRIX_INPUT_PRESSED_STATE": {"info_key": "matrix_pins.input_pressed_state", "value_type": "int"},
     "MATRIX_IO_DELAY": {"info_key": "matrix_pins.io_delay", "value_type": "int"},
+    "MATRIX_MASKED": {"info_key": "matrix_pins.masked", "value_type": "flag"},
 
     // Mouse Keys
     "MOUSEKEY_DELAY": {"info_key": "mousekey.delay", "value_type": "int"},
@@ -183,7 +192,7 @@
 
     // Split Keyboard
     "SOFT_SERIAL_PIN": {"info_key": "split.serial.pin"},
-    "SOFT_SERIAL_SPEED": {"info_key": "split.soft_serial_speed"},
+    "SELECT_SOFT_SERIAL_SPEED": {"info_key": "split.serial.speed"},
     "SPLIT_HAND_MATRIX_GRID": {"info_key": "split.handedness.matrix_grid", "value_type": "array", "to_c": false},
     "SPLIT_HAND_PIN": {"info_key": "split.handedness.pin"},
     "SPLIT_USB_DETECT": {"info_key": "split.usb_detect.enabled", "value_type": "flag"},

data/mappings/info_rules.hjson

@@ -13,6 +13,7 @@
 
     "AUDIO_DRIVER": {"info_key": "audio.driver"},
     "BACKLIGHT_DRIVER": {"info_key": "backlight.driver"},
+    "BATTERY_DRIVER": {"info_key": "battery.driver"},
     "BLUETOOTH_DRIVER": {"info_key": "bluetooth.driver"},
     "BOARD": {"info_key": "board"},
     "BOOTLOADER": {"info_key": "bootloader", "warn_duplicate": false},
@@ -53,8 +54,8 @@
     "WS2812_DRIVER": {"info_key": "ws2812.driver"},
 
     // Items we want flagged in lint
-    "DEFAULT_FOLDER": {"info_key": "_deprecated.default_folder", "deprecated": true},
     "CTPC": {"info_key": "_invalid.ctpc", "invalid": true, "replace_with": "CONVERT_TO=proton_c"},
     "CONVERT_TO_PROTON_C": {"info_key": "_invalid.ctpc", "invalid": true, "replace_with": "CONVERT_TO=proton_c"},
+    "DEFAULT_FOLDER": {"info_key": "_invalid.default_folder", "invalid": true},
     "VIAL_ENABLE": {"info_key": "_invalid.vial", "invalid": true}
 }

data/mappings/keyboard_aliases.hjson

@@ -68,6 +68,81 @@
     "bakeneko80": {
         "target": "kkatano/bakeneko80"
     },
+    "bastardkb/charybdis/3x5/v2/elitec": {
+        "target": "bastardkb/charybdis/3x5/elitec"
+    },
+    "bastardkb/charybdis/3x5/v2/splinky_2": {
+        "target": "bastardkb/charybdis/3x5/elitec"
+    },
+    "bastardkb/charybdis/3x5/v2/splinky_3": {
+        "target": "bastardkb/charybdis/3x5/elitec"
+    },
+    "bastardkb/charybdis/3x5/v2/stemcell": {
+        "target": "bastardkb/charybdis/3x5/elitec"
+    },
+    "bastardkb/charybdis/3x6/v2/elitec": {
+        "target": "bastardkb/charybdis/3x6/elitec"
+    },
+    "bastardkb/charybdis/3x6/v2/splinky_2": {
+        "target": "bastardkb/charybdis/3x6/elitec"
+    },
+    "bastardkb/charybdis/3x6/v2/splinky_3": {
+        "target": "bastardkb/charybdis/3x6/elitec"
+    },
+    "bastardkb/charybdis/3x6/v2/stemcell": {
+        "target": "bastardkb/charybdis/3x6/elitec"
+    },
+    "bastardkb/charybdis/4x6/v2/elitec": {
+        "target": "bastardkb/charybdis/4x6/elitec"
+    },
+    "bastardkb/charybdis/4x6/v2/splinky_2": {
+        "target": "bastardkb/charybdis/4x6/elitec"
+    },
+    "bastardkb/charybdis/4x6/v2/splinky_3": {
+        "target": "bastardkb/charybdis/4x6/elitec"
+    },
+    "bastardkb/charybdis/4x6/v2/stemcell": {
+        "target": "bastardkb/charybdis/4x6/elitec"
+    },
+    "bastardkb/dilemma/3x5_2/splinky": {
+        "target": "bastardkb/dilemma/3x5_2/promicro"
+    },
+    "bastardkb/scylla/v2/elitec": {
+        "target": "bastardkb/scylla/promicro"
+    },
+    "bastardkb/scylla/v2/splinky_2": {
+        "target": "bastardkb/scylla/promicro"
+    },
+    "bastardkb/scylla/v2/splinky_3": {
+        "target": "bastardkb/scylla/promicro"
+    },
+    "bastardkb/scylla/v2/stemcell": {
+        "target": "bastardkb/scylla/promicro"
+    },
+    "bastardkb/skeletyl/v2/elitec": {
+        "target": "bastardkb/skeletyl/promicro"
+    },
+    "bastardkb/skeletyl/v2/splinky_2": {
+        "target": "bastardkb/skeletyl/promicro"
+    },
+    "bastardkb/skeletyl/v2/splinky_3": {
+        "target": "bastardkb/skeletyl/promicro"
+    },
+    "bastardkb/skeletyl/v2/stemcell": {
+        "target": "bastardkb/skeletyl/promicro"
+    },
+    "bastardkb/tbkmini/v2/elitec": {
+        "target": "bastardkb/tbkmini/promicro"
+    },
+    "bastardkb/tbkmini/v2/splinky_2": {
+        "target": "bastardkb/tbkmini/promicro"
+    },
+    "bastardkb/tbkmini/v2/splinky_3": {
+        "target": "bastardkb/tbkmini/promicro"
+    },
+    "bastardkb/tbkmini/v2/stemcell": {
+        "target": "bastardkb/tbkmini/promicro"
+    },
     "bear_face": {
         "target": "bear_face/v1"
     },
@@ -257,44 +332,11 @@
     "handwired/jscotto/scottostarter": {
         "target": "handwired/scottokeebs/scottostarter"
     },
-    "helix/pico/sc/back": {
-        "target": "helix/pico/sc"
+    "helix": {
+        "target": "helix/beta"
     },
-    "helix/pico/sc/under": {
-        "target": "helix/pico/sc"
-    },
-    "helix/rev2/back/oled": {
-        "target": "helix/rev2/back"
-    },
-    "helix/rev2/oled": {
-        "target": "helix/rev2"
-    },
-    "helix/rev2/oled/back": {
-        "target": "helix/rev2/back"
-    },
-    "helix/rev2/oled/under": {
-        "target": "helix/rev2/under"
-    },
-    "helix/rev2/sc/back": {
-        "target": "helix/rev2/sc"
-    },
-    "helix/rev2/sc/oled": {
-        "target": "helix/rev2/sc"
-    },
-    "helix/rev2/sc/oledback": {
-        "target": "helix/rev2/sc"
-    },
-    "helix/rev2/sc/oledunder": {
-        "target": "helix/rev2/sc"
-    },
-    "helix/rev2/sc/under": {
-        "target": "helix/rev2/sc"
-    },
-    "helix/rev2/under": {
-        "target": "helix/rev2/sc"
-    },
-    "helix/rev2/under/oled": {
-        "target": "helix/rev2/under"
+    "helix/rev2": {
+        "target": "helix/beta"
     },
     "honeycomb": {
         "target": "keyhive/honeycomb"
@@ -407,6 +449,9 @@
     "lfkeyboards/smk65": {
         "target": "lfkeyboards/smk65/revb"
     },
+    "ll3macorn/bongopad": {
+        "target": "ll3ma/bongopad"
+    },
     "m3v3van": {
         "target": "matthewdias/m3n3van"
     },
@@ -1881,6 +1926,12 @@
     "kin80": {
         "target": "kin80/blackpill401"
     },
+    "kprepublic/cstc40/daughterboard": {
+        "target": "kprepublic/cstc40/rev1"
+    },
+    "kprepublic/cstc40/single_pcb": {
+        "target": "kprepublic/cstc40/rev2"
+    },
     "kumaokobo/kudox_full": {
         "target": "kumaokobo/kudox_full/rev1"
     },
@@ -2214,8 +2265,17 @@
     "trnthsn/s6xty5neor2": {
         "target": "trnthsn/s6xty5neor2/stm32f103"
     },
-    "tweetydabird/lotus58": {
-        "target": "tweetydabird/lotus58/promicro"
+    "tweetydabird/lotus58/elite_c": {
+        "target": "tweetydabird/lotus58"
+    },
+    "tweetydabird/lotus58/nanoboot": {
+        "target": "tweetydabird/lotus58"
+    },
+    "tweetydabird/lotus58/promicro": {
+        "target": "tweetydabird/lotus58"
+    },
+    "tweetydabird/lotus58/rp2040_ce": {
+        "target": "tweetydabird/lotus58"
     },
     "unison": {
         "target": "unison/v04"
@@ -2258,5 +2318,54 @@
     },
     "zsa/planck_ez": {
         "target": "zsa/planck_ez/base"
+    },
+    // DEFAULT_FOLDER removed during 2025 Q3 cycle
+    "cannonkeys/satisfaction75": {
+        "target": "cannonkeys/satisfaction75/rev1"
+    },
+    "converter/adb_usb": {
+        "target": "converter/adb_usb/rev1"
+    },
+    "converter/sun_usb": {
+        "target": "converter/sun_usb/type5"
+    },
+    "converter/usb_usb": {
+        "target": "converter/usb_usb/hasu"
+    },
+    "durgod/dgk6x": {
+        "target": "durgod/dgk6x/hades_ansi"
+    },
+    "ergodox_ez": {
+        "target": "ergodox_ez/base"
+    },
+    "ferris/0_2": {
+        "target": "ferris/0_2/base"
+    },
+    "handwired/dygma/raise": {
+        "target": "handwired/dygma/raise/ansi"
+    },
+    "helix/rev3_4rows": {
+        "target": "helix/rev3"
+    },
+    "helix/rev3_5rows": {
+        "target": "helix/rev3"
+    },
+    "ibm/model_m/mschwingen": {
+        "target": "ibm/model_m/mschwingen/led_wired"
+    },
+    "mechwild/sugarglider": {
+        "target": "mechwild/sugarglider/wide_oled/f401"
+    },
+    "mechwild/sugarglider/wide_oled": {
+        "target": "mechwild/sugarglider/wide_oled/f401"
+    },
+    "novelkeys/nk65": {
+        "target": "novelkeys/nk65/v1"
+    },
+    "novelkeys/nk65/base": {
+        "target": "novelkeys/nk65/v1"
+    },
+    "sirius/uni660/rev2": {
+        "target": "sirius/uni660/rev2/ansi"
     }
 }

data/schemas/keyboard.jsonschema

@@ -188,6 +188,28 @@
                 "as_caps_lock": {"type": "boolean"}
             }
         },
+        "battery": {
+            "type": "object",
+            "additionalProperties": false,
+            "properties": {
+                "driver": {
+                    "type": "string",
+                    "enum": ["adc", "custom", "vendor"]
+                },
+                "adc": {
+                    "type": "object",
+                    "additionalProperties": false,
+                    "properties": {
+                        "pin": {"$ref": "./definitions.jsonschema#/mcu_pin"},
+                        "reference_voltage": {"type": "integer"},
+                        "divider_r1": {"type": "integer"},
+                        "divider_r2": {"type": "integer"},
+                        "resolution": {"type": "integer"}
+                    }
+                },
+                "sample_interval": {"type": "integer"}
+            }
+        },
         "bluetooth": {
             "type": "object",
             "additionalProperties": false,
@@ -473,6 +495,7 @@
                 "ghost": {"type": "boolean"},
                 "input_pressed_state": {"$ref": "./definitions.jsonschema#/unsigned_int"},
                 "io_delay": {"$ref": "./definitions.jsonschema#/unsigned_int"},
+                "masked": {"type": "boolean"},
                 "direct": {
                     "type": "array",
                     "items": {"$ref": "./definitions.jsonschema#/mcu_pin_array"}
@@ -863,8 +886,7 @@
                 },
                 "soft_serial_speed": {
                     "type": "integer",
-                    "minimum": 0,
-                    "maximum": 5
+                    "$comment": "Deprecated: use split.serial.speed instead"
                 },
                 "serial": {
                     "type": "object",
@@ -874,7 +896,12 @@
                             "type": "string",
                             "enum": ["bitbang", "usart", "vendor"]
                         },
-                        "pin": {"$ref": "./definitions.jsonschema#/mcu_pin"}
+                        "pin": {"$ref": "./definitions.jsonschema#/mcu_pin"},
+                        "speed": {
+                            "type": "integer",
+                            "minimum": 0,
+                            "maximum": 5
+                        }
                     }
                 },
                 "transport": {

docs/ChangeLog/20200229.md

@@ -36,7 +36,7 @@ Four times a year QMK runs a process for merging Breaking Changes. A Breaking Ch
 ## Encoder flip
 
 * Flips the encoder direction so that `clockwise == true` is for actually turning the knob clockwise
-* Adds `ENCODER_DIRECTION_FLIP` define, so that reversing the expected dirction is simple for users.
+* Adds `ENCODER_DIRECTION_FLIP` define, so that reversing the expected direction is simple for users.
 * Cleans up documentation page for encoders
 
 

docs/ChangeLog/20200530.md

@@ -19,7 +19,7 @@ These PRs move the V-USB driver code out of the qmk_firmware repository and into
 
 Updates all of the per key tap-hold functions to pass the `keyrecord_t` structure, and include documentation changes.
 
-Any remaining versions or code outside of the main repo will need to be converted: 
+Any remaining versions or code outside of the main repo will need to be converted:
 | Old function                                         | New Function                                                              |
 |------------------------------------------------------|---------------------------------------------------------------------------|
 |`uint16_t get_tapping_term(uint16_t keycode)`         |`uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record)`         |
@@ -38,7 +38,7 @@ After the next breaking change you will not be able to build if `bin/qmk hello`
 [#8269](https://github.com/qmk/qmk_firmware/pull/8269)
 
 - Provides debug functionality on ChibiOS/ARM that is more compliant than previous integrations.
-- Less maintenence, fewer QMK customisations, and allows QMK to sidestep previous compile and runtime issues.
+- Less maintenance, fewer QMK customisations, and allows QMK to sidestep previous compile and runtime issues.
 - A `make git-submodule` may be required after pulling the latest QMK Firmware code to update to the new dependency.
 
 ### Fixed RGB_DISABLE_AFTER_TIMEOUT to be seconds based & small internals cleanup
@@ -51,8 +51,10 @@ After the next breaking change you will not be able to build if `bin/qmk hello`
 
 The `RGB_DISABLE_AFTER_TIMEOUT` definition is now deprecated, and has been superseded by `RGB_DISABLE_TIMEOUT`. To use the new definition, rename `RGB_DISABLE_AFTER_TIMEOUT` to `RGB_DISABLE_TIMEOUT` in your `config.h` file, and multiply the value set by 1200.
 
-Before: `#define RGB_DISABLE_AFTER_TIMEOUT 100`  
-After: `#define RGB_DISABLE_TIMEOUT 120000`
+```diff
+-#define RGB_DISABLE_AFTER_TIMEOUT 100
++#define RGB_DISABLE_TIMEOUT 120000
+```
 
 ### Switch to qmk forks for everything
 
@@ -103,8 +105,8 @@ This allows current lily58 firmware to advance with updates to the `split_common
 - Alternatively, if you did not change the OLED code from that in `default`, you may find it easier to simply copy the [relevant section](https://github.com/qmk/qmk_firmware/blob/4ac310668501ae6786c711ecc8f01f62ddaa1c0b/keyboards/lily58/keymaps/default/keymap.c#L138-L172). Otherwise, the changes you need to make are as follows (sample change [here](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7R138-R173))
 - [Remove](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7L138-L141) the block
 ```c
-#ifdef SSD1306OLED	
-  iota_gfx_init(!has_usb());   // turns on the display	
+#ifdef SSD1306OLED
+  iota_gfx_init(!has_usb());   // turns on the display
 #endif
 ```
 - Within the block bounded by `#ifdef OLED_DRIVER_ENABLE` and `#endif // OLED_DRIVER_ENABLE`, add the following block to ensure that your two OLEDs are rotated correctly across the left and right sides:
@@ -127,7 +129,7 @@ oled_rotation_t oled_init_user(oled_rotation_t rotation) {
 
 * Refactor to use split_common and remove split codes under the zinc/revx/
 * Add - backlight RGB LED and/or underglow RGB LED option
-* Add - continuous RGB animations feature (between L and R halves) 
+* Add - continuous RGB animations feature (between L and R halves)
 * Fix - keymap files to adapt to changes
     * all authors of keymaps confirmed this PR
 * Update - documents and rules.mk
@@ -164,8 +166,8 @@ void keyboard_pre_init_kb(void) {
 - The following changes are for compatibility with the OLED driver. If you don't use the OLED driver you may safely delete [this section](https://github.com/qmk/qmk_firmware/blob/e6b9980bd45c186f7360df68c24b6e05a80c10dc/keyboards/lily58/keymaps/default/keymap.c#L144-L190)
 - [Remove](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7L91-L158) the block
 ```c
-#ifdef SSD1306OLED	
-  iota_gfx_init(!has_usb());   // turns on the display	
+#ifdef SSD1306OLED
+  iota_gfx_init(!has_usb());   // turns on the display
 #endif
 ```
 - Within the block bounded by `#ifdef OLED_DRIVER_ENABLE` and `#endif // OLED_DRIVER_ENABLE`, add the following block to ensure that your two OLEDs are rotated correctly across the left and right sides:

docs/ChangeLog/20210529.md

@@ -12,7 +12,7 @@ Added support for MK66F18 (Teensy 3.6) microcontroller.
 
 ### New command: qmk console ([#12828](https://github.com/qmk/qmk_firmware/pull/12828)) {#new-command-qmk-console}
 
-A new `qmk console` command has been added for attaching to your keyboard's console. It operates similiarly to QMK Toolbox by allowing you to connect to one or more keyboard consoles to display debugging messages.
+A new `qmk console` command has been added for attaching to your keyboard's console. It operates similarly to QMK Toolbox by allowing you to connect to one or more keyboard consoles to display debugging messages.
 
 ### Improved command: qmk config {#improve-command-qmk-config}
 
@@ -121,8 +121,8 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
             tap_code(KC_UP);
         }
     }
-    return true; 
-    // If you return true, this will allow the keyboard level code to run, as well. 
+    return true;
+    // If you return true, this will allow the keyboard level code to run, as well.
     //Returning false will override the keyboard level code. Depending on how the keyboard level function is set up.
 }
 ```

docs/ChangeLog/20210828.md

@@ -104,7 +104,7 @@ void dip_switch_update_user(uint8_t index, bool active) {
     }
 }
 
-void dip_switch_update_mask_kb(uint32_t state) { 
+void dip_switch_update_mask_kb(uint32_t state) {
     dip_switch_update_mask_user(state);
 }
 

docs/ChangeLog/20220226.md

@@ -29,7 +29,7 @@ Bootloader configuration is no longer assumed. Keyboards must now set either:
 
 ### Rename `AdafruitBLE` to `BluefruitLE` ([#16127](https://github.com/qmk/qmk_firmware/pull/16127))
 
-In preparation of future bluetooth work, the `AdafruitBLE` integration has been renamed to allow potential for any other Adafruit BLE products. 
+In preparation of future bluetooth work, the `AdafruitBLE` integration has been renamed to allow potential for any other Adafruit BLE products.
 
 ### Updated Keyboard Codebases {#updated-keyboard-codebases}
 

docs/ChangeLog/20250831.md

@@ -0,0 +1,181 @@
+# QMK Breaking Changes - 2025 Aug 31 Changelog
+
+## Changes Requiring User Action
+
+### Updated Keyboard Codebases
+
+| Old Keyboard Name                    | New Keyboard Name                |
+|--------------------------------------|----------------------------------|
+| bastardkb/charybdis/3x5/v2/elitec    | bastardkb/charybdis/3x5/elitec   |
+| bastardkb/charybdis/3x5/v2/splinky_2 | bastardkb/charybdis/3x5/elitec   |
+| bastardkb/charybdis/3x5/v2/splinky_3 | bastardkb/charybdis/3x5/elitec   |
+| bastardkb/charybdis/3x5/v2/stemcell  | bastardkb/charybdis/3x5/elitec   |
+| bastardkb/charybdis/3x6/v2/elitec    | bastardkb/charybdis/3x6/elitec   |
+| bastardkb/charybdis/3x6/v2/splinky_2 | bastardkb/charybdis/3x6/elitec   |
+| bastardkb/charybdis/3x6/v2/splinky_3 | bastardkb/charybdis/3x6/elitec   |
+| bastardkb/charybdis/3x6/v2/stemcell  | bastardkb/charybdis/3x6/elitec   |
+| bastardkb/charybdis/4x6/v2/elitec    | bastardkb/charybdis/4x6/elitec   |
+| bastardkb/charybdis/4x6/v2/splinky_2 | bastardkb/charybdis/4x6/elitec   |
+| bastardkb/charybdis/4x6/v2/splinky_3 | bastardkb/charybdis/4x6/elitec   |
+| bastardkb/charybdis/4x6/v2/stemcell  | bastardkb/charybdis/4x6/elitec   |
+| bastardkb/dilemma/3x5_2/splinky      | bastardkb/dilemma/3x5_2/promicro |
+| bastardkb/scylla/v2/elitec           | bastardkb/scylla/promicro        |
+| bastardkb/scylla/v2/splinky_2        | bastardkb/scylla/promicro        |
+| bastardkb/scylla/v2/splinky_3        | bastardkb/scylla/promicro        |
+| bastardkb/scylla/v2/stemcell         | bastardkb/scylla/promicro        |
+| bastardkb/skeletyl/v2/elitec         | bastardkb/skeletyl/promicro      |
+| bastardkb/skeletyl/v2/splinky_2      | bastardkb/skeletyl/promicro      |
+| bastardkb/skeletyl/v2/splinky_3      | bastardkb/skeletyl/promicro      |
+| bastardkb/skeletyl/v2/stemcell       | bastardkb/skeletyl/promicro      |
+| bastardkb/tbkmini/v2/elitec          | bastardkb/tbkmini/promicro       |
+| bastardkb/tbkmini/v2/splinky_2       | bastardkb/tbkmini/promicro       |
+| bastardkb/tbkmini/v2/splinky_3       | bastardkb/tbkmini/promicro       |
+| bastardkb/tbkmini/v2/stemcell        | bastardkb/tbkmini/promicro       |
+| helix/rev2                           | helix/beta                       |
+| helix/rev3_4rows                     | helix/rev3                       |
+| helix/rev3_5rows                     | helix/rev3                       |
+| kprepublic/cstc40/daughterboard      | kprepublic/cstc40/rev1           |
+| kprepublic/cstc40/single_pcb         | kprepublic/cstc40/rev2           |
+| ll3macorn/bongopad                   | ll3ma/bongopad                   |
+| novelkeys/nk65/base                  | novelkeys/nk65/v1                |
+| tweetydabird/lotus58/elite_c         | tweetydabird/lotus58             |
+| tweetydabird/lotus58/nanoboot        | tweetydabird/lotus58             |
+| tweetydabird/lotus58/promicro        | tweetydabird/lotus58             |
+| tweetydabird/lotus58/rp2040_ce       | tweetydabird/lotus58             |
+
+### Mitigate VIA keylogger security issues [#25414](https://github.com/qmk/qmk_firmware/pull/25414)
+
+VIA's keyboard matrix testing functionality, which allows users to identify active key presses, has been identified as a potential security concern by community members and security researchers. This feature has been demonstrated to enable unauthorized keystroke capture, with documented examples showing how malicious scripts could exploit this capability to create keyloggers. A recent security assessment revealed that user credentials could be compromised by exploiting the matrix testing function combined with VIA's keycode assignment queries. In this attack scenario, a script could remain active during a locked session and capture password input when users authenticate upon return.
+
+The QMK team notified the VIA team of this security vulnerability on May 17, 2022, and made multiple subsequent attempts to coordinate a mitigation strategy. Despite repeated outreach, the VIA team has provided no acknowledgment or response to these security concerns. Given the severity of the potential security implications and the lack of engagement from the VIA team, the QMK team has unilaterally implemented a security enhancement that modifies the keyboard matrix testing functionality to prevent the reporting of key press events. This change prioritizes user security and data protection over potential feature compatibility concerns within VIA.
+
+## Deprecation Notices
+
+In line with the [notice period](../support_deprecation_policy#how-much-advance-notice-will-be-given), deprecation notices for larger items are listed here.
+
+### `DEFAULT_FOLDER` removal ([#23281](https://github.com/qmk/qmk_firmware/pull/23281))
+
+`DEFAULT_FOLDER` was originally introduced to work around limitations within the build system.
+Parent folders containing common configuration would create invalid build targets.
+
+With the introduction of [`keyboard.json`](./20240526#keyboard-json) as a configuration file, the build system now has a consistent method to detect build targets.
+The `DEFAULT_FOLDER` functionality is now removed with the intent that `rules.mk` is now pure configuration.
+
+Backwards compatibility of build targets has been maintained where possible.
+
+### Converter `Pin Compatible` updates ([#20330](https://github.com/qmk/qmk_firmware/pull/20330))
+
+Converter support has been further limited to only function if a keyboard declares that it is compatible.
+
+This can be configured in the following ways:
+
+:::::tabs
+
+==== keyboard.json
+
+```json [keyboard.json]
+{
+    "development_board": "promicro", // [!code focus]
+}
+```
+
+==== rules.mk
+
+```make [rules.mk]
+PIN_COMPATIBLE = promicro
+```
+
+:::::
+
+see the [Converters Feature](../feature_converters) documentation for more information.
+
+### Removal of deprecated RGB and Mouse keycodes ([#25444](https://github.com/qmk/qmk_firmware/pull/25444))
+
+Backwards compatibility of deprecated RGB and Mouse keycodes has been removed.
+
+See the following documentation for the list of currently supported keycodes:
+
+* [RGB Lighting](../features/rgblight#keycodes)
+* [RGB Matrix](../features/rgb_matrix#keycodes)
+* [Mouse keys](../features/mouse_keys#mapping-mouse-actions)
+
+## Full changelist
+
+Core:
+* Remove converter assumption that everything is a promicro ([#20330](https://github.com/qmk/qmk_firmware/pull/20330))
+* Remove `DEFAULT_FOLDER` handling ([#23281](https://github.com/qmk/qmk_firmware/pull/23281))
+* Add core handling for pointing device failures. ([#25315](https://github.com/qmk/qmk_firmware/pull/25315))
+* Relocate remaining `process_record_quantum` keycodes ([#25328](https://github.com/qmk/qmk_firmware/pull/25328))
+* Remove `process_action_kb` callback ([#25331](https://github.com/qmk/qmk_firmware/pull/25331))
+* Add `{rgb|led}_matrix_get_mode_name()`. ([#25344](https://github.com/qmk/qmk_firmware/pull/25344))
+* Align sleep_led logic ([#25395](https://github.com/qmk/qmk_firmware/pull/25395))
+* Mitigate VIA keylogger security issues ([#25414](https://github.com/qmk/qmk_firmware/pull/25414))
+* Deprecate some nonstandard mod & mod-tap keycode aliases ([#25437](https://github.com/qmk/qmk_firmware/pull/25437))
+* Refactor Starlight Smooth matrix effect ([#25442](https://github.com/qmk/qmk_firmware/pull/25442))
+* Remove deprecated `RGB_` and Mouse keycodes ([#25444](https://github.com/qmk/qmk_firmware/pull/25444))
+* Configure SPI for `QMK_PM2040` board ([#25481](https://github.com/qmk/qmk_firmware/pull/25481))
+* Configure SPI for `STEMCELL` board ([#25486](https://github.com/qmk/qmk_firmware/pull/25486))
+* Configure SPI for `QMK_BLOK` board ([#25487](https://github.com/qmk/qmk_firmware/pull/25487))
+* Clamp reactive offset value ([#25489](https://github.com/qmk/qmk_firmware/pull/25489))
+* Relocate `AUDIO_INIT_DELAY` implementation ([#25491](https://github.com/qmk/qmk_firmware/pull/25491))
+* Add MATRIX_ROWS_PER_HAND definition ([#25513](https://github.com/qmk/qmk_firmware/pull/25513))
+* Refactor battery driver ([#25550](https://github.com/qmk/qmk_firmware/pull/25550))
+* Add cachyos as pattern when installing dependencies ([#25580](https://github.com/qmk/qmk_firmware/pull/25580))
+
+CLI:
+* Add MATRIX_MASKED DD config ([#25383](https://github.com/qmk/qmk_firmware/pull/25383))
+* Ensure keyboard aliases do not point to themselves ([#25500](https://github.com/qmk/qmk_firmware/pull/25500))
+
+Keyboards:
+* [Update] E8ghtyNeo caps indicator ([#25009](https://github.com/qmk/qmk_firmware/pull/25009))
+* Keychron C3 Pro `c3_pro.c` corrections ([#25049](https://github.com/qmk/qmk_firmware/pull/25049))
+* Update franky36 pid and vid ([#25160](https://github.com/qmk/qmk_firmware/pull/25160))
+* Added Encoder support for Soyuz ([#25279](https://github.com/qmk/qmk_firmware/pull/25279))
+* CSTC40 rev3 (FXTWINK) ([#25285](https://github.com/qmk/qmk_firmware/pull/25285))
+* Migrate remaining `DEFAULT_FOLDER` to keyboard aliases ([#25291](https://github.com/qmk/qmk_firmware/pull/25291))
+* Configure boards to use development_board - R ([#25316](https://github.com/qmk/qmk_firmware/pull/25316))
+* Configure boards to use development_board - P ([#25317](https://github.com/qmk/qmk_firmware/pull/25317))
+* Configure boards to use development_board - NO ([#25338](https://github.com/qmk/qmk_firmware/pull/25338))
+* Configure boards to use development_board - LM ([#25341](https://github.com/qmk/qmk_firmware/pull/25341))
+* maple_computing/launchpad - Remove broken `default_rgb` keymap ([#25342](https://github.com/qmk/qmk_firmware/pull/25342))
+* update winry25 VID and PID ([#25351](https://github.com/qmk/qmk_firmware/pull/25351))
+* Configure boards to use development_board - DE ([#25369](https://github.com/qmk/qmk_firmware/pull/25369))
+* Configure boards to use development_board - FGHIJ ([#25370](https://github.com/qmk/qmk_firmware/pull/25370))
+* refactor(mercutio): layouts & reformatting ([#25408](https://github.com/qmk/qmk_firmware/pull/25408))
+* Configure boards to use development_board - ABC ([#25417](https://github.com/qmk/qmk_firmware/pull/25417))
+* Configure boards to use development_board - K ([#25421](https://github.com/qmk/qmk_firmware/pull/25421))
+* Refactor `helix/pico` ([#25428](https://github.com/qmk/qmk_firmware/pull/25428))
+* Refactor `helix/rev2` ([#25429](https://github.com/qmk/qmk_firmware/pull/25429))
+* Refactor `helix/rev3_{4,5}rows` ([#25430](https://github.com/qmk/qmk_firmware/pull/25430))
+* Migrate `helix` common configuration ([#25433](https://github.com/qmk/qmk_firmware/pull/25433))
+* Refactor `bastardkb/tbkmini` ([#25438](https://github.com/qmk/qmk_firmware/pull/25438))
+* Convert `novelkeys/nk65` to use RGB Matrix ([#25450](https://github.com/qmk/qmk_firmware/pull/25450))
+* Convert moon to lite custom matrix ([#25452](https://github.com/qmk/qmk_firmware/pull/25452))
+* Refactor `bastardkb/skeletyl` ([#25456](https://github.com/qmk/qmk_firmware/pull/25456))
+* Refactor `bastardkb/scylla` ([#25459](https://github.com/qmk/qmk_firmware/pull/25459))
+* Refactor `bastardkb/dilemma/3x5_2` ([#25462](https://github.com/qmk/qmk_firmware/pull/25462))
+* Migrate `usb.force_nkro` to `host.default.nkro` ([#25468](https://github.com/qmk/qmk_firmware/pull/25468))
+* Give mouse report to pointing_device_task_user first in ploopyco devices ([#25475](https://github.com/qmk/qmk_firmware/pull/25475))
+* Refactor `bastardkb/charybdis/3x5` ([#25488](https://github.com/qmk/qmk_firmware/pull/25488))
+* Refactor `bastardkb/charybdis/3x6` ([#25493](https://github.com/qmk/qmk_firmware/pull/25493))
+* Refactor `bastardkb/charybdis/4x6` ([#25494](https://github.com/qmk/qmk_firmware/pull/25494))
+* Rebrand For Ll3ma Keyboards ([#25498](https://github.com/qmk/qmk_firmware/pull/25498))
+* Remove some encoder resolution that duplicate defaults ([#25517](https://github.com/qmk/qmk_firmware/pull/25517))
+* Remove overriding of `DF()` within keyboards ([#25541](https://github.com/qmk/qmk_firmware/pull/25541))
+* Refactor inland/kb83 ([#25542](https://github.com/qmk/qmk_firmware/pull/25542))
+* Refactor `tweetydabird/lotus58` ([#25547](https://github.com/qmk/qmk_firmware/pull/25547))
+* Swap spleeb to default GENERIC_PROMICRO_RP2040 board files ([#25564](https://github.com/qmk/qmk_firmware/pull/25564))
+
+Keyboard fixes:
+* Fix `keebio/quefrency/rev1:default60` ([#25423](https://github.com/qmk/qmk_firmware/pull/25423))
+* Fixup `bastardkb/tbkmini` keymap's build target ([#25458](https://github.com/qmk/qmk_firmware/pull/25458))
+* Miscellaneous fixes for lint warnings ([#25469](https://github.com/qmk/qmk_firmware/pull/25469))
+* Fix pytest/has_community default keymap location ([#25471](https://github.com/qmk/qmk_firmware/pull/25471))
+* Fix serial speed DD configuration & migrate keyboards ([#25546](https://github.com/qmk/qmk_firmware/pull/25546))
+* Update rgb x coordinate of rightmost column ([#25556](https://github.com/qmk/qmk_firmware/pull/25556))
+
+Bugs:
+* Fix buggy switch statement in quantum.c ([#25322](https://github.com/qmk/qmk_firmware/pull/25322))
+* Compilation fixes for `-fno-common` ([#25436](https://github.com/qmk/qmk_firmware/pull/25436))
+* Only userspace should be searched for keyboard aliases when locating keymaps ([#25477](https://github.com/qmk/qmk_firmware/pull/25477))
+* Allow `qmk flash <filename>` to flash AT32 boards ([#25497](https://github.com/qmk/qmk_firmware/pull/25497))

docs/ChangeLog/20251130/PR25515.md

@@ -0,0 +1,3 @@
+# Refactor debounce algorithm with static allocation [#25515](https://github.com/qmk/qmk_firmware/pull/25515)
+
+Removed dynamic memory allocation (malloc, free) from all debounce implementations for improved efficiency on embedded systems and to avoid runtime allocation overhead. Refactored state arrays to use direct indexing, simplifying code and eliminating pointer arithmetic. Standardized usage of MATRIX_ROWS_PER_HAND throughout the codebase to ensure consistent support for split keyboards.

docs/_sidebar.json

@@ -21,8 +21,14 @@
             { "text": "Debugging QMK", "link": "/faq_debug" },
             { "text": "Keymap FAQ", "link": "/faq_keymap" },
             { "text": "Squeezing Space from AVR", "link": "/squeezing_avr" },
-            { "text": "Glossary", "link": "/reference_glossary" },
-            { "text": "License Violations", "link": "/license_violations" }
+            { "text": "Glossary", "link": "/reference_glossary" }
+        ]
+    },
+    {
+        "text": "Licensing",
+        "items": [
+            { "text": "License Violations", "link": "/license_violations" },
+            { "text": "Proprietary Libraries", "link": "/proprietary_libs" }
         ]
     },
     {
@@ -169,6 +175,7 @@
                         ]
                     },
                     { "text": "Audio", "link": "/features/audio" },
+                    { "text": "Battery", "link": "/features/battery" },
                     { "text": "Bootmagic", "link": "/features/bootmagic" },
                     { "text": "Converters", "link": "/feature_converters" },
                     { "text": "Custom Matrix", "link": "/custom_matrix" },
@@ -207,7 +214,7 @@
                     { "text": "My Pull Request Was Flagged", "link": "/breaking_changes_instructions" },
                     {
                         "text": "Most Recent ChangeLog",
-                        "link": "/ChangeLog/20250525"
+                        "link": "/ChangeLog/20250831"
                     },
                     { "text": "Past Breaking Changes", "link": "/breaking_changes_history" },
                     { "text": "Deprecation Policy", "link": "/support_deprecation_policy" }

docs/breaking_changes.md

@@ -10,25 +10,25 @@ Practically, this means QMK merges the `develop` branch into the `master` branch
 
 ## What has been included in past Breaking Changes?
 
+* [2025 Aug 31](ChangeLog/20250831)
 * [2025 May 25](ChangeLog/20250525)
 * [2025 Feb 23](ChangeLog/20250223)
-* [2024 Nov 24](ChangeLog/20241124)
 * [Older Breaking Changes](breaking_changes_history)
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for Aug 31, 2025.
+The next Breaking Change is scheduled for November 30, 2025.
 
 ### Important Dates
 
-* 2025 May 25 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
-* 2025 Aug 3 - `develop` closed to new PRs.
-* 2025 Aug 3 - Call for testers.
-* 2025 Aug 17 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
-* 2025 Aug 24 - `develop` is locked, only critical bugfix PRs merged.
-* 2025 Aug 29 - `master` is locked, no PRs merged.
-* 2025 Aug 31 - Merge `develop` to `master`.
-* 2025 Aug 31 - `master` is unlocked. PRs can be merged again.
+* 2025 Aug 31 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
+* 2025 Nov 2 - `develop` closed to new PRs.
+* 2025 Nov 2 - Call for testers.
+* 2025 Nov 16 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
+* 2025 Nov 23 - `develop` is locked, only critical bugfix PRs merged.
+* 2025 Nov 28 - `master` is locked, no PRs merged.
+* 2025 Nov 30 - Merge `develop` to `master`.
+* 2025 Nov 30 - `master` is unlocked. PRs can be merged again.
 
 ## What changes will be included?
 

docs/breaking_changes_history.md

@@ -2,6 +2,7 @@
 
 This page links to all previous changelogs from the QMK Breaking Changes process.
 
+* [2025 Aug 31](ChangeLog/20250831) - version 0.30.0
 * [2025 May 25](ChangeLog/20250525) - version 0.29.0
 * [2025 Feb 23](ChangeLog/20250223) - version 0.28.0
 * [2024 Nov 24](ChangeLog/20241124) - version 0.27.0

docs/cli_commands.md

@@ -17,12 +17,12 @@ qmk compile [-c] <configuratorExport.json>
 **Usage for Keymaps**:
 
 ```
-qmk compile [-c] [-e <var>=<value>] [-j <num_jobs>] [--compiledb] -kb <keyboard_name> -km <keymap_name>
+qmk compile [-c] [-e <var>=<value>] [-j <num_jobs>] [--compiledb] -kb <keyboard> -km <keymap>
 ```
 
 **Usage in Keyboard Directory**:
 
-Must be in keyboard directory with a default keymap, or in keymap directory for keyboard, or supply one with `--keymap <keymap_name>`
+Must be in keyboard directory with a default keymap, or in keymap directory for keyboard, or supply one with `--keymap <keymap>`
 ```
 qmk compile
 ```
@@ -30,7 +30,7 @@ qmk compile
 **Usage for building all keyboards that support a specific keymap**:
 
 ```
-qmk compile -kb all -km <keymap_name>
+qmk compile -kb all -km <keymap>
 ```
 
 **Example**:
@@ -62,7 +62,7 @@ $ qmk compile
 
 Must be under `qmk_firmware/layouts/`, and in a keymap folder.
 ```
-qmk compile -kb <keyboard_name>
+qmk compile -kb <keyboard>
 ```
 
 **Example**:
@@ -77,11 +77,11 @@ $ qmk compile -kb dz60
 
 It is possible to speed up compilation by adding the `-j`/`--parallel` flag.
 ```
-qmk compile -j <num_jobs> -kb <keyboard_name>
+qmk compile -j <num_jobs> -kb <keyboard>
 ```
 The `num_jobs` argument determines the maximum number of jobs that can be used. Setting it to zero will enable parallel compilation without limiting the maximum number of jobs.
 ```
-qmk compile -j 0 -kb <keyboard_name>
+qmk compile -j 0 -kb <keyboard>
 ```
 
 **Compilation Database**:
@@ -120,7 +120,7 @@ qmk flash [-bl <bootloader>] [-c] [-e <var>=<value>] [-j <num_jobs>] <configurat
 **Usage for Keymaps**:
 
 ```
-qmk flash -kb <keyboard_name> -km <keymap_name> [-bl <bootloader>] [-c] [-e <var>=<value>] [-j <num_jobs>]
+qmk flash -kb <keyboard> -km <keymap_name> [-bl <bootloader>] [-c] [-e <var>=<value>] [-j <num_jobs>]
 ```
 
 **Usage for pre-compiled firmwares**:
@@ -631,14 +631,15 @@ This command compiles all the External Userspace build targets.
 **Usage**:
 
 ```
-qmk userspace-compile [-h] [-e ENV] [-n] [-c] [-j PARALLEL] [-t]
+qmk userspace-compile [-h] [-e ENV] [-p] [-n] [-c] [-j PARALLEL] [-t]
 
 options:
   -h, --help            show this help message and exit
-  -e ENV, --env ENV     Set a variable to be passed to make. May be passed multiple times.
+  -e, --env ENV         Set a variable to be passed to make. May be passed multiple times.
+  -p, --print-failures  Print failed builds.
   -n, --dry-run         Don't actually build, just show the commands to be run.
   -c, --clean           Remove object files before compiling.
-  -j PARALLEL, --parallel PARALLEL
+  -j, --parallel PARALLEL
                         Set the number of parallel make jobs; 0 means unlimited.
   -t, --no-temp         Remove temporary files during build.
 ```

docs/config_options.md

@@ -364,8 +364,6 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
 
 ## Build Options
 
-* `DEFAULT_FOLDER`
-  * Used to specify a default folder when a keyboard has more than one sub-folder.
 * `FIRMWARE_FORMAT`
   * Defines which format (bin, hex) is copied to the root `qmk_firmware` folder after building.
 * `SRC`

docs/custom_quantum_functions.md

@@ -145,7 +145,7 @@ void keyboard_pre_init_user(void) {
 
 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 dependent on where it's started.
 
 
 ### `matrix_init_*` Function Documentation
@@ -209,7 +209,7 @@ You should use this function if you need custom matrix scanning code. It can als
 
 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.
+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 throttling their behaviour if you do indeed require implementing something special.
 
 ### Example `void housekeeping_task_user(void)` implementation
 
@@ -246,7 +246,7 @@ void check_rgb_timeout(void) {
     }
 }
 /* Then, call the above functions from QMK's built in post processing functions like so */
-/* Runs at the end of each scan loop, check if RGB timeout has occured or not */
+/* Runs at the end of each scan loop, check if RGB timeout has occurred or not */
 void housekeeping_task_user(void) {
 #ifdef RGBLIGHT_TIMEOUT
     check_rgb_timeout();
@@ -316,7 +316,7 @@ bool shutdown_kb(bool jump_to_bootloader) {
     if (!shutdown_user(jump_to_bootloader)) {
         return false;
     }
-    
+
     if (jump_to_bootloader) {
         // red for bootloader
         rgb_matrix_set_color_all(RGB_OFF);

docs/data_driven_config.md

@@ -6,7 +6,7 @@ This page describes how QMK's data driven JSON configuration system works. It is
 
 Historically QMK has been configured through a combination of two mechanisms- `rules.mk` and `config.h`. While this worked well when QMK was only a handful of keyboards we've grown to encompass nearly 4000 supported keyboards. That extrapolates out to 6000 configuration files under `keyboards/` alone! The freeform nature of these files and the unique patterns people have used to avoid duplication have made ongoing maintenance a challenge, and a large number of our keyboards follow patterns that are outdated and sometimes harder to understand.
 
-We have also been working on bringing the power of QMK to people who aren't comformable with a CLI, and other projects such as VIA are working to make using QMK as easy as installing a program. These tools need information about how a keyboard is laid out or what pins and features are available so that users can take full advantage of QMK. We introduced `info.json` as a first step towards this. The QMK API is an effort to combine these 3 sources of information- `config.h`, `rules.mk`, and `info.json`- into a single source of truth that end-user tools can use.
+We have also been working on bringing the power of QMK to people who aren't comfortable with a CLI, and other projects such as VIA are working to make using QMK as easy as installing a program. These tools need information about how a keyboard is laid out or what pins and features are available so that users can take full advantage of QMK. We introduced `info.json` as a first step towards this. The QMK API is an effort to combine these 3 sources of information- `config.h`, `rules.mk`, and `info.json`- into a single source of truth that end-user tools can use.
 
 Now we have support for generating `rules.mk` and `config.h` values from `info.json`, allowing us to have a single source of truth. This will allow us to use automated tooling to maintain keyboards saving a lot of time and maintenance work.
 

docs/drivers/aw20216s.md

@@ -44,7 +44,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const aw20216s_led_t PROGMEM g_aw20216s_leds[AW20216S_LED_COUNT] = {

docs/drivers/battery.md

@@ -1,6 +1,6 @@
 # Battery Driver
 
-This driver provides support for sampling battery level.
+This driver provides support for directly sampling battery level.
 
 ## Usage
 
@@ -10,21 +10,17 @@ To use this driver, add the following to your `rules.mk`:
 BATTERY_DRIVER_REQUIRED = yes
 ```
 
-## Basic Configuration {#basic-configuration}
-
-Add the following to your `config.h`:
-
-|Define                    |Default |Description                                       |
-|--------------------------|--------|--------------------------------------------------|
-|`BATTERY_SAMPLE_INTERVAL` |`30000` |The time between battery samples in milliseconds. |
+::::info Note
+This is already configured for you if you are using the [Battery](../features/battery) feature.
+::::
 
 ## Driver Configuration {#driver-configuration}
 
-Driver selection can be configured in `rules.mk` as `BATTERY_DRIVER`. Valid values are `adc` (default), `vendor`, or `custom`. See below for information on individual drivers.
+Driver selection can be configured in `rules.mk` as `BATTERY_DRIVER`. Valid values are `adc`, `vendor`, or `custom`. See below for information on individual drivers.
 
 ### ADC Driver {#adc-driver}
 
-This is the default battery driver. The default configuration assumes the battery is connected to a ADC capable pin through a voltage divider.
+The default configuration assumes the battery is connected to a ADC capable pin through a voltage divider.
 
 ```make
 BATTERY_DRIVER = adc
@@ -32,42 +28,25 @@ BATTERY_DRIVER = adc
 
 The following `#define`s apply only to the `adc` driver:
 
-|Define                       |Default       |Description                                                   |
-|-----------------------------|--------------|--------------------------------------------------------------|
-|`BATTERY_PIN`                |*Not defined* |The GPIO pin connected to the voltage divider.                |
-|`BATTERY_REF_VOLTAGE_MV`     |`3300`        |The ADC reverence voltage, in millivolts.                     |
-|`BATTERY_VOLTAGE_DIVIDER_R1` |`100`         |The voltage divider resistance, in kOhm. Set to 0 to disable. |
-|`BATTERY_VOLTAGE_DIVIDER_R2` |`100`         |The voltage divider resistance, in kOhm. Set to 0 to disable. |
-|`BATTERY_ADC_RESOLUTION`     |`10`          |The ADC resolution configured for the ADC Driver.             |
+|Define                           |Default       |Description                                                   |
+|---------------------------------|--------------|--------------------------------------------------------------|
+|`BATTERY_ADC_PIN`                |*Not defined* |The GPIO pin connected to the voltage divider.                |
+|`BATTERY_ADC_REF_VOLTAGE_MV`     |`3300`        |The ADC reverence voltage, in millivolts.                     |
+|`BATTERY_ADC_VOLTAGE_DIVIDER_R1` |`100`         |The voltage divider resistance, in kOhm. Set to 0 to disable. |
+|`BATTERY_ADC_VOLTAGE_DIVIDER_R2` |`100`         |The voltage divider resistance, in kOhm. Set to 0 to disable. |
+|`BATTERY_ADC_RESOLUTION`         |`10`          |The ADC resolution configured for the ADC Driver.             |
 
-## Functions
+### Custom Driver {#custom-driver}
 
-### `uint8_t battery_get_percent(void)` {#api-battery-get-percent}
+A custom driver is expected to implement the following interface:
 
-Sample battery level.
+```c
+void battery_driver_init(void) {
+    // Perform any initialisation here
+}
 
-#### Return Value {#api-battery-get-percent-return}
-
-The battery percentage, in the range 0-100.
-
-## Callbacks
-
-### `void battery_percent_changed_user(uint8_t level)` {#api-battery-percent-changed-user}
-
-User hook called when battery level changed.
-
-### Arguments {#api-battery-percent-changed-user-arguments}
-
- - `uint8_t level`  
-   The battery percentage, in the range 0-100.
-
----
-
-### `void battery_percent_changed_kb(uint8_t level)` {#api-battery-percent-changed-kb}
-
-Keyboard hook called when battery level changed.
-
-### Arguments {#api-battery-percent-changed-kb-arguments}
-
- - `uint8_t level`  
-   The battery percentage, in the range 0-100.
+uint8_t battery_driver_sample_percent(void) {
+    // Read and return current state here
+    return value;
+}
+```

docs/drivers/is31fl3218.md

@@ -37,7 +37,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3218_led_t PROGMEM g_is31fl3218_leds[IS31FL3218_LED_COUNT] = {

docs/drivers/is31fl3236.md

@@ -50,7 +50,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3236_led_t PROGMEM g_is31fl3236_leds[IS31FL3236_LED_COUNT] = {

docs/drivers/is31fl3729.md

@@ -120,7 +120,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3729_led_t PROGMEM g_is31fl3729_leds[IS31FL3729_LED_COUNT] = {

docs/drivers/is31fl3731.md

@@ -61,7 +61,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3731_led_t PROGMEM g_is31fl3731_leds[IS31FL3731_LED_COUNT] = {

docs/drivers/is31fl3733.md

@@ -145,7 +145,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3733_led_t PROGMEM g_is31fl3733_leds[IS31FL3733_LED_COUNT] = {

docs/drivers/is31fl3736.md

@@ -129,7 +129,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3736_led_t PROGMEM g_is31fl3736_leds[IS31FL3736_LED_COUNT] = {

docs/drivers/is31fl3737.md

@@ -117,7 +117,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3737_led_t PROGMEM g_is31fl3737_leds[IS31FL3737_LED_COUNT] = {

docs/drivers/is31fl3741.md

@@ -117,7 +117,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3741_led_t PROGMEM g_is31fl3741_leds[IS31FL3741_LED_COUNT] = {

docs/drivers/is31fl3742a.md

@@ -117,7 +117,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3742a_led_t PROGMEM g_is31fl3742a_leds[IS31FL3742A_LED_COUNT] = {

docs/drivers/is31fl3743a.md

@@ -127,7 +127,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3743a_led_t PROGMEM g_is31fl3743a_leds[IS31FL3743A_LED_COUNT] = {

docs/drivers/is31fl3745.md

@@ -127,7 +127,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3745_led_t PROGMEM g_is31fl3745_leds[IS31FL3745_LED_COUNT] = {

docs/drivers/is31fl3746a.md

@@ -132,7 +132,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const is31fl3746a_led_t PROGMEM g_is31fl3746a_leds[IS31FL3746A_LED_COUNT] = {

docs/drivers/serial.md

@@ -33,7 +33,7 @@ On ARM platforms the bitbang driver causes connection issues when using it toget
 +-------+                 +-------+
 ```
 
-One GPIO pin is needed for the bitbang driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SOFT_SERIAL_PIN` (SSP) in the configuration. A TRS or USB cable provides enough conductors for this driver to function. 
+One GPIO pin is needed for the bitbang driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SOFT_SERIAL_PIN` (SSP) in the configuration. A TRS or USB cable provides enough conductors for this driver to function.
 
 ### Setup
 
@@ -63,12 +63,12 @@ SERIAL_DRIVER = bitbang
 
 ## USART Half-duplex
 
-Targeting ARM boards based on ChibiOS, where communication is offloaded to a USART hardware device that supports Half-duplex operation. The advantages over bitbanging are fast, accurate timings and reduced CPU usage. Therefore it is advised to choose Half-duplex over Bitbang if MCU is capable of utilising Half-duplex, and Full-duplex can't be used instead (e.g. lack of available GPIO pins, or imcompatible PCB design).
+Targeting ARM boards based on ChibiOS, where communication is offloaded to a USART hardware device that supports Half-duplex operation. The advantages over bitbanging are fast, accurate timings and reduced CPU usage. Therefore it is advised to choose Half-duplex over Bitbang if MCU is capable of utilising Half-duplex, and Full-duplex can't be used instead (e.g. lack of available GPIO pins, or incompatible PCB design).
 
 ### Pin configuration
 
 ```
-  LEFT                      RIGHT  
+  LEFT                      RIGHT
 +-------+  |           |  +-------+
 |       |  R           R  |       |
 |       |  |   SERIAL  |  |       |
@@ -80,7 +80,7 @@ Targeting ARM boards based on ChibiOS, where communication is offloaded to a USA
 +-------+                 +-------+
 ```
 
-Only one GPIO pin is needed for the Half-duplex driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SERIAL_USART_TX_PIN` in the configuration. Ensure that the pin chosen for split communication can operate as the TX pin of the contoller's USART peripheral. A TRS or USB cable provides enough conductors for this driver to function. As the split connection is configured to operate in open-drain mode, an **external pull-up resistor is needed to keep the line high**. Resistor values of 1.5kΩ to 8.2kΩ are known to work. 
+Only one GPIO pin is needed for the Half-duplex driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SERIAL_USART_TX_PIN` in the configuration. Ensure that the pin chosen for split communication can operate as the TX pin of the contoller's USART peripheral. A TRS or USB cable provides enough conductors for this driver to function. As the split connection is configured to operate in open-drain mode, an **external pull-up resistor is needed to keep the line high**. Resistor values of 1.5kΩ to 8.2kΩ are known to work.
 
 ::: warning
 ***Note:*** A pull-up resistor isn't required for RP2040 controllers configured with PIO subsystem.
@@ -278,7 +278,7 @@ There are several advanced configuration options that can be defined in your key
 
 ### Baudrate
 
-If you're having issues or need a higher baudrate with serial communication, you can change the baudrate which in turn controls the communication speed for serial. You want to lower the baudrate if you experience failed transactions. 
+If you're having issues or need a higher baudrate with serial communication, you can change the baudrate which in turn controls the communication speed for serial. You want to lower the baudrate if you experience failed transactions.
 
 ```c
 #define SELECT_SOFT_SERIAL_SPEED n
@@ -307,19 +307,19 @@ This is the default time window in milliseconds in which a successful communicat
 
 ## Troubleshooting
 
-If you're having issues withe serial communication, you can enable debug messages that will give you insights which part of the communication failed. The enable these messages add to your keyboards `config.h` file:
+If you're having issues with serial communication, you can enable debug messages that will give you insights which part of the communication failed. The enable these messages add to your keyboards `config.h` file:
 
 ```c
 #define SERIAL_DEBUG
 ```
- 
+
 ::: tip
 The messages will be printed out to the `CONSOLE` output. For additional information, refer to [Debugging/Troubleshooting QMK](../faq_debug).
 :::
 
 ## Alternate Functions for selected STM32 MCUs
 
-Pins for USART Peripherals with 
+Pins for USART Peripherals with
 
 ### STM32F303 / Proton-C [Datasheet](https://www.st.com/resource/en/datasheet/stm32f303cc.pdf)
 

docs/drivers/snled27351.md

@@ -52,7 +52,7 @@ Depending on the ChibiOS board configuration, you may need to [enable and config
 
 ## LED Mapping {#led-mapping}
 
-In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboardname>.c`:
+In order to use this driver, each output must be mapped to an LED index, by adding the following to your `<keyboard>.c`:
 
 ```c
 const snled27351_led_t PROGMEM g_snled27351_leds[SNLED27351_LED_COUNT] = {

docs/drivers/ws2812.md

@@ -144,18 +144,30 @@ The following defines apply only to ARM devices:
 |`WS2812_T1L`|`(WS2812_TIMING - WS2812_T1H)`|The length of a "1" bit's low phase in nanoseconds (bitbang and PIO drivers only)|
 |`WS2812_T0L`|`(WS2812_TIMING - WS2812_T0H)`|The length of a "0" bit's low phase in nanoseconds (bitbang and PIO drivers only)|
 
-### Push-Pull and Open Drain {#push-pull-open-drain}
+### Logic Levels {#logic-levels}
 
-By default, the GPIO used for data transmission is configured as a *push-pull* output, meaning the pin is effectively always driven either to VCC or to ground.
+WS2812 LEDs usually operate at 5V, but some microcontrollers, particularly ARM-based ones, run on 3.3V. This can pose an issue when driving the LED chain as the logic level voltage is lower than the power supply voltage, leading to unreliable data transmission. There are two main workarounds:
 
-For situations where the logic level voltage is lower than the power supply voltage, however, this can pose an issue. The solution is to configure the pin for *open drain* mode instead, and use a pullup resistor between the DI pin and VCC. In this mode, the MCU can only pull the GPIO *low*, or leave it floating. The pullup resistor is then responsible for pulling the line high, when the MCU is not driving the GPIO.
+#### 1. Open Drain Circuit {#open-drain-circuit}
 
-To configure the DI pin for open drain configuration, add the following to your `config.h`:
+By default, `WS2812_DI_PIN` is configured as a *push-pull* output, meaning the pin is effectively always driven either to VCC or to ground; however, it can be configured in *open drain* mode instead.
+
+In this mode, the MCU will only pull the GPIO *low*, and leaves it floating otherwise. A pullup resistor (typically around 10kΩ) between DI and 5V is then responsible for pulling the line high when the MCU is not driving the GPIO.
+
+To use the DI pin in open drain configuration, add the following to your `config.h`:
 
 ```c
 #define WS2812_EXTERNAL_PULLUP
 ```
 
+::: warning
+Because the GPIO is being pulled to 5V in this situation rather than VCC (3.3V), **it must be a 5V tolerant pin**. Consult your MCU's datasheet first – if there are no eligible pins, you must use a level shifter instead.
+:::
+
+#### 2. Level Shifter {#level-shifter}
+
+A level shifter IC, such as the SN74LV1T34, can be placed between the GPIO and the first LED's DI pin to convert the 3.3V logic to 5V. This requires no additional configuration in the firmware, nor a 5V tolerant GPIO, but may be more expensive and is generally less handwire-friendly.
+
 ### SPI Driver {#arm-spi-driver}
 
 Depending on the ChibiOS board configuration, you may need to enable SPI at the keyboard level. For STM32, this would look like:

docs/faq_general.md

@@ -38,7 +38,7 @@ Awesome! Open up a Pull Request for it. We'll review the code, and merge it!
 
 That's amazing! We would love to assist you with that!
 
-In fact, we have a [whole page](https://qmk.fm/powered/) dedicated to adding QMK Branding to your page and keyboard. This covers pretty much everything you need (knowledge and images) to officially support QMK.
+In fact, we have a [whole page](https://qmk.fm/trademark) dedicated to adding QMK Branding to your page and keyboard. This covers pretty much everything you need (knowledge and images) to officially support QMK.
 
 If you have any questions about this, open an issue or head to [Discord](https://discord.gg/qmk).
 

docs/feature_advanced_keycodes.md

@@ -2,36 +2,36 @@
 
 These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
 
-|Key       |Aliases                           |Description                                                                    |
-|----------|----------------------------------|-------------------------------------------------------------------------------|
-|`LCTL(kc)`|`C(kc)`                           |Hold Left Control and press `kc`                                               |
-|`LSFT(kc)`|`S(kc)`                           |Hold Left Shift and press `kc`                                                 |
-|`LALT(kc)`|`A(kc)`, `LOPT(kc)`               |Hold Left Alt and press `kc`                                                   |
-|`LGUI(kc)`|`G(kc)`, `LCMD(kc)`, `LWIN(kc)`   |Hold Left GUI and press `kc`                                                   |
-|`LCS(kc)` |                                  |Hold Left Control and Left Shift and press `kc`                                |
-|`LCA(kc)` |                                  |Hold Left Control and Left Alt and press `kc`                                  |
-|`LCG(kc)` |                                  |Hold Left Control and Left GUI and press `kc`                                  |
-|`LSA(kc)` |                                  |Hold Left Shift and Left Alt and press `kc`                                    |
-|`LSG(kc)` |`SGUI(kc)`, `SCMD(kc)`, `SWIN(kc)`|Hold Left Shift and Left GUI and press `kc`                                    |
-|`LAG(kc)` |                                  |Hold Left Alt and Left GUI and press `kc`                                      |
-|`LCSG(kc)`|                                  |Hold Left Control, Left Shift and Left GUI and press `kc`                      |
-|`LCAG(kc)`|                                  |Hold Left Control, Left Alt and Left GUI and press `kc`                        |
-|`LSAG(kc)`|                                  |Hold Left Shift, Left Alt and Left GUI and press `kc`                          |
-|`RCTL(kc)`|                                  |Hold Right Control and press `kc`                                              |
-|`RSFT(kc)`|                                  |Hold Right Shift and press `kc`                                                |
-|`RALT(kc)`|`ROPT(kc)`, `ALGR(kc)`            |Hold Right Alt and press `kc`                                                  |
-|`RGUI(kc)`|`RCMD(kc)`, `RWIN(kc)`            |Hold Right GUI and press `kc`                                                  |
-|`RCA(kc)` |                                  |Hold Right Control and Right Alt and press `kc`                                |
-|`RCS(kc)` |                                  |Hold Right Control and Right Shift and press `kc`                              |
-|`RCG(kc)` |                                  |Hold Right Control and Right GUI and press `kc`                                |
-|`RSA(kc)` |`SAGR(kc)`                        |Hold Right Shift and Right Alt and press `kc`                                  |
-|`RSG(kc)` |                                  |Hold Right Shift and Right GUI and press `kc`                                  |
-|`RAG(kc)` |                                  |Hold Right Alt and Right GUI and press `kc`                                    |
-|`RCSG(kc)`|                                  |Hold Right Control, Right Shift and Right GUI and press `kc`                   |
-|`RCAG(kc)`|                                  |Hold Right Control, Right Alt and Right GUI and press `kc`                     |
-|`RSAG(kc)`|                                  |Hold Right Shift, Right Alt and Right GUI and press `kc`                       |
-|`MEH(kc)` |                                  |Hold Left Control, Left Shift and Left Alt and press `kc`                      |
-|`HYPR(kc)`|                                  |Hold Left Control, Left Shift, Left Alt and Left GUI and press `kc`<sup>1</sup>|
+|Key       |Aliases                        |Description                                                                    |
+|----------|-------------------------------|-------------------------------------------------------------------------------|
+|`LCTL(kc)`|`C(kc)`                        |Hold Left Control and press `kc`                                               |
+|`LSFT(kc)`|`S(kc)`                        |Hold Left Shift and press `kc`                                                 |
+|`LALT(kc)`|`A(kc)`, `LOPT(kc)`            |Hold Left Alt and press `kc`                                                   |
+|`LGUI(kc)`|`G(kc)`, `LCMD(kc)`, `LWIN(kc)`|Hold Left GUI and press `kc`                                                   |
+|`LCS(kc)` |                               |Hold Left Control and Left Shift and press `kc`                                |
+|`LCA(kc)` |                               |Hold Left Control and Left Alt and press `kc`                                  |
+|`LCG(kc)` |                               |Hold Left Control and Left GUI and press `kc`                                  |
+|`LSA(kc)` |                               |Hold Left Shift and Left Alt and press `kc`                                    |
+|`LSG(kc)` |                               |Hold Left Shift and Left GUI and press `kc`                                    |
+|`LAG(kc)` |                               |Hold Left Alt and Left GUI and press `kc`                                      |
+|`LCSG(kc)`|                               |Hold Left Control, Left Shift and Left GUI and press `kc`                      |
+|`LCAG(kc)`|                               |Hold Left Control, Left Alt and Left GUI and press `kc`                        |
+|`LSAG(kc)`|                               |Hold Left Shift, Left Alt and Left GUI and press `kc`                          |
+|`RCTL(kc)`|                               |Hold Right Control and press `kc`                                              |
+|`RSFT(kc)`|                               |Hold Right Shift and press `kc`                                                |
+|`RALT(kc)`|`ROPT(kc)`, `ALGR(kc)`         |Hold Right Alt and press `kc`                                                  |
+|`RGUI(kc)`|`RCMD(kc)`, `RWIN(kc)`         |Hold Right GUI and press `kc`                                                  |
+|`RCA(kc)` |                               |Hold Right Control and Right Alt and press `kc`                                |
+|`RCS(kc)` |                               |Hold Right Control and Right Shift and press `kc`                              |
+|`RCG(kc)` |                               |Hold Right Control and Right GUI and press `kc`                                |
+|`RSA(kc)` |                               |Hold Right Shift and Right Alt and press `kc`                                  |
+|`RSG(kc)` |                               |Hold Right Shift and Right GUI and press `kc`                                  |
+|`RAG(kc)` |                               |Hold Right Alt and Right GUI and press `kc`                                    |
+|`RCSG(kc)`|                               |Hold Right Control, Right Shift and Right GUI and press `kc`                   |
+|`RCAG(kc)`|                               |Hold Right Control, Right Alt and Right GUI and press `kc`                     |
+|`RSAG(kc)`|                               |Hold Right Shift, Right Alt and Right GUI and press `kc`                       |
+|`MEH(kc)` |                               |Hold Left Control, Left Shift and Left Alt and press `kc`                      |
+|`HYPR(kc)`|                               |Hold Left Control, Left Shift, Left Alt and Left GUI and press `kc`<sup>1</sup>|
 
 <sup>1. More information on the Hyper key can be found on [this blog post by Brett Terpstra](https://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/).</sup>
 

docs/feature_debounce_type.md

@@ -47,7 +47,7 @@ susceptible to noise, you must choose a debounce method that will also mitigate
    * Debounce algorithms often have a 'debounce time' parameter, that specifies the maximum settling time of the switch contacts.
      This time might be measured in various units:
      * Cycles-based debouncing waits n cycles (scans), decreasing count by one each matrix_scan
-     * Timestamp-based debouncing stores the millisecond timestamp a change occurred, and does substraction to figure out time elapsed.
+     * Timestamp-based debouncing stores the millisecond timestamp a change occurred, and does subtraction to figure out time elapsed.
    * Timestamp-based debouncing is usually superior, especially in the case of noise-resistant devices because settling times of physical
      switches is specified in units of time, and should not depend on the matrix scan-rate of the keyboard.
    * Cycles-based debouncing is sometimes considered inferior, because the settling time that it is able to compensate for depends on the

docs/feature_eeprom.md

@@ -100,7 +100,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
         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
+                eeconfig_update_user(user_config.raw); // write the settings to EEPROM
             }
         }
         return true; break;
@@ -109,7 +109,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
   }
 }
 ```
-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 `EE_CLR` keycode or [Bootmagic](features/bootmagic) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
+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 `EE_CLR` keycode or [Bootmagic](features/bootmagic) functionality. 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!

docs/feature_layers.md

@@ -25,7 +25,7 @@ active layer until pressed again.
 
 Currently, the `layer` argument of `LT()` is limited to layers 0-15, and the `kc` argument to the [Basic Keycode set](keycodes_basic), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. This is because QMK uses 16-bit keycodes, of which 4 bits are used for the function identifier and 4 bits for the layer, leaving only 8 bits for the keycode.
 
-For a similar reason, the `layer` argument of `LM()` is also limited to layers 0-15 and the `mod` argument must fit within 5 bits. As a consequence, although left and right modifiers are supported by `LM()`, it is impossible to mix and match left and right modifiers. Specifying at least one right-hand modifier in a combination such as `MOD_RALT|MOD_LSFT` will convert *all* the listed modifiers to their right-hand counterpart. So, using the aforementionned mod-mask will actually send <kbd>Right Alt</kbd>+<kbd>Right Shift</kbd>. Make sure to use the `MOD_xxx` constants over alternative ways of specifying modifiers when defining your layer-mod key.
+For a similar reason, the `layer` argument of `LM()` is also limited to layers 0-15 and the `mod` argument must fit within 5 bits. As a consequence, although left and right modifiers are supported by `LM()`, it is impossible to mix and match left and right modifiers. Specifying at least one right-hand modifier in a combination such as `MOD_RALT|MOD_LSFT` will convert *all* the listed modifiers to their right-hand counterpart. So, using the aforementioned mod-mask will actually send <kbd>Right Alt</kbd>+<kbd>Right Shift</kbd>. Make sure to use the `MOD_xxx` constants over alternative ways of specifying modifiers when defining your layer-mod key.
 
 | `LM(1,KC_LSFT)` | `LM(1,MOD_MASK_SHIFT)` | `LM(1,MOD_BIT(KC_LSFT))` | `LM(1,MOD_LSFT)` |
 |:---------------:|:----------------------:|:------------------------:|:----------------:|
@@ -61,27 +61,27 @@ Sometimes, you might want to switch between layers in a macro or as part of a ta
 
 There are a number of functions (and variables) related to how you can use or manipulate the layers.
 
-|Function                                      |Description                                                                                              |
-|----------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| `layer_state_set(layer_mask)`                | Directly sets the layer state (avoid unless you know what you are doing).                               |
-| `layer_clear()`                              | Clears all layers (turns them all off).                                                                 |
-| `layer_move(layer)`                          | Turns specified layer on, and all other layers off.                                                     |
-| `layer_on(layer)`                            | Turns specified layer on, leaves all other layers in existing state.                                    |
-| `layer_off(layer)`                           | Turns specified layer off, leaves all other layers in existing state.                                   |
-| `layer_invert(layer)`                        | Inverts/toggles the state of the specified layer                                                        |
-| `layer_or(layer_mask)`                       | Turns on layers based on matching bits between specifed layer and existing layer state.                 |
-| `layer_and(layer_mask)`                      | Turns on layers based on matching enabled bits between specifed layer and existing layer state.         |
-| `layer_xor(layer_mask)`                      | Turns on layers based on non-matching bits between specifed layer and existing layer state.             |
-| `layer_debug(layer_mask)`                    | Prints out the current bit mask and highest active layer to debugger console.                           |
-| `default_layer_set(layer_mask)`              | Directly sets the default layer state (avoid unless you know what you are doing).                       |
-| `default_layer_or(layer_mask)`               | Turns on layers based on matching bits between specifed layer and existing default layer state.         |
-| `default_layer_and(layer_mask)`              | Turns on layers based on matching enabled bits between specifed layer and existing default layer state. |
-| `default_layer_xor(layer_mask)`              | Turns on layers based on non-matching bits between specifed layer and existing default layer state.     |
-| `default_layer_debug(layer_mask)`            | Prints out the current bit mask and highest active default layer to debugger console.                   |
-| [`set_single_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)            | Sets the default layer, but does _not_ write it to persistent memory (EEPROM). | 
-| [`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer) | Sets the default layer and writes it to persistent memory (EEPROM).  |
-| [`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z) | Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off). |
-| [`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z) | Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions. |
+|Function                                     |Description                                                                                             |
+|---------------------------------------------|--------------------------------------------------------------------------------------------------------|
+|`layer_state_set(layer_mask)`                |Directly sets the layer state (avoid unless you know what you are doing).                               |
+|`layer_clear()`                              |Clears all layers (turns them all off).                                                                 |
+|`layer_move(layer)`                          |Turns specified layer on, and all other layers off.                                                     |
+|`layer_on(layer)`                            |Turns specified layer on, leaves all other layers in existing state.                                    |
+|`layer_off(layer)`                           |Turns specified layer off, leaves all other layers in existing state.                                   |
+|`layer_invert(layer)`                        |Inverts/toggles the state of the specified layer                                                        |
+|`layer_or(layer_mask)`                       |Turns on layers based on matching bits between specified layer and existing layer state.                |
+|`layer_and(layer_mask)`                      |Turns on layers based on matching enabled bits between specified layer and existing layer state.        |
+|`layer_xor(layer_mask)`                      |Turns on layers based on non-matching bits between specified layer and existing layer state.            |
+|`layer_debug(layer_mask)`                    |Prints out the current bit mask and highest active layer to debugger console.                           |
+|`default_layer_set(layer_mask)`              |Directly sets the default layer state (avoid unless you know what you are doing).                       |
+|`default_layer_or(layer_mask)`               |Turns on layers based on matching bits between specified layer and existing default layer state.        |
+|`default_layer_and(layer_mask)`              |Turns on layers based on matching enabled bits between specified layer and existing default layer state.|
+|`default_layer_xor(layer_mask)`              |Turns on layers based on non-matching bits between specified layer and existing default layer state.    |
+|`default_layer_debug(layer_mask)`            |Prints out the current bit mask and highest active default layer to debugger console.                   |
+|[`set_single_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)           |Sets the default layer, but does _not_ write it to persistent memory (EEPROM).                      |
+|[`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)|Sets the default layer and writes it to persistent memory (EEPROM).                                 |
+|[`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z)                                |Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off).|
+|[`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z)       |Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions.               |
 
 In addition to the functions that you can call, there are a number of callback functions that get called every time the layer changes. This passes the layer state to the function, where it can be read or modified.
 
@@ -154,7 +154,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
   switch (keycode) {
     case KC_CYCLE_LAYERS:
       // Our logic will happen on presses, nothing is done on releases
-      if (!record->event.pressed) { 
+      if (!record->event.pressed) {
         // We've already handled the keycode (doing nothing), let QMK know so no further code is run unnecessarily
         return false;
       }

docs/feature_userspace.md

@@ -24,10 +24,10 @@ For example,
 
     make planck:jack
 
-Will include the `/users/jack/` folder in the path, along with `/users/jack/rules.mk`.  
+Will include the `/users/jack/` folder in the path, along with `/users/jack/rules.mk`.
 
 ::: warning
-This `name` can be [overridden](#override-default-userspace), if needed.  
+This `name` can be [overridden](#override-default-userspace), if needed.
 :::
 
 ## `Rules.mk`
@@ -38,9 +38,9 @@ It's highly recommended that you use `<name>.c` as the default source file to be
 
     SRC += <name>.c
 
-Additional files may be added in the same way - it's recommended you have one named `<name>`.c/.h to start off with, though. 
+Additional files may be added in the same way - it's recommended you have one named `<name>`.c/.h to start off with, though.
 
-The `/users/<name>/rules.mk` file will be included in the build _after_ the `rules.mk` from your keymap. This allows you to have features in your userspace `rules.mk` that depend on individual QMK features that may or may not be available on a specific keyboard. 
+The `/users/<name>/rules.mk` file will be included in the build _after_ the `rules.mk` from your keymap. This allows you to have features in your userspace `rules.mk` that depend on individual QMK features that may or may not be available on a specific keyboard.
 
 For example, if you have RGB control features shared between all your keyboards that support RGB lighting, you can add support for that if the RGBLIGHT feature is enabled:
 ```make
@@ -82,7 +82,7 @@ You should use the `config.h` for [configuration options](config_options), and t
 
 Please include authorship (your name, GitHub username, email), and optionally [a license that's GPL compatible](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).
 
-You can use this as a template: 
+You can use this as a template:
 ```
 Copyright <year> <name> <email> @<github_username>
 
@@ -100,9 +100,9 @@ You should have received a copy of the GNU General Public License
 along with this program.  If not, see <http://www.gnu.org/licenses/>.
 ```
 
-You'd want to replace the year, name, email and GitHub username with your info. 
+You'd want to replace the year, name, email and GitHub username with your info.
 
-Additionally, this is a good place to document your code, if you wish to share it with others. 
+Additionally, this is a good place to document your code, if you wish to share it with others.
 
 ## Build All Keyboards That Support a Specific Keymap
 
@@ -118,20 +118,21 @@ This is ideal for when you want ensure everything compiles successfully when pre
 
 ## Examples
 
-For a brief example, checkout [`/users/_example/`](https://github.com/qmk/qmk_firmware/tree/master/users/_example).  
-For more complicated examples, checkout the [`awesome-qmk` colletion](https://github.com/qmk/awesome-qmk).
+For a brief example, checkout [`/users/_example/`](https://github.com/qmk/qmk_firmware/tree/master/users/_example).
+
+For more complicated examples, checkout the [`awesome-qmk` collection](https://github.com/qmk/awesome-qmk).
 
 
 ### Customized Functions
 
-QMK has a bunch of [functions](custom_quantum_functions) that have [`_quantum`, `_kb`, and `_user` versions](custom_quantum_functions#a-word-on-core-vs-keyboards-vs-keymap) that you can use.  You will pretty much always want to use the user version of these functions.  But the problem is that if you use them in your userspace, then you don't have a version that you can use in your keymap. 
+QMK has a bunch of [functions](custom_quantum_functions) that have [`_quantum`, `_kb`, and `_user` versions](custom_quantum_functions#a-word-on-core-vs-keyboards-vs-keymap) that you can use.  You will pretty much always want to use the user version of these functions.  But the problem is that if you use them in your userspace, then you don't have a version that you can use in your keymap.
 
-However, you can actually add support for keymap version, so that you can use it in both your userspace and your keymap! 
+However, you can actually add support for keymap version, so that you can use it in both your userspace and your keymap!
 
 
-For instance, let's look at the `layer_state_set_user()` function.  You can enable the [Tri Layer State](ref_functions#olkb-tri-layers) functionality on all of your boards, while also retaining the Tri Layer functionality in your `keymap.c` files. 
+For instance, let's look at the `layer_state_set_user()` function.  You can enable the [Tri Layer State](ref_functions#olkb-tri-layers) functionality on all of your boards, while also retaining the Tri Layer functionality in your `keymap.c` files.
 
-In your `<name.c>` file, you'd want to add this: 
+In your `<name.c>` file, you'd want to add this:
 ```c
 __attribute__ ((weak))
 layer_state_t layer_state_set_keymap (layer_state_t state) {
@@ -143,7 +144,7 @@ layer_state_t layer_state_set_user (layer_state_t state) {
   return layer_state_set_keymap (state);
 }
 ```
-The `__attribute__ ((weak))` part tells the compiler that this is a placeholder function that can then be replaced by a version in your `keymap.c`.  That way, you don't need to add it to your `keymap.c`, but if you do, you won't get any conflicts because the function is the same name. 
+The `__attribute__ ((weak))` part tells the compiler that this is a placeholder function that can then be replaced by a version in your `keymap.c`.  That way, you don't need to add it to your `keymap.c`, but if you do, you won't get any conflicts because the function is the same name.
 
 The `_keymap` part here doesn't matter, it just needs to be something other than `_quantum`, `_kb`, or `_user`, since those are already in use. So you could use `layer_state_set_mine`, `layer_state_set_fn`, or anything else.
 
@@ -151,7 +152,7 @@ You can see a list of this and other common functions in [`template.c`](https://
 
 ### Custom Features
 
-Since the Userspace feature can support a staggering number of boards, you may have boards that you want to enable certain functionality for, but not for others. And you can actually create "features" that you can enable or disable in your own userspace.  
+Since the Userspace feature can support a staggering number of boards, you may have boards that you want to enable certain functionality for, but not for others. And you can actually create "features" that you can enable or disable in your own userspace.
 
 For instance, if you wanted to have a bunch of macros available, but only on certain boards (to save space), you could "hide" them being a `#ifdef MACROS_ENABLED`, and then enable it per board.  To do this, add this to your rules.mk
 ```make
@@ -159,11 +160,11 @@ ifeq ($(strip $(MACROS_ENABLED)), yes)
     OPT_DEFS += -DMACROS_ENABLED
 endif
 ```
-The `OPT_DEFS` setting causes `MACROS_ENABLED` to be defined for your keyboards (note the `-D` in front of the name), and you could use `#ifdef MACROS_ENABLED` to check the status in your c/h files, and handle that code based on that. 
+The `OPT_DEFS` setting causes `MACROS_ENABLED` to be defined for your keyboards (note the `-D` in front of the name), and you could use `#ifdef MACROS_ENABLED` to check the status in your c/h files, and handle that code based on that.
 
 Then you add `MACROS_ENABLED = yes` to the `rules.mk` for you keymap to enable this feature and the code in your userspace.
 
-And in your `process_record_user` function, you'd do something like this: 
+And in your `process_record_user` function, you'd do something like this:
 ```c
 bool process_record_user(uint16_t keycode, keyrecord_t *record) {
   switch (keycode) {
@@ -187,9 +188,9 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
 
 ### Consolidated Macros
 
-If you wanted to consolidate macros and other functions into your userspace for all of your keymaps, you can do that.  This builds upon the [Customized Functions](#customized-functions) example above. This lets you maintain a bunch of macros that are shared between the different keyboards, and allow for keyboard specific macros, too. 
+If you wanted to consolidate macros and other functions into your userspace for all of your keymaps, you can do that.  This builds upon the [Customized Functions](#customized-functions) example above. This lets you maintain a bunch of macros that are shared between the different keyboards, and allow for keyboard specific macros, too.
 
-First, you'd want to go through all of your `keymap.c` files and replace `process_record_user` with `process_record_keymap` instead.   This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well.   You'll also want to replace `SAFE_RANGE` with `NEW_SAFE_RANGE` so that you wont have any overlapping keycodes
+First, you'd want to go through all of your `keymap.c` files and replace `process_record_user` with `process_record_keymap` instead.   This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well.   You'll also want to replace `SAFE_RANGE` with `NEW_SAFE_RANGE` so that you won't have any overlapping keycodes
 
 Then add `#include "<name>.h"` to all of your keymap.c files.  This allows you to use these new keycodes without having to redefine them in each keymap.
 
@@ -245,7 +246,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
 }
 ```
 
-For boards that may not have a shift button (such as on a macro pad), we need a way to always include the bootloader option.  To do that, add the following to the `rules.mk` in your userspace folder: 
+For boards that may not have a shift button (such as on a macro pad), we need a way to always include the bootloader option.  To do that, add the following to the `rules.mk` in your userspace folder:
 
 ```make
 ifeq ($(strip $(FLASH_BOOTLOADER)), yes)
@@ -255,7 +256,7 @@ endif
 
 This will add a new `KC_MAKE` keycode that can be used in any of your keymaps.  And this keycode will output `make <keyboard>:<keymap>`, making frequent compiling easier.  And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
 
-Also, holding Shift will add the flash target (`:flash`) to the command.  Holding Control will add some commands that will speed up compiling time by processing multiple files at once. 
+Also, holding Shift will add the flash target (`:flash`) to the command.  Holding Control will add some commands that will speed up compiling time by processing multiple files at once.
 
 And for the boards that lack a shift key, or that you want to always attempt the flashing part, you can add `FLASH_BOOTLOADER = yes` to the `rules.mk` of that keymap.
 

docs/features/audio.md

@@ -73,16 +73,13 @@ Should you rather choose to generate and use your own sample-table with the DAC
 
 
 ### PWM (software)
-if the DAC pins are unavailable (or the MCU has no usable DAC at all, like STM32F1xx); PWM can be an alternative.
+If the DAC pins are unavailable (or the MCU has no usable DAC at all, like STM32F1xx); PWM can be an alternative.
 Note that there is currently only one speaker/pin supported.
 
-set in `rules.mk`:
-
-`AUDIO_DRIVER = pwm_software` and in `config.h`: 
-`#define AUDIO_PIN C13` (can be any pin) to have the selected pin output a pwm signal, generated from a timer callback which toggles the pin in software.
+To use this feature, set `AUDIO_DRIVER = pwm_software` in `rules.mk` and set `#define AUDIO_PIN C13` (can be any pin) in `config.h` to have the selected pin output a pwm signal, generated from a timer callback which toggles the pin in software.
 
 #### Wiring
-the usual piezo wiring: red goes to the selected AUDIO_PIN, black goes to ground.
+The usual piezo wiring: red goes to the selected AUDIO_PIN, black goes to ground.
 
 OR if you can chose to drive one piezo with two pins, for example `#define AUDIO_PIN B1`, `#define AUDIO_PIN_ALT B2` in `config.h`, with `#define AUDIO_PIN_ALT_AS_NEGATIVE` - then the red lead could go to B1, the black to B2.
 
@@ -159,7 +156,7 @@ PLAY_LOOP(my_song);
 
 It's advised that you wrap all audio features in `#ifdef AUDIO_ENABLE` / `#endif` to avoid causing problems when audio isn't built into the keyboard.
 
-The available keycodes for audio are: 
+The available keycodes for audio are:
 
 |Key                      |Aliases  |Description                                |
 |-------------------------|---------|-------------------------------------------|
@@ -178,8 +175,8 @@ These keycodes turn all of the audio functionality on and off.  Turning it off m
 |`AUDIO_PIN`                       | *Not defined*        |Configures the pin that the speaker is connected to.                                         |
 |`AUDIO_PIN_ALT`                   | *Not defined*        |Configures the pin for a second speaker or second pin connected to one speaker.              |
 |`AUDIO_PIN_ALT_AS_NEGATIVE`       | *Not defined*        |Enables support for one speaker connected to two pins.                                       |
-|`AUDIO_INIT_DELAY`                | *Not defined*        |Enables delay during startup song to accomidate for USB startup issues.                      |
-|`AUDIO_ENABLE_TONE_MULTIPLEXING`  | *Not defined*        |Enables time splicing/multiplexing to create multiple tones simutaneously.                   |
+|`AUDIO_INIT_DELAY`                | *Not defined*        |Enables delay during startup song to accommodate for USB startup issues.                     |
+|`AUDIO_ENABLE_TONE_MULTIPLEXING`  | *Not defined*        |Enables time splicing/multiplexing to create multiple tones simultaneously.                  |
 |`AUDIO_POWER_CONTROL_PIN`         | *Not defined*        |Enables power control code to enable or cut off power to speaker (such as with PAM8302 amp). |
 |`AUDIO_POWER_CONTROL_PIN_ON_STATE`| `1`                  |The state of the audio power control pin when audio is "on" - `1` for high, `0` for low.     |
 |`STARTUP_SONG`                    | `STARTUP_SOUND`      |Plays when the keyboard starts up (audio.c)                                                  |
@@ -301,9 +298,9 @@ Things that return false are not part of the mask, and are always processed.
 
 ### Music Map
 
-By default, the Music Mode uses the columns and row to determine the scale for the keys. For a board that uses a rectangular matrix that matches the keyboard layout, this is just fine.  However, for boards that use a more complicated matrix (such as the Planck Rev6, or many split keyboards) this would result in a very skewed experience.  
+By default, the Music Mode uses the columns and row to determine the scale for the keys. For a board that uses a rectangular matrix that matches the keyboard layout, this is just fine.  However, for boards that use a more complicated matrix (such as the Planck Rev6, or many split keyboards) this would result in a very skewed experience.
 
-However, the Music Map option allows you to remap the scaling for the music mode, so it fits the layout, and is more natural. 
+However, the Music Map option allows you to remap the scaling for the music mode, so it fits the layout, and is more natural.
 
 To enable this feature, add `#define MUSIC_MAP` to your `config.h` file, and then you will want to add a `uint8_t music_map` to your keyboard's `c` file, or your `keymap.c`.
 
@@ -316,13 +313,13 @@ const uint8_t music_map[MATRIX_ROWS][MATRIX_COLS] = LAYOUT_ortho_4x12(
 );
 ```
 
-You will want to use whichever `LAYOUT` macro that your keyboard uses here.  This maps it to the correct key location.  Start in  the bottom left of the keyboard layout, and  move to the right, and then upwards.  Fill in all the entries until you have a complete matrix.  
+You will want to use whichever `LAYOUT` macro that your keyboard uses here.  This maps it to the correct key location.  Start in  the bottom left of the keyboard layout, and  move to the right, and then upwards.  Fill in all the entries until you have a complete matrix.
 
-You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e9ace1487887c1f8b4a7e8e6d87c322988bec9ce/keyboards/planck/planck.c#L24-L29) as an example of how to implement this. 
+You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e9ace1487887c1f8b4a7e8e6d87c322988bec9ce/keyboards/planck/planck.c#L24-L29) as an example of how to implement this.
 
 ## Audio Click
 
-This adds a click sound each time you hit a button, to simulate click sounds from the keyboard. And the sounds are slightly different for each keypress, so it doesn't sound like a single long note, if you type rapidly. 
+This adds a click sound each time you hit a button, to simulate click sounds from the keyboard. And the sounds are slightly different for each keypress, so it doesn't sound like a single long note, if you type rapidly.
 
 Keycodes available:
 
@@ -341,7 +338,7 @@ The feature is disabled by default, to save space.  To enable it, add this to yo
 #define AUDIO_CLICKY
 ```
 
-You can configure the default, min and max frequencies, the stepping and built in randomness by defining these values: 
+You can configure the default, min and max frequencies, the stepping and built in randomness by defining these values:
 
 | Option | Default Value | Description |
 |--------|---------------|-------------|
@@ -349,7 +346,7 @@ You can configure the default, min and max frequencies, the stepping and built i
 | `AUDIO_CLICKY_FREQ_MIN` | 65.0f | Sets the lowest frequency (under 60f are a bit buggy). |
 | `AUDIO_CLICKY_FREQ_MAX` | 1500.0f | Sets the highest frequency. Too high may result in coworkers attacking you. |
 | `AUDIO_CLICKY_FREQ_FACTOR` | 1.18921f| Sets the stepping of UP/DOWN key codes.  This is a multiplicative factor.  The default steps the frequency up/down by a musical minor third.  |
-| `AUDIO_CLICKY_FREQ_RANDOMNESS`     |  0.05f |  Sets a factor of randomness for the clicks, Setting this to `0f` will make each click identical, and `1.0f` will make this sound much like the 90's computer screen scrolling/typing effect. | 
+| `AUDIO_CLICKY_FREQ_RANDOMNESS`     |  0.05f |  Sets a factor of randomness for the clicks, Setting this to `0f` will make each click identical, and `1.0f` will make this sound much like the 90's computer screen scrolling/typing effect. |
 | `AUDIO_CLICKY_DELAY_DURATION` | 1 | An integer note duration where 1 is 1/16th of the tempo, or a sixty-fourth note (see `quantum/audio/musical_notes.h` for implementation details). The main clicky effect will be delayed by this duration.  Adjusting this to values around 6-12 will help compensate for loud switches. |
 
 ## MIDI Functionality

docs/features/battery.md

@@ -0,0 +1,55 @@
+# Battery
+
+This feature provides the high level abstraction for sampling battery level.
+
+## Usage
+
+To use this driver, add the following to your `rules.mk`:
+
+```make
+BATTERY_ENABLE = yes
+```
+
+## Basic Configuration {#basic-configuration}
+
+Add the following to your `config.h`:
+
+|Define                    |Default |Description                                       |
+|--------------------------|--------|--------------------------------------------------|
+|`BATTERY_SAMPLE_INTERVAL` |`30000` |The time between battery samples in milliseconds. |
+
+## Driver Configuration {#driver-configuration}
+
+See the [Battery Driver](../drivers/battery) documentation for more information.
+
+## Functions
+
+### `uint8_t battery_get_percent(void)` {#api-battery-get-percent}
+
+Sample battery level.
+
+#### Return Value {#api-battery-get-percent-return}
+
+The battery percentage, in the range 0-100.
+
+## Callbacks
+
+### `void battery_percent_changed_user(uint8_t level)` {#api-battery-percent-changed-user}
+
+User hook called when battery level changed.
+
+### Arguments {#api-battery-percent-changed-user-arguments}
+
+ - `uint8_t level`  
+   The battery percentage, in the range 0-100.
+
+---
+
+### `void battery_percent_changed_kb(uint8_t level)` {#api-battery-percent-changed-kb}
+
+Keyboard hook called when battery level changed.
+
+### Arguments {#api-battery-percent-changed-kb-arguments}
+
+ - `uint8_t level`  
+   The battery percentage, in the range 0-100.

docs/features/bootmagic.md

@@ -46,7 +46,7 @@ When [handedness](split_keyboard#setting-handedness) is predetermined via option
     }
 ```
 
-If you pick the top right key for the right half, it is `R05` on the top layout. Within the key matrix below, `R05` is located on row 4 columnn 4. To use that key as the right half's Bootmagic trigger, add these entries to your `config.h` file:
+If you pick the top right key for the right half, it is `R05` on the top layout. Within the key matrix below, `R05` is located on row 4 column 4. To use that key as the right half's Bootmagic trigger, add these entries to your `config.h` file:
 
 ```c
 #define BOOTMAGIC_ROW_RIGHT 4

docs/features/encoders.md

@@ -68,7 +68,7 @@ Additionally, if one side does not have an encoder, you can specify `{}` for the
 ```
 
 ::: warning
-Keep in mind that whenver you change the encoder resolution, you will need to reflash the half that has the encoder affected by the change.
+Keep in mind that whenever you change the encoder resolution, you will need to reflash the half that has the encoder affected by the change.
 :::
 
 ## Encoder map {#encoder-map}

docs/features/haptic_feedback.md

@@ -44,14 +44,14 @@ Not all keycodes below will work depending on which haptic mechanism you have ch
 |`QK_HAPTIC_MODE_NEXT`        |`HF_NEXT`| Go to next DRV2605L waveform                          |
 |`QK_HAPTIC_MODE_PREVIOUS`    |`HF_PREV`| Go to previous DRV2605L waveform                      |
 |`QK_HAPTIC_CONTINUOUS_TOGGLE`|`HF_CONT`| Toggle continuous haptic mode on/off                  |
-|`QK_HAPTIC_CONTINUOUS_UP`    |`HF_CONU`| Increase DRV2605L continous haptic strength           |
-|`QK_HAPTIC_CONTINUOUS_DOWN`  |`HF_COND`| Decrease DRV2605L continous haptic strength           |
+|`QK_HAPTIC_CONTINUOUS_UP`    |`HF_CONU`| Increase DRV2605L continuous haptic strength          |
+|`QK_HAPTIC_CONTINUOUS_DOWN`  |`HF_COND`| Decrease DRV2605L continuous haptic strength          |
 |`QK_HAPTIC_DWELL_UP`         |`HF_DWLU`| Increase Solenoid dwell time                          |
 |`QK_HAPTIC_DWELL_DOWN`       |`HF_DWLD`| Decrease Solenoid dwell time                          |
 
 ### Solenoids
 
-The solenoid code supports relay switches, and similar hardware, as well as solenoids. 
+The solenoid code supports relay switches, and similar hardware, as well as solenoids.
 
 For a regular solenoid,  you will need a build a circuit to drive the solenoid through a mosfet as most MCU will not be able to provide the current needed to drive the coil in the solenoid.
 
@@ -75,7 +75,7 @@ For relay switches, the hardware may already contain all of that ciruitry, and j
 |`SOLENOID_BUZZ_NONACTUATED` | `SOLENOID_MIN_DWELL` |Non-Actuated-time when the switch is in buzz mode.            |
 
 * If solenoid buzz is off, then dwell time is how long the "plunger" stays activated. The dwell time changes how the solenoid sounds.
-* If solenoid buzz is on, then dwell time sets the length of the buzz, while `SOLENOID_BUZZ_ACTUATED` and `SOLENOID_BUZZ_NONACTUATED` set the (non-)actuation times withing the buzz period.
+* If solenoid buzz is on, then dwell time sets the length of the buzz, while `SOLENOID_BUZZ_ACTUATED` and `SOLENOID_BUZZ_NONACTUATED` set the (non-)actuation times within the buzz period.
 * With the current implementation, for any of the above time settings, the precision of these settings may be affected by how fast the keyboard is able to scan the matrix.
   Therefore, if the keyboards scanning routine is slow, it may be preferable to set `SOLENOID_DWELL_STEP_SIZE` to a value slightly smaller than the time it takes to scan the keyboard.
 
@@ -104,7 +104,7 @@ Eccentric Rotating Mass vibration motors (ERM) is motor with a off-set weight at
 ```
 ##### LRA
 
-Linear resonant actuators (LRA, also know as a linear vibrator) works different from a ERM. A LRA has a weight and magnet suspended by springs and a voice coil. When the drive signal is applied, the weight would be vibrate on a single axis (side to side or up and down). Since the weight is attached to a spring, there is a resonance effect at a specific frequency. This frequency is where the LRA will operate the most efficiently. Refer to the motor's datasheet for the recommanded range for this frequency.
+Linear resonant actuators (LRA, also know as a linear vibrator) works different from a ERM. A LRA has a weight and magnet suspended by springs and a voice coil. When the drive signal is applied, the weight would be vibrate on a single axis (side to side or up and down). Since the weight is attached to a spring, there is a resonance effect at a specific frequency. This frequency is where the LRA will operate the most efficiently. Refer to the motor's datasheet for the recommended range for this frequency.
 
 ```c
 #define DRV2605L_FB_ERM_LRA 1
@@ -114,7 +114,7 @@ Linear resonant actuators (LRA, also know as a linear vibrator) works different
 /* Please refer to your datasheet for the optimal setting for your specific motor. */
 #define DRV2605L_RATED_VOLTAGE 2
 #define DRV2605L_V_PEAK 2.8
-#define DRV2605L_V_RMS 2.0 
+#define DRV2605L_V_RMS 2.0
 #define DRV2605L_V_PEAK 2.1
 #define DRV2605L_F_LRA 205 /* resonance freq */
 ```
@@ -125,7 +125,7 @@ DRV2605L comes with preloaded library of various waveform sequences that can be
 
 List of waveform sequences from the datasheet:
 
-|seq# | Sequence name          |seq# | Sequence name                  |seq# |Sequence name                           |
+|seq# | Sequence name       |seq# | Sequence name                     |seq# |Sequence name                         |
 |-----|---------------------|-----|-----------------------------------|-----|--------------------------------------|
 | 1   | strong_click 		| 43  | lg_dblclick_med_60                | 85  | transition_rampup_med_smooth2        |
 | 2   | strong_click_60 	| 44  | lg_dblsharp_tick                  | 86  | transition_rampup_short_smooth1      |

docs/features/led_matrix.md

@@ -214,9 +214,30 @@ led_matrix_mode(LED_MATRIX_CUSTOM_my_cool_effect);
 For inspiration and examples, check out the built-in effects under `quantum/led_matrix/animations/`.
 
 
+## Naming
+
+If you wish to be able to use the name of an effect in your code -- say for a display indicator -- then you can enable the function `led_matrix_get_mode_name` in the following manner:
+
+In your keymap's `config.h`:
+```c
+#define LED_MATRIX_MODE_NAME_ENABLE
+```
+
+In your `keymap.c`
+```c
+const char* effect_name = led_matrix_get_mode_name(led_matrix_get_mode());
+// do something with `effect_name`, like `oled_write_ln(effect_name, false);`
+```
+
+::: info
+`led_matrix_get_mode_name()` is not enabled by default as it increases the amount of flash memory used by the firmware based on the number of effects enabled.
+:::
+
+
 ## Additional `config.h` Options {#additional-configh-options}
 
 ```c
+#define LED_MATRIX_MODE_NAME_ENABLE // enables led_matrix_get_mode_name()
 #define LED_MATRIX_KEYRELEASES // reactive effects respond to keyreleases (instead of keypresses)
 #define LED_MATRIX_TIMEOUT 0 // number of milliseconds to wait until led automatically turns off
 #define LED_MATRIX_SLEEP // turn off effects when suspended

docs/features/pointing_device.md

@@ -51,7 +51,7 @@ The ADNS 9800 is an SPI driven optical sensor, that uses laser output for surfac
 | `ADNS9800_CS_PIN`       | (Required) Sets the Chip Select pin connected to the sensor.           | `POINTING_DEVICE_CS_PIN` |
 
 
-The CPI range is 800-8200, in increments of 200. Defaults to 1800 CPI. 
+The CPI range is 800-8200, in increments of 200. Defaults to 1800 CPI.
 
 ### Analog Joystick
 
@@ -258,7 +258,7 @@ To use the paw 3204 sensor, add this to your `rules.mk`
 POINTING_DEVICE_DRIVER = paw3204
 ```
 
-The paw 3204 sensor uses a serial type protocol for communication, and requires an additional light source. 
+The paw 3204 sensor uses a serial type protocol for communication, and requires an additional light source.
 
 | Setting (`config.h`) | Description                                                    | Default                    |
 | -------------------- |--------------------------------------------------------------- | -------------------------- |
@@ -275,7 +275,7 @@ To use the Pimoroni Trackball module, add this to your `rules.mk`:
 POINTING_DEVICE_DRIVER = pimoroni_trackball
 ```
 
-The Pimoroni Trackball module is a I2C based breakout board with an RGB enable trackball. 
+The Pimoroni Trackball module is a I2C based breakout board with an RGB enable trackball.
 
 | Setting (`config.h`)                 | Description                                                                        | Default |
 | ------------------------------------ | ---------------------------------------------------------------------------------- | ------- |
@@ -379,14 +379,14 @@ POINTING_DEVICE_DRIVER = custom
 Using the custom driver will require implementing the following functions:
 
 ```c
-void           pointing_device_driver_init(void) {}
+bool           pointing_device_driver_init(void) { return true; }
 report_mouse_t pointing_device_driver_get_report(report_mouse_t mouse_report) { return mouse_report; }
 uint16_t       pointing_device_driver_get_cpi(void) { return 0; }
 void           pointing_device_driver_set_cpi(uint16_t cpi) {}
 ```
 
 ::: warning
-Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/pointing_device_drivers.c`, but there may be cases where it's very specific to the hardware.  So these functions are provided, just in case. 
+Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/pointing_device_drivers.c`, but there may be cases where it's very specific to the hardware.  So these functions are provided, just in case.
 :::
 
 ## Common Configuration
@@ -413,7 +413,7 @@ Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/
 When using `SPLIT_POINTING_ENABLE` the `POINTING_DEVICE_MOTION_PIN` functionality is not supported and `POINTING_DEVICE_TASK_THROTTLE_MS` will default to `1`. Increasing this value will increase transport performance at the cost of possible mouse responsiveness.
 :::
 
-The `POINTING_DEVICE_CS_PIN`, `POINTING_DEVICE_SDIO_PIN`, and `POINTING_DEVICE_SCLK_PIN` provide a convenient way to define a single pin that can be used for an interchangeable sensor config.  This allows you to have a single config, without defining each device.  Each sensor allows for this to be overridden with their own defines. 
+The `POINTING_DEVICE_CS_PIN`, `POINTING_DEVICE_SDIO_PIN`, and `POINTING_DEVICE_SCLK_PIN` provide a convenient way to define a single pin that can be used for an interchangeable sensor config.  This allows you to have a single config, without defining each device.  Each sensor allows for this to be overridden with their own defines.
 
 ::: warning
 Any pointing device with a lift/contact status can integrate inertial cursor feature into its driver, controlled by `POINTING_DEVICE_GESTURES_CURSOR_GLIDE_ENABLE`. e.g. PMW3360 can use Lift_Stat from Motion register. Note that `POINTING_DEVICE_MOTION_PIN` cannot be used with this feature; continuous polling of `get_report()` is needed to generate glide reports.
@@ -424,7 +424,7 @@ Any pointing device with a lift/contact status can integrate inertial cursor fea
 | Setting                                  | Description                                                                                                               | Default       |
 | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------- |
 | `POINTING_DEVICE_HIRES_SCROLL_ENABLE`    | (Optional) Enables high resolution scrolling.                                                                             | _not defined_ |
-| `POINTING_DEVICE_HIRES_SCROLL_MULTIPLIER`| (Optional) Resolution mutiplier value used by high resolution scrolling. Must be between 1 and 127, inclusive.            | `120`         |
+| `POINTING_DEVICE_HIRES_SCROLL_MULTIPLIER`| (Optional) Resolution multiplier value used by high resolution scrolling. Must be between 1 and 127, inclusive.           | `120`         |
 | `POINTING_DEVICE_HIRES_SCROLL_EXPONENT`  | (Optional) Resolution exponent value used by high resolution scrolling. Must be between 0 and 127, inclusive.             | `0`           |
 
 The `POINTING_DEVICE_HIRES_SCROLL_ENABLE` setting enables smooth and continuous scrolling when using trackballs or high-end encoders as mouse wheels (as opposed to the typical stepped behavior of most mouse wheels).
@@ -435,7 +435,7 @@ If even smoother scrolling than provided by this default value is desired, first
 The function `pointing_device_get_hires_scroll_resolution()` can be called to get the pre-computed resolution multiplier value as a `uint16_t`.
 
 ::: warning
-High resolution scrolling usually results in larger and/or more frequent mouse reports. This can result in overflow errors and overloading of the host computer's input buffer. 
+High resolution scrolling usually results in larger and/or more frequent mouse reports. This can result in overflow errors and overloading of the host computer's input buffer.
 To deal with these issues, define `WHEEL_EXTENDED_REPORT` and throttle the rate at which mouse reports are sent.
 :::
 
@@ -465,22 +465,24 @@ If there is a `_RIGHT` configuration option or callback, the [common configurati
 :::
 
 
-## Callbacks and Functions 
+## Callbacks and Functions
 
-| Function                                                   | Description                                                                                                   |
-| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
-| `pointing_device_init_kb(void)`                            | Callback to allow for keyboard level initialization. Useful for additional hardware sensors.                  |
-| `pointing_device_init_user(void)`                          | Callback to allow for user level initialization. Useful for additional hardware sensors.                      |
-| `pointing_device_task_kb(mouse_report)`                    | Callback that sends sensor data, so keyboard code can intercept and modify the data.  Returns a mouse report. |
-| `pointing_device_task_user(mouse_report)`                  | Callback that sends sensor data, so user code can intercept and modify the data.  Returns a mouse report.     |
-| `pointing_device_handle_buttons(buttons, pressed, button)` | Callback to handle hardware button presses. Returns a `uint8_t`.                                              |
-| `pointing_device_get_cpi(void)`                            | Gets the current CPI/DPI setting from the sensor, if supported.                                               |
-| `pointing_device_set_cpi(uint16_t)`                        | Sets the CPI/DPI, if supported.                                                                               |
-| `pointing_device_get_report(void)`                         | Returns the current mouse report (as a `report_mouse_t` data structure).                                      |
-| `pointing_device_set_report(mouse_report)`                 | Sets the mouse report to the assigned `report_mouse_t` data structured passed to the function.                |
-| `pointing_device_send(void)`                               | Sends the current mouse report to the host system.  Function can be replaced.                                 |
-| `has_mouse_report_changed(new_report, old_report)`         | Compares the old and new `report_mouse_t` data and returns true only if it has changed.                       |
-| `pointing_device_adjust_by_defines(mouse_report)`          | Applies rotations and invert configurations to a raw mouse report.                                            |
+| Function                                                      | Description                                                                                                   |
+| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
+| `pointing_device_init_kb(void)`                               | Callback to allow for keyboard level initialization. Useful for additional hardware sensors.                  |
+| `pointing_device_init_user(void)`                             | Callback to allow for user level initialization. Useful for additional hardware sensors.                      |
+| `pointing_device_task_kb(mouse_report)`                       | Callback that sends sensor data, so keyboard code can intercept and modify the data.  Returns a mouse report. |
+| `pointing_device_task_user(mouse_report)`                     | Callback that sends sensor data, so user code can intercept and modify the data.  Returns a mouse report.     |
+| `pointing_device_handle_buttons(buttons, pressed, button)`    | Callback to handle hardware button presses. Returns a `uint8_t`.                                              |
+| `pointing_device_get_cpi(void)`                               | Gets the current CPI/DPI setting from the sensor, if supported.                                               |
+| `pointing_device_set_cpi(uint16_t)`                           | Sets the CPI/DPI, if supported.                                                                               |
+| `pointing_device_get_report(void)`                            | Returns the current mouse report (as a `report_mouse_t` data structure).                                      |
+| `pointing_device_set_report(mouse_report)`                    | Sets the mouse report to the assigned `report_mouse_t` data structured passed to the function.                |
+| `pointing_device_send(void)`                                  | Sends the current mouse report to the host system.  Function can be replaced.                                 |
+| `has_mouse_report_changed(new_report, old_report)`            | Compares the old and new `report_mouse_t` data and returns true only if it has changed.                       |
+| `pointing_device_adjust_by_defines(mouse_report)`             | Applies rotations and invert configurations to a raw mouse report.                                            |
+| `pointing_device_get_status(void)`                            | Returns device status as `pointing_device_status_t` a good return is `POINTING_DEVICE_STATUS_SUCCESS`.        |
+| `pointing_device_set_status(pointing_device_status_t status)` | Sets device status, anything other than `POINTING_DEVICE_STATUS_SUCCESS` will disable reports from the device.|
 
 
 ## Split Keyboard Callbacks and Functions
@@ -511,7 +513,7 @@ To manually manipulate the mouse reports outside of the `pointing_device_task_*`
 
 * `pointing_device_get_report()` - Returns the current report_mouse_t that represents the information sent to the host computer
 * `pointing_device_set_report(report_mouse_t mouse_report)` - Overrides and saves the report_mouse_t to be sent to the host computer
-* `pointing_device_send()` - Sends the mouse report to the host and zeroes out the report. 
+* `pointing_device_send()` - Sends the mouse report to the host and zeroes out the report.
 
 When the mouse report is sent, the x, y, v, and h values are set to 0 (this is done in `pointing_device_send()`, which can be overridden to avoid this behavior).  This way, button states persist, but movement will only occur once.  For further customization, both `pointing_device_init` and `pointing_device_task` can be overridden.
 
@@ -546,7 +548,7 @@ Recall that the mouse report is set to zero (except the buttons) whenever it is
 
 ### Drag Scroll or Mouse Scroll
 
-A very common implementation is to use the mouse movement to scroll instead of moving the cursor on the system.  This uses the `pointing_device_task_user` callback to intercept and modify the mouse report before it's sent to the host system. 
+A very common implementation is to use the mouse movement to scroll instead of moving the cursor on the system.  This uses the `pointing_device_task_user` callback to intercept and modify the mouse report before it's sent to the host system.
 
 ```c
 enum custom_keycodes {
@@ -573,7 +575,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
 }
 ```
 
-This allows you to toggle between scrolling and cursor movement by pressing the DRAG_SCROLL key.  
+This allows you to toggle between scrolling and cursor movement by pressing the DRAG_SCROLL key.
 
 ### Advanced Drag Scroll
 
@@ -709,7 +711,7 @@ If you are having issues with pointing device drivers debug messages can be enab
 ```c
 #define POINTING_DEVICE_DEBUG
 ```
- 
+
 ::: tip
 The messages will be printed out to the `CONSOLE` output. For additional information, refer to [Debugging/Troubleshooting QMK](../faq_debug).
 :::
@@ -718,7 +720,7 @@ The messages will be printed out to the `CONSOLE` output. For additional informa
 ---
 # Automatic Mouse Layer {#pointing-device-auto-mouse}
 
-When using a pointing device combined with a keyboard the mouse buttons are often kept on a separate layer from the default keyboard layer, which requires pressing or holding a key to change layers before using the mouse. To make this easier and more efficient an additional pointing device feature may be enabled that will automatically activate a target layer as soon as the pointing device is active _(in motion, mouse button pressed etc.)_ and deactivate the target layer after a set time.   
+When using a pointing device combined with a keyboard the mouse buttons are often kept on a separate layer from the default keyboard layer, which requires pressing or holding a key to change layers before using the mouse. To make this easier and more efficient an additional pointing device feature may be enabled that will automatically activate a target layer as soon as the pointing device is active _(in motion, mouse button pressed etc.)_ and deactivate the target layer after a set time.
 
 Additionally if any key that is defined as a mouse key is pressed then the layer will be held as long as the key is pressed and the timer will be reset on key release. When a non-mouse key is pressed then the layer is deactivated early _(with some exceptions see below)_.  Mod, mod tap, and one shot mod keys are ignored _(i.e. don't hold or activate layer but do not deactivate the layer either)_ when sending a modifier keycode _(e.g. hold for mod tap)_ allowing for mod keys to be used with the mouse without activating the target layer when typing.
 
@@ -752,8 +754,9 @@ void pointing_device_init_user(void) {
 }
 ```
 
-Because the auto mouse feature can be disabled/enabled during runtime and starts as disabled by default it must be enabled by calling `set_auto_mouse_enable(true);` somewhere in firmware before the feature will work.   
-_Note: for setting the target layer during initialization either setting `AUTO_MOUSE_DEFAULT_LAYER` in `config.h` or calling `set_auto_mouse_layer(<mouse_layer>)` can be used._   
+Because the auto mouse feature can be disabled/enabled during runtime and starts as disabled by default it must be enabled by calling `set_auto_mouse_enable(true);` somewhere in firmware before the feature will work.
+
+_Note: for setting the target layer during initialization either setting `AUTO_MOUSE_DEFAULT_LAYER` in `config.h` or calling `set_auto_mouse_layer(<mouse_layer>)` can be used._
 
 
 ## How to Customize:
@@ -772,7 +775,7 @@ There are a few ways to control the auto mouse feature with both `config.h` opti
 
 ### Adding mouse keys
 
-While all default mouse keys and layer keys(for current mouse layer) are treated as mouse keys, additional Keyrecords can be added to mouse keys by adding them to the is_mouse_record_* stack. 
+While all default mouse keys and layer keys(for current mouse layer) are treated as mouse keys, additional Keyrecords can be added to mouse keys by adding them to the is_mouse_record_* stack.
 
 #### Callbacks for setting up additional key codes as mouse keys:
 | Callback                                                             | Description                                        |
@@ -780,7 +783,7 @@ While all default mouse keys and layer keys(for current mouse layer) are treated
 | `bool is_mouse_record_kb(uint16_t keycode, keyrecord_t* record)`     |  keyboard level callback for adding mouse keys     |
 | `bool is_mouse_record_user(uint16_t keycode, keyrecord_t* record)`   |  user/keymap level callback for adding mouse keys  |
 
-##### To use the callback function to add mouse keys:   
+##### To use the callback function to add mouse keys:
 
 The following code will cause the enter key and all of the arrow keys to be treated as mouse keys (hold target layer while they are pressed and reset active layer timer).
 ```c
@@ -804,7 +807,7 @@ bool is_mouse_record_kb(uint16_t keycode, keyrecord_t* record) {
 
 There are several functions that allow for more advanced interaction with the auto mouse feature allowing for greater control.
 
-### Functions to control auto mouse enable and target layer:   
+### Functions to control auto mouse enable and target layer:
 | Function                                                   | Description                                                                          | Aliases                   |     Return type |
 | :--------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------- | --------------: |
 | `set_auto_mouse_enable(bool enable)`                       | Enable or disable auto mouse (true:enable, false:disable)                            |                           |    `void`(None) |
@@ -823,25 +826,27 @@ There are several functions that allow for more advanced interaction with the au
 | `get_auto_mouse_key_tracker(void)`                         | Gets the current count for the auto mouse key tracker.                               |                           |        `int8_t` |
 | `set_auto_mouse_key_tracker(int8_t key_tracker)`           | Sets/Overrides the current count for the auto mouse key tracker.                     |                           |    `void`(None) |
 
-_NOTES:_   
-    - _Due to the nature of how some functions work, the `auto_mouse_trigger_reset`, and `auto_mouse_layer_off` functions should never be called in the `layer_state_set_*` stack as this can cause indefinite loops._   
-    - _It is recommended that `remove_auto_mouse_layer` is used in the `layer_state_set_*` stack of functions and `auto_mouse_layer_off` is used everywhere else_   
-    - _`remove_auto_mouse_layer(state, false)` or `auto_mouse_layer_off()` should be called before any instance of `set_auto_mouse_enabled(false)` or `set_auto_mouse_layer(layer)` to ensure that the target layer will be removed appropriately before disabling auto mouse or changing target to avoid a stuck layer_      
-    
-### Functions for handling custom key events:   
+_NOTES:_
+
+- _Due to the nature of how some functions work, the `auto_mouse_trigger_reset`, and `auto_mouse_layer_off` functions should never be called in the `layer_state_set_*` stack as this can cause indefinite loops._
+- _It is recommended that `remove_auto_mouse_layer` is used in the `layer_state_set_*` stack of functions and `auto_mouse_layer_off` is used everywhere else_
+- _`remove_auto_mouse_layer(state, false)` or `auto_mouse_layer_off()` should be called before any instance of `set_auto_mouse_enabled(false)` or `set_auto_mouse_layer(layer)` to ensure that the target layer will be removed appropriately before disabling auto mouse or changing target to avoid a stuck layer_
+
+### Functions for handling custom key events:
 | Function                                                   | Description                                                                      |     Return type |
 | :--------------------------------------------------------- | -------------------------------------------------------------------------------- | --------------: |
 | `auto_mouse_keyevent(bool pressed)`                        | Auto mouse mouse key event (true: key down, false: key up)                       |    `void`(None) |
 | `auto_mouse_trigger_reset(bool pressed)`                   | Reset auto mouse status on key down and start delay timer (non-mouse key event)  |    `void`(None) |
 | `auto_mouse_toggle(void)`                                  | Toggle on/off target toggle state (disables layer deactivation when true)        |    `void`(None) |
-| `get_auto_mouse_toggle(void)`                              | Return value of toggling state variable                                          |          `bool` |   
+| `get_auto_mouse_toggle(void)`                              | Return value of toggling state variable                                          |          `bool` |
+
 _NOTE: Generally it would be preferable to use the `is_mouse_record_*` functions to add any additional keys that should act as mouse keys rather than adding `auto_mouse_keyevent(record.event->pressed)` to `process_records_*`_
 
-### Advanced control examples   
+### Advanced control examples
 
-#### Disable auto mouse on certain layers:   
+#### Disable auto mouse on certain layers:
 
-The auto mouse feature can be disabled any time and this can be helpful if you want to disable the auto mouse feature under certain circumstances such as when particular layers are active. One issue however is the handling of the target layer, it needs to be removed appropriately **before** disabling auto mouse _(see notes under control functions above)_. The following function would disable the auto_mouse feature whenever the layers `_LAYER5` through `_LAYER7` are active as the top most layer _(ignoring target layer)_.   
+The auto mouse feature can be disabled any time and this can be helpful if you want to disable the auto mouse feature under certain circumstances such as when particular layers are active. One issue however is the handling of the target layer, it needs to be removed appropriately **before** disabling auto mouse _(see notes under control functions above)_. The following function would disable the auto_mouse feature whenever the layers `_LAYER5` through `_LAYER7` are active as the top most layer _(ignoring target layer)_.
 
 ```c
 // in keymap.c:
@@ -880,7 +885,7 @@ layer_state_t default_layer_state_set_user(layer_state_t state) {
             auto_mouse_layer_off();
             set_auto_mouse_layer(_MOUSE_LAYER_2);
             break;
-        
+
         default:
             if((AUTO_MOUSE_TARGET_LAYER) == _MOUSE_LAYER_1) break;
             auto_mouse_layer_off();
@@ -890,9 +895,11 @@ layer_state_t default_layer_state_set_user(layer_state_t state) {
 }
 ```
 
-### Use custom keys to control auto mouse:  
-Custom key records could also be created that control the auto mouse feature.   
-The code example below would create a custom key that would toggle the auto mouse feature on and off when pressed while also setting a bool that could be used to disable other code that may turn it on such as the layer code above.   
+### Use custom keys to control auto mouse:
+
+Custom key records could also be created that control the auto mouse feature.
+
+The code example below would create a custom key that would toggle the auto mouse feature on and off when pressed while also setting a bool that could be used to disable other code that may turn it on such as the layer code above.
 
 ```c
 // in config.h:
@@ -921,11 +928,11 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
 
 ## Customize Target Layer Activation
 
-Layer activation can be customized by overwriting the `auto_mouse_activation` function. This function is checked every time `pointing_device_task` is called when inactive and every `AUTO_MOUSE_DEBOUNCE` ms when active, and will evaluate pointing device level conditions that trigger target layer activation. When it returns true, the target layer will be activated barring the usual exceptions _(e.g. delay time has not expired)_.   
+Layer activation can be customized by overwriting the `auto_mouse_activation` function. This function is checked every time `pointing_device_task` is called when inactive and every `AUTO_MOUSE_DEBOUNCE` ms when active, and will evaluate pointing device level conditions that trigger target layer activation. When it returns true, the target layer will be activated barring the usual exceptions _(e.g. delay time has not expired)_.
 
 By default it will return true if any of the `mouse_report` axes `x`,`y`,`h`,`v` are non zero, or if there is any mouse buttons active in `mouse_report`.
 _Note: The Cirque pinnacle track pad already implements a custom activation function that will activate on touchdown as well as movement all of the default conditions, currently this only works for the master side of split keyboards._
- 
+
 | Function                                                   | Description                                                                      |     Return type |
 | :--------------------------------------------------------- | -------------------------------------------------------------------------------- | --------------: |
 | `auto_mouse_activation(report_mouse_t mouse_report)`       | Overwritable function that controls target layer activation (when true)          |          `bool` |
@@ -937,12 +944,12 @@ When using a custom pointing device (overwriting `pointing_device_task`) the fol
 ```c
 bool pointing_device_task(void) {
     //...Custom pointing device task code
-    
+
     // handle automatic mouse layer (needs report_mouse_t as input)
     pointing_device_task_auto_mouse(local_mouse_report);
-    
+
     //...More custom pointing device task code
-    
+
     return pointing_device_send();
 }
 ```

docs/features/repeat_key.md

@@ -5,7 +5,7 @@ Key after tapping the <kbd>Z</kbd> key types another "`z`." This is useful for
 typing doubled letters, like the `z` in "`dazzle`": a double tap on <kbd>Z</kbd>
 can instead be a roll from <kbd>Z</kbd> to <kbd>Repeat</kbd>, which is
 potentially faster and more comfortable. The Repeat Key is also useful for
-hotkeys, like repeating Ctrl + Shift + Right Arrow to select by word. 
+hotkeys, like repeating Ctrl + Shift + Right Arrow to select by word.
 
 Repeat Key remembers mods that were active with the last key press. These mods
 are combined with any additional mods while pressing the Repeat Key. If the last
@@ -49,10 +49,10 @@ reduce firmware size, Alternate Repeat may be disabled by adding in config.h:
 
 The following alternate keys are defined by default. See
 `get_alt_repeat_key_keycode_user()` below for how to change or add to these
-definitions. Where it makes sense, these definitions also include combinations 
+definitions. Where it makes sense, these definitions also include combinations
 with mods, like Ctrl + Left &harr; Ctrl + Right Arrow.
 
-**Navigation** 
+**Navigation**
 
 |Keycodes                           |Description                        |
 |-----------------------------------|-----------------------------------|
@@ -65,7 +65,7 @@ with mods, like Ctrl + Left &harr; Ctrl + Right Arrow.
 |`MS_WHLL` &harr; `MS_WHLR`         | Mouse Wheel Left &harr; Right     |
 |`MS_WHLU` &harr; `MS_WHLD`         | Mouse Wheel Up &harr; Down        |
 
-**Misc** 
+**Misc**
 
 |Keycodes                           |Description                        |
 |-----------------------------------|-----------------------------------|
@@ -73,7 +73,7 @@ with mods, like Ctrl + Left &harr; Ctrl + Right Arrow.
 |`KC_LBRC` &harr; `KC_RBRC`         | `[` &harr; `]`                    |
 |`KC_LCBR` &harr; `KC_RCBR`         | `{` &harr; `}`                    |
 
-**Media** 
+**Media**
 
 |Keycodes                           |Description                        |
 |-----------------------------------|-----------------------------------|
@@ -176,9 +176,9 @@ macro](../feature_macros). This way macros can be used without having to
 dedicate keys to them. The following defines a couple shortcuts.
 
 * Typing <kbd>K</kbd>, <kbd>Alt Repeat</kbd> produces "`keyboard`," with the
-  initial "`k`" typed as usual and the "`eybord`" produced by the macro. 
+  initial "`k`" typed as usual and the "`eybord`" produced by the macro.
 * Typing <kbd>.</kbd>, <kbd>Alt Repeat</kbd> produces "`../`," handy for "up
-  directory" on the shell. Similary, <kbd>.</kbd> types the initial "`.`" and 
+  directory" on the shell. Similarly, <kbd>.</kbd> types the initial "`.`" and
   "`./`" is produced by the macro.
 
 ```c
@@ -290,7 +290,7 @@ By default, pressing the Repeat Key will simply behave as if the last key
 were pressed again. This also works with macro keys with custom handlers,
 invoking the macro again. In case fine-tuning is needed for sensible repetition,
 you can handle how a key is repeated with `get_repeat_key_count()` within
-`process_record_user()`. 
+`process_record_user()`.
 
 The `get_repeat_key_count()` function returns a signed count of times the key
 has been repeated or alternate repeated. When a key is pressed as usual,
@@ -306,16 +306,16 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
             if (get_repeat_key_count() > 0) {
                 // MY_MACRO is being repeated!
                 if (record->event.pressed) {
-                    SEND_STRING("repeat!");    
+                    SEND_STRING("repeat!");
                 }
-            } else {                          
+            } else {
                 // MY_MACRO is being used normally.
-                if (record->event.pressed) {  
+                if (record->event.pressed) {
                     SEND_STRING("macro");
                 }
             }
             return false;
-     
+
         // Other macros...
     }
     return true;
@@ -347,19 +347,19 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
         case MY_MACRO:
             if (get_repeat_key_count() > 0) {        // Repeating.
                 if (record->event.pressed) {
-                    SEND_STRING("repeat!");    
+                    SEND_STRING("repeat!");
                 }
             } else if (get_repeat_key_count() < 0) { // Alternate repeating.
                 if (record->event.pressed) {
                     SEND_STRING("alt repeat!");
                 }
             } else {                                 // Used normally.
-                if (record->event.pressed) {  
+                if (record->event.pressed) {
                     SEND_STRING("macro");
                 }
             }
             return false;
-     
+
         // Other macros...
     }
     return true;
@@ -377,7 +377,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t* record) {
 | `set_last_mods(mods)`          | Set the mods to apply when repeating.                                  |
 | `get_repeat_key_count()`       | Signed count of times the key has been repeated or alternate repeated. |
 | `get_alt_repeat_key_keycode()` | Keycode to be used for alternate repeating.                            |
- 
+
 
 ## Additional "Alternate" keys
 
@@ -437,7 +437,7 @@ static void process_altrep3(uint16_t keycode, uint8_t mods) {
 
 bool process_record_user(uint16_t keycode, keyrecord_t* record) {
     switch (keycode) {
-        case ALTREP2: 
+        case ALTREP2:
             if (record->event.pressed) {
                 process_altrep2(get_last_keycode(), get_last_mods());
             }

docs/features/rgb_matrix.md

@@ -125,13 +125,13 @@ enum rgb_matrix_effects {
     RGB_MATRIX_CYCLE_SPIRAL,        // Full gradient spinning spiral around center of keyboard
     RGB_MATRIX_DUAL_BEACON,         // Full gradient spinning around center of keyboard
     RGB_MATRIX_RAINBOW_BEACON,      // Full tighter gradient spinning around center of keyboard
-    RGB_MATRIX_RAINBOW_PINWHEELS,   // Full dual gradients spinning two halfs of keyboard
+    RGB_MATRIX_RAINBOW_PINWHEELS,   // Full dual gradients spinning two halves of keyboard
     RGB_MATRIX_FLOWER_BLOOMING,     // Full tighter gradient of first half scrolling left to right and second half scrolling right to left
     RGB_MATRIX_RAINDROPS,           // Randomly changes a single key's hue
     RGB_MATRIX_JELLYBEAN_RAINDROPS, // Randomly changes a single key's hue and saturation
-    RGB_MATRIX_HUE_BREATHING,       // Hue shifts up a slight ammount at the same time, then shifts back
-    RGB_MATRIX_HUE_PENDULUM,        // Hue shifts up a slight ammount in a wave to the right, then back to the left
-    RGB_MATRIX_HUE_WAVE,            // Hue shifts up a slight ammount and then back down in a wave to the right
+    RGB_MATRIX_HUE_BREATHING,       // Hue shifts up a slight amount at the same time, then shifts back
+    RGB_MATRIX_HUE_PENDULUM,        // Hue shifts up a slight amount in a wave to the right, then back to the left
+    RGB_MATRIX_HUE_WAVE,            // Hue shifts up a slight amount and then back down in a wave to the right
     RGB_MATRIX_PIXEL_FRACTAL,       // Single hue fractal filled keys pulsing horizontally out to edges
     RGB_MATRIX_PIXEL_FLOW,          // Pulsing RGB flow along LED wiring with random hues
     RGB_MATRIX_PIXEL_RAIN,          // Randomly light keys with random hues
@@ -240,7 +240,7 @@ In order to change the delay of temperature decrease define `RGB_MATRIX_TYPING_H
 
 As heatmap uses the physical position of the leds set in the g_led_config, you may need to tweak the following options to get the best effect for your keyboard. Note the size of this grid is `224x64`.
 
-Limit the distance the effect spreads to surrounding keys. 
+Limit the distance the effect spreads to surrounding keys.
 
 ```c
 #define RGB_MATRIX_TYPING_HEATMAP_SPREAD 40
@@ -365,9 +365,30 @@ These are shorthands to popular colors. The `RGB` ones can be passed to the `set
 These are defined in [`color.h`](https://github.com/qmk/qmk_firmware/blob/master/quantum/color.h). Feel free to add to this list!
 
 
+## Naming
+
+If you wish to be able to use the name of an effect in your code -- say for a display indicator -- then you can enable the function `rgb_matrix_get_mode_name` in the following manner:
+
+In your keymap's `config.h`:
+```c
+#define RGB_MATRIX_MODE_NAME_ENABLE
+```
+
+In your `keymap.c`
+```c
+const char* effect_name = rgb_matrix_get_mode_name(rgb_matrix_get_mode());
+// do something with `effect_name`, like `oled_write_ln(effect_name, false);`
+```
+
+::: info
+`rgb_matrix_get_mode_name()` is not enabled by default as it increases the amount of flash memory used by the firmware based on the number of effects enabled.
+:::
+
+
 ## Additional `config.h` Options {#additional-configh-options}
 
 ```c
+#define RGB_MATRIX_MODE_NAME_ENABLE // enables rgb_matrix_get_mode_name()
 #define RGB_MATRIX_KEYRELEASES // reactive effects respond to keyreleases (instead of keypresses)
 #define RGB_MATRIX_TIMEOUT 0 // number of milliseconds to wait until rgb automatically turns off
 #define RGB_MATRIX_SLEEP // turn off effects when suspended
@@ -385,8 +406,8 @@ These are defined in [`color.h`](https://github.com/qmk/qmk_firmware/blob/master
 #define RGB_MATRIX_VAL_STEP 16 // The value by which to increment the brightness per adjustment action
 #define RGB_MATRIX_SPD_STEP 16 // The value by which to increment the animation speed per adjustment action
 #define RGB_MATRIX_DEFAULT_FLAGS LED_FLAG_ALL // Sets the default LED flags, if none has been set
-#define RGB_MATRIX_SPLIT { X, Y } 	// (Optional) For split keyboards, the number of LEDs connected on each half. X = left, Y = Right.
-                              		// If reactive effects are enabled, you also will want to enable SPLIT_TRANSPORT_MIRROR
+#define RGB_MATRIX_SPLIT { X, Y } // (Optional) For split keyboards, the number of LEDs connected on each half. X = left, Y = Right.
+                                  // If reactive effects are enabled, you also will want to enable SPLIT_TRANSPORT_MIRROR
 #define RGB_TRIGGER_ON_KEYDOWN      // Triggers RGB keypress events on key down. This makes RGB control feel more responsive. This may cause RGB to not function properly on some boards
 ```
 

docs/features/space_cadet.md

@@ -32,7 +32,7 @@ COMMAND_ENABLE = no
 
 ## Configuration
 
-By default Space Cadet assumes a US ANSI layout, but if your layout uses different keys for parentheses, you can redefine them in your `config.h`. In addition, you can redefine the modifier to send on tap, or even send no modifier at all. The new configuration defines bundle all options up into a single define of 3 key codes in this order: the `Modifier` when held or when used with other keys, the `Tap Modifer` sent when tapped (no modifier if `KC_TRNS`), finally the `Keycode` sent when tapped. Now keep in mind, mods from other keys will still apply to the `Keycode` if say `KC_RSFT` is held while tapping `SC_LSPO` key with `KC_TRNS` as the `Tap Modifer`.
+By default Space Cadet assumes a US ANSI layout, but if your layout uses different keys for parentheses, you can redefine them in your `config.h`. In addition, you can redefine the modifier to send on tap, or even send no modifier at all. The new configuration defines bundle all options up into a single define of 3 key codes in this order: the `Modifier` when held or when used with other keys, the `Tap Modifier` sent when tapped (no modifier if `KC_TRNS`), finally the `Keycode` sent when tapped. Now keep in mind, mods from other keys will still apply to the `Keycode` if say `KC_RSFT` is held while tapping `SC_LSPO` key with `KC_TRNS` as the `Tap Modifier`.
 
 |Define          |Default                        |Description                                                                      |
 |----------------|-------------------------------|---------------------------------------------------------------------------------|

docs/features/split_keyboard.md

@@ -1,12 +1,12 @@
-# Split Keyboard 
+# Split Keyboard
 
-Many keyboards in the QMK Firmware repo are "split" keyboards. They use two controllers—one plugging into USB, and the second connected by a serial or an I<sup>2</sup>C connection over a TRRS or similar cable. 
+Many keyboards in the QMK Firmware repo are "split" keyboards. They use two controllers—one plugging into USB, and the second connected by a serial or an I<sup>2</sup>C connection over a TRRS or similar cable.
 
-Split keyboards can have a lot of benefits, but there is some additional work needed to get them enabled.  
+Split keyboards can have a lot of benefits, but there is some additional work needed to get them enabled.
 
-QMK Firmware has a generic implementation that is usable by any board, as well as numerous board specific implementations. 
+QMK Firmware has a generic implementation that is usable by any board, as well as numerous board specific implementations.
 
-For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards. 
+For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards.
 
 ::: warning
 ARM split supports most QMK subsystems when using the 'serial' and 'serial_usart' drivers. I2C slave is currently unsupported.
@@ -29,33 +29,33 @@ Notes:
 
 ## Hardware Configuration
 
-This assumes that you're using two Pro Micro-compatible controllers, and are using TRRS jacks to connect to two halves. 
+This assumes that you're using two Pro Micro-compatible controllers, and are using TRRS jacks to connect to two halves.
 
 ### Required Hardware
 
 Apart from diodes and key switches for the keyboard matrix in each half, you will need 2x TRRS sockets and 1x TRRS cable.
 
-Alternatively, you can use any sort of cable and socket that has at least 3 wires. 
+Alternatively, you can use any sort of cable and socket that has at least 3 wires.
 
 If you want to use I<sup>2</sup>C to communicate between halves, you will need a cable with at least 4 wires and 2x 4.7kΩ pull-up resistors.
 
-#### Considerations 
+#### Considerations
 
-The most commonly used connection is a TRRS cable and jacks.  These provide 4 wires, making them very useful for split keyboards, and are easy to find. 
+The most commonly used connection is a TRRS cable and jacks.  These provide 4 wires, making them very useful for split keyboards, and are easy to find.
 
-However, since one of the wires carries VCC, this means that the boards are not hot pluggable. You should always disconnect the board from USB before unplugging and plugging in TRRS cables, or you can short the controller, or worse. 
+However, since one of the wires carries VCC, this means that the boards are not hot pluggable. You should always disconnect the board from USB before unplugging and plugging in TRRS cables, or you can short the controller, or worse.
 
-Another option is to use phone cables (as in, old school RJ-11/RJ-14 cables). Make sure that you use one that actually supports 4 wires/lanes.  
+Another option is to use phone cables (as in, old school RJ-11/RJ-14 cables). Make sure that you use one that actually supports 4 wires/lanes.
 
-However, USB cables, SATA cables, and even just 4 wires have been known to be used for communication between the controllers. 
+However, USB cables, SATA cables, and even just 4 wires have been known to be used for communication between the controllers.
 
 ::: warning
-Using USB cables for communication between the controllers works just fine, but the connector could be mistaken for a normal USB connection and potentially short out the keyboard, depending on how it's wired.  For this reason, they are not recommended for connecting split keyboards.  
+Using USB cables for communication between the controllers works just fine, but the connector could be mistaken for a normal USB connection and potentially short out the keyboard, depending on how it's wired.  For this reason, they are not recommended for connecting split keyboards.
 :::
 
 ### Serial Wiring
 
-The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka PD0/PD1/PD2/PD3) between the two Pro Micros. 
+The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka PD0/PD1/PD2/PD3) between the two Pro Micros.
 
 ::: tip
 Note that the pin used here is actually set by `SOFT_SERIAL_PIN` below.
@@ -66,7 +66,7 @@ Note that the pin used here is actually set by `SOFT_SERIAL_PIN` below.
 
 ### I<sup>2</sup>C Wiring
 
-The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros. 
+The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros.
 
 The pull-up resistors may be placed on either half. If you wish to use the halves independently, it is also possible to use 4 resistors and have the pull-ups in both halves.
 Note that the total resistance for the connected system should be within spec at 2.2k-10kOhm, with an 'ideal' at 4.7kOhm, regardless of the placement and number.
@@ -75,13 +75,13 @@ Note that the total resistance for the connected system should be within spec at
 
 ## Firmware Configuration
 
-To enable the split keyboard feature, add the following to your `rules.mk`: 
+To enable the split keyboard feature, add the following to your `rules.mk`:
 
 ```make
 SPLIT_KEYBOARD = yes
 ```
 
-If you're using a custom transport (communication method), then you will also need to add: 
+If you're using a custom transport (communication method), then you will also need to add:
 
 ```make
 SPLIT_TRANSPORT = custom
@@ -109,7 +109,7 @@ You can configure the firmware to read a pin on the controller to determine hand
 #define SPLIT_HAND_PIN B7
 ```
 
-This will read the specified pin. By default, if it's high, then the controller assumes it is the left hand, and if it's low, it's assumed to be the right side. 
+This will read the specified pin. By default, if it's high, then the controller assumes it is the left hand, and if it's low, it's assumed to be the right side.
 
 This behaviour can be flipped by adding this to you `config.h` file:
 
@@ -141,10 +141,10 @@ While `MATRIX_MASKED` isn't necessary to use `SPLIT_HAND_MATRIX_GRID` successful
 
 #### Handedness by EEPROM
 
-This method sets the keyboard's handedness by setting a flag in the persistent storage (`EEPROM`).  This is checked when the controller first starts up, and determines what half the keyboard is, and how to orient the keyboard layout. 
+This method sets the keyboard's handedness by setting a flag in the persistent storage (`EEPROM`).  This is checked when the controller first starts up, and determines what half the keyboard is, and how to orient the keyboard layout.
 
 
-To enable this method, add the following to your `config.h` file: 
+To enable this method, add the following to your `config.h` file:
 
 ```c
 #define EE_HANDS
@@ -176,7 +176,7 @@ Some controllers (e.g. Blackpill with DFU compatible bootloader) will need to be
 [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/) can also be used to flash EEPROM handedness files. Place the controller in bootloader mode and select menu option Tools -> EEPROM -> Set Left/Right Hand
 :::
 
-This setting is not changed when re-initializing the EEPROM using the `EE_CLR` key, or using the `eeconfig_init()` function.  However, if you reset the EEPROM outside of the firmware's built in options (such as flashing a file that overwrites the `EEPROM`, like how the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/)'s "Reset EEPROM" button works), you'll need to re-flash the controller with the `EEPROM` files. 
+This setting is not changed when re-initializing the EEPROM using the `EE_CLR` key, or using the `eeconfig_init()` function.  However, if you reset the EEPROM outside of the firmware's built in options (such as flashing a file that overwrites the `EEPROM`, like how the [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/)'s "Reset EEPROM" button works), you'll need to re-flash the controller with the `EEPROM` files.
 
 You can find the `EEPROM` files in the QMK firmware repo, [here](https://github.com/qmk/qmk_firmware/tree/master/quantum/split_common).
 
@@ -208,13 +208,13 @@ Because not every split keyboard is identical, there are a number of additional
 #define USE_I2C
 ```
 
-This configures the use of I<sup>2</sup>C support for split keyboard transport (AVR only).  
+This configures the use of I<sup>2</sup>C support for split keyboard transport (AVR only).
 
 ```c
 #define SOFT_SERIAL_PIN D0
 ```
 
-This sets the pin to be used for serial communication. If you're not using serial, you shouldn't need to define this.  
+This sets the pin to be used for serial communication. If you're not using serial, you shouldn't need to define this.
 
 However, if you are using serial and I<sup>2</sup>C on the board, you will need to set this, and to something other than D0 and D1 (as these are used for I<sup>2</sup>C communication).
 
@@ -235,7 +235,7 @@ If you're having issues with serial communication, you can change this value, as
 #define FORCED_SYNC_THROTTLE_MS 100
 ```
 
-This sets the maximum number of milliseconds before forcing a synchronization of data from master to slave. Under normal circumstances this sync occurs whenever the data _changes_, for safety a data transfer occurs after this number of milliseconds if no change has been detected since the last sync. 
+This sets the maximum number of milliseconds before forcing a synchronization of data from master to slave. Under normal circumstances this sync occurs whenever the data _changes_, for safety a data transfer occurs after this number of milliseconds if no change has been detected since the last sync.
 
 ```c
 #define SPLIT_MAX_CONNECTION_ERRORS 10
@@ -249,7 +249,7 @@ Set to 0 to disable the disconnection check altogether.
 ```
 How long (in milliseconds) the master part should block all connection attempts to the slave after the communication has been flagged as disconnected (see `SPLIT_MAX_CONNECTION_ERRORS` above).
 
-One communication attempt will be allowed everytime this amount of time has passed since the last attempt. If that attempt succeeds, the communication is seen as working again.
+One communication attempt will be allowed every time this amount of time has passed since the last attempt. If that attempt succeeds, the communication is seen as working again.
 
 Set to 0 to disable this throttling of communications while disconnected. This can save you a couple of bytes of firmware size.
 
@@ -280,7 +280,7 @@ This enables syncing of the Host LED status (caps lock, num lock, etc) between b
 #define SPLIT_MODS_ENABLE
 ```
 
-This enables transmitting modifier state (normal, weak, oneshot and oneshot locked) to the non primary side of the split keyboard. The purpose of this feature is to support cosmetic use of modifer state (e.g. displaying status on an OLED screen).
+This enables transmitting modifier state (normal, weak, oneshot and oneshot locked) to the non primary side of the split keyboard. The purpose of this feature is to support cosmetic use of modifier state (e.g. displaying status on an OLED screen).
 
 ```c
 #define SPLIT_WPM_ENABLE
@@ -304,7 +304,7 @@ This enables transmitting the current ST7565 on/off status to the slave side of
 #define SPLIT_POINTING_ENABLE
 ```
 
-This enables transmitting the pointing device status to the master side of the split keyboard. The purpose of this feature is to enable use pointing devices on the slave side. 
+This enables transmitting the pointing device status to the master side of the split keyboard. The purpose of this feature is to enable use pointing devices on the slave side.
 
 ::: warning
 There is additional required configuration for `SPLIT_POINTING_ENABLE` outlined in the [pointing device documentation](pointing_device#split-keyboard-configuration).
@@ -401,7 +401,7 @@ By default, the inbound and outbound data is limited to a maximum of 32 bytes ea
 
 ### Hardware Configuration Options
 
-There are some settings that you may need to configure, based on how the hardware is set up. 
+There are some settings that you may need to configure, based on how the hardware is set up.
 
 ```c
 #define MATRIX_ROW_PINS_RIGHT { <row pins> }
@@ -433,7 +433,7 @@ This option enables synchronization of the RGB Light modes between the controlle
 #define RGBLED_SPLIT { 6, 6 }
 ```
 
-This sets how many LEDs are directly connected to each controller.  The first number is the left side, and the second number is the right side.  
+This sets how many LEDs are directly connected to each controller.  The first number is the left side, and the second number is the right side.
 
 ::: tip
 This setting implies that `RGBLIGHT_SPLIT` is enabled, and will forcibly enable it, if it's not.
@@ -479,7 +479,7 @@ This set the maximum slave timeout when waiting for communication from master wh
 
 Master/slave delegation is made either by detecting voltage on VBUS connection or waiting for USB communication (`SPLIT_USB_DETECT`). Pro Micro boards can use VBUS detection out of the box and be used with or without `SPLIT_USB_DETECT`.
 
-Many ARM boards, but not all, do not support VBUS detection. Because it is common that ARM boards lack VBUS detection, `SPLIT_USB_DETECT` is automatically defined on ARM targets (technically when ChibiOS is targetted).
+Many ARM boards, but not all, do not support VBUS detection. Because it is common that ARM boards lack VBUS detection, `SPLIT_USB_DETECT` is automatically defined on ARM targets (technically when ChibiOS is targeted).
 
 ### Teensy boards
 
@@ -501,7 +501,7 @@ You may need to use the 5V pad from the regulator block above as the pads were t
 
 ## Additional Resources
 
-Nicinabox has a [very nice and detailed guide](https://github.com/nicinabox/lets-split-guide) for the Let's Split keyboard, that covers most everything you need to know, including troubleshooting information. 
+Nicinabox has a [very nice and detailed guide](https://github.com/nicinabox/lets-split-guide) for the Let's Split keyboard, that covers most everything you need to know, including troubleshooting information.
 
 However, the RGB Light section is out of date, as it was written long before the RGB Split code was added to QMK Firmware. Instead, wire each strip up directly to the controller.
 

docs/features/st7565.md

@@ -182,12 +182,12 @@ void st7565_render(void);
 void st7565_set_cursor(uint8_t col, uint8_t line);
 
 // Advances the cursor to the next page, writing ' ' if true
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void st7565_advance_page(bool clearPageRemainder);
 
 // Moves the cursor forward 1 character length
 // Advance page if there is not enough room for the next character
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void st7565_advance_char(void);
 
 // Writes a single character to the buffer at current cursor position

docs/features/stenography.md

@@ -4,6 +4,14 @@
 
 The [Open Steno Project](https://www.openstenoproject.org/) has built an open-source program called Plover that provides real-time translation of steno strokes into words and commands. It has an established dictionary and supports
 
+## Steno Support in QMK
+
+There are three ways that QMK keyboards can support steno, with varying degrees of configuration required:
+
+1. Plover with [Arpeggiation](https://plover.wiki/index.php/Glossary#Arpeggiate) requires no changes to any keyboard and is supported by QMK as well as any other QWERTY keyboard.
+2. Plover with [NKRO](https://plover.wiki/index.php/Using_a_standard_keyboard_with_Plover#NKRO). If your keyboard supports NKRO in hardware and you have NKRO enabled as a USB endpoint, you can chord with the keyboard. Many devices will arrive stock like this and will require no changes.
+3. Steno Machine Protocols.  This requires the most configuration, but this has the advantage of allowing you to use your keyboard keys normally (either on another layer or another piece of hardware) without enabling and disabling your steno software.
+
 ## Plover with QWERTY Keyboard {#plover-with-qwerty-keyboard}
 
 Plover can work with any standard QWERTY keyboard, although it is more efficient if the keyboard supports NKRO (n-key rollover) to allow Plover to see all the pressed keys at once. An example keymap for Plover can be found in `planck/keymaps/default`. Switching to the `PLOVER` layer adjusts the position of the keyboard to support the number bar.
@@ -14,14 +22,14 @@ You may also need to adjust your layout, either in QMK or in Plover, if you have
 
 ## Plover with Steno Protocol {#plover-with-steno-protocol}
 
-Plover also understands the language of several steno machines. QMK can speak a couple of these languages: TX Bolt and GeminiPR. An example layout can be found in `planck/keymaps/steno`.
+Plover also understands the language of several steno machines. QMK can speak a couple of these languages: TX Bolt and GeminiPR. An example layout can be found in `splitography/keymaps/default`.
 
 When QMK speaks to Plover over a steno protocol, Plover will not use the keyboard as input. This means that you can switch back and forth between a standard keyboard and your steno keyboard, or even switch layers from Plover to standard and back without needing to activate/deactivate Plover.
 
 In this mode, Plover expects to speak with a steno machine over a serial port so QMK will present itself to the operating system as a virtual serial port in addition to a keyboard.
 
 ::: info
-Note: Due to hardware limitations, you might not be able to run both a virtual serial port and mouse emulation at the same time.
+Due to hardware limitations, you might not be able to run both a virtual serial port and other features (mouse keys, NKRO, or MIDI support) at the same time. You will likely encounter a compile time error if this is the case. Disable those other features as necessary.
 :::
 
 ::: warning
@@ -94,7 +102,7 @@ STENO_ENABLE = yes
 STENO_PROTOCOL = all
 ```
 
-If you want to switch protocols programatically, as part of a custom macro for example, don't use `tap_code(QK_STENO_*)`, as `tap_code` only supports [basic keycodes](../keycodes_basic). Instead, you should use `steno_set_mode(STENO_MODE_*)`, whose valid arguments are `STENO_MODE_BOLT` and `STENO_MODE_GEMINI`.
+If you want to switch protocols programmatically, as part of a custom macro for example, don't use `tap_code(QK_STENO_*)`, as `tap_code` only supports [basic keycodes](../keycodes_basic). Instead, you should use `steno_set_mode(STENO_MODE_*)`, whose valid arguments are `STENO_MODE_BOLT` and `STENO_MODE_GEMINI`.
 
 The default protocol is Gemini PR but the last protocol used is stored in non-volatile memory so QMK will remember your choice between reboots of your keyboard — assuming that your keyboard features (emulated) EEPROM.
 
@@ -156,7 +164,7 @@ At the end of this scenario given as an example, `chord` would have five bits se
 ## Keycode Reference {#keycode-reference}
 
 ::: info
-Note: TX Bolt does not support the full set of keys. The TX Bolt implementation in QMK will map the GeminiPR keys to the nearest TX Bolt key so that one key map will work for both.
+TX Bolt does not support the full set of keys. The TX Bolt implementation in QMK will map the GeminiPR keys to the nearest TX Bolt key so that one key map will work for both.
 :::
 
 |GeminiPR|TX Bolt|Steno Key|

docs/getting_started_introduction.md

@@ -19,8 +19,8 @@ Within the folder `keyboards`, its subfolder `handwired` and its vendor and manu
 * `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`.
 * `info.json`: The file used for setting layout for QMK Configurator. See [Configurator Support](reference_configurator_support) for more information.
 * `readme.md`: A brief overview of the keyboard.
-* `<keyboardName>.h`: This file is where the keyboard layout is defined against the keyboard's switch matrix.
-* `<keyboardName>.c`: This file is where you can find custom code for the keyboard.  
+* `<keyboard>.h`: This file is where the keyboard layout is defined against the keyboard's switch matrix.
+* `<keyboard>.c`: This file is where you can find custom code for the keyboard.  
 
 For more information on project structure, see [QMK Keyboard Guidelines](hardware_keyboard_guidelines).
 

docs/getting_started_make_guide.md

@@ -1,8 +1,8 @@
 # More Detailed `make` Instructions
 
-The full syntax of the `make` command is `<keyboard_folder>:<keymap>:<target>`, where:
+The full syntax of the `make` command is `<keyboard>:<keymap>:<target>`, where:
 
-* `<keyboard_folder>` is the path of the keyboard, for example `planck`
+* `<keyboard>` is the path of the keyboard, for example `planck`
   * Use `all` to compile all keyboards
   * Specify the path to compile a revision, for example `planck/rev4` or `planck/rev3`
   * If the keyboard doesn't have any folders, it can be left out

docs/hand_wire.md

@@ -162,7 +162,7 @@ The pins you'll absolutely have to avoid, as with any controller, are: GND, VCC,
 
 Cut wires to the length of the distance from the a point on each column/row to the controller.  You can solder anywhere along the row, as long as it's after the diode - soldering before the diode (on the keyswitch side) will cause that row not to work.
 
-Ribbon cable can be used to keep this extra tidy.  You may also want to consider routing the wires beneath the exisiting columns/rows.
+Ribbon cable can be used to keep this extra tidy.  You may also want to consider routing the wires beneath the existing columns/rows.
 
 <img src="https://i.imgur.com/z2QlKfB.jpg" alt="Ribbon Cable" width="350"/>
 
@@ -188,7 +188,7 @@ qmk import-kbfirmware /path/to/export.json
 For example:
 
 ```
-$ qmk import-kbfirmware ~/Downloads/gh62.json 
+$ qmk import-kbfirmware ~/Downloads/gh62.json
 Ψ Importing gh62.json.
 
 ⚠ Support here is basic - Consider using 'qmk new-keyboard' instead
@@ -227,16 +227,16 @@ If you've done all of these things, keep in mind that sometimes you might have h
 
 ## Finishing up
 
-Once you have confirmed that the keyboard is working, if you have used a seperate (non handwire specific) controller you will want to secure it in place.  This can be done in many different ways e.g. hot glue, double sided sticky tape, 3D printed caddy, electrical tape.
+Once you have confirmed that the keyboard is working, if you have used a separate (non handwire specific) controller you will want to secure it in place.  This can be done in many different ways e.g. hot glue, double sided sticky tape, 3D printed caddy, electrical tape.
 
-If you found this fullfilling you could experiment by adding additional features such as [in switch LEDs](https://geekhack.org/index.php?topic=94258.0), [in switch RGB](https://www.reddit.com/r/MechanicalKeyboards/comments/5s1l5u/photoskeyboard_science_i_made_a_handwired_rgb/), [RGB underglow](https://medium.com/@DavidNZ/hand-wired-custom-keyboard-cdd14429c7b3#.7a1ovebsk) or even an [OLED display!](https://www.reddit.com/r/olkb/comments/5zy7og/adding_ssd1306_oled_display_to_your_build/) 
+If you found this fulfilling you could experiment by adding additional features such as [in switch LEDs](https://geekhack.org/index.php?topic=94258.0), [in switch RGB](https://www.reddit.com/r/MechanicalKeyboards/comments/5s1l5u/photoskeyboard_science_i_made_a_handwired_rgb/), [RGB underglow](https://medium.com/@DavidNZ/hand-wired-custom-keyboard-cdd14429c7b3#.7a1ovebsk) or even an [OLED display!](https://www.reddit.com/r/olkb/comments/5zy7og/adding_ssd1306_oled_display_to_your_build/)
 
 There are a lot of possibilities inside the firmware - explore [the documentation](/) for a full feature list, and dive into the different keyboards to see how people use all of them. You can always stop by [the OLKB subreddit](https://reddit.com/r/olkb) or [QMK Discord](https://discord.gg/qmk) for help!
 
 ## Links to Other Guides
 
 - [matt3o's step by step guide (BrownFox build)](https://deskthority.net/viewtopic.php?f=7&t=6050) also his [website](https://matt3o.com/hand-wiring-a-custom-keyboard/) and [video guide](https://www.youtube.com/watch?v=LVzpsjFWPP4)
-- [Cribbit's "Modern hand wiring guide - stronger, cleaner, easier"](https://geekhack.org/index.php?topic=87689.0) 
+- [Cribbit's "Modern hand wiring guide - stronger, cleaner, easier"](https://geekhack.org/index.php?topic=87689.0)
 - [Sasha Solomon's "Building my first Keyboard"](https://medium.com/@sachee/building-my-first-keyboard-and-you-can-too-512c0f8a4c5f)
 - [RoastPotatoes' "How to hand wire a Planck"](https://blog.roastpotatoes.co/guide/2015/11/04/how-to-handwire-a-planck/)
 - [Masterzen's "Handwired keyboard build log"](https://www.masterzen.fr/2018/12/16/handwired-keyboard-build-log-part-1/)

docs/hardware_drivers.md

@@ -24,7 +24,7 @@ Support for WS2811/WS2812{a,b,c} LED's. For more information see the [RGB Light]
 
 ## IS31FL3731
 
-Support for up to 2 drivers. Each driver impliments 2 charlieplex matrices to individually address LEDs using I2C. This allows up to 144 same color LEDs or 32 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](features/rgb_matrix) page.
+Support for up to 2 drivers. Each driver implements 2 charlieplex matrices to individually address LEDs using I2C. This allows up to 144 same color LEDs or 32 RGB LEDs. For more information on how to setup the driver see the [RGB Matrix](features/rgb_matrix) page.
 
 ## IS31FL3733
 

docs/hardware_keyboard_guidelines.md

@@ -44,7 +44,11 @@ QMK uses sub-folders both for organization and to share code between revisions o
 qmk_firmware/keyboards/top_folder/sub_1/sub_2/sub_3/sub_4
 ```
 
-If a sub-folder has a `rules.mk` file it will be considered a compilable keyboard. It will be available in QMK Configurator and tested with `make all`. If you are using a folder to organize several keyboards from the same maker you should not have a `rules.mk` file.
+If a sub-folder has a `keyboard.json` file it will be considered a compilable keyboard. It will be available in QMK Configurator and tested with `make all`. If you are using a folder to organize several keyboards from the same maker you should not have a `keyboard.json` file.
+
+::: tip
+When configuring a keyboard with multiple revisions (like the `clueboard/66` example below), an `info.json` file at the top keyboard level (eg. `clueboard/66`) should be used for configuration shared between revisions. Then `keyboard.json` in each revision directory containing revision-specific configuration, and indicating a buildable keyboard.
+:::
 
 Example:
 
@@ -52,35 +56,49 @@ Clueboard uses sub-folders for both purposes, organization and keyboard revision
 
 * [`qmk_firmware`](https://github.com/qmk/qmk_firmware/tree/master)
   * [`keyboards`](https://github.com/qmk/qmk_firmware/tree/master/keyboards)
-    * [`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard)  ← This is the organization folder, there's no `rules.mk` file
-      * [`60`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/60)  ← This is a compilable keyboard, it has a `rules.mk` file
-      * [`66`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66) ← This is also compilable- it uses `DEFAULT_FOLDER` to specify `rev3` as the default revision
+    * [`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard)  ← This is the organization folder, there's no `keyboard.json` file
+      * [`60`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/60)  ← This is a compilable keyboard - it has a `keyboard.json` file
+      * [`66`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66) ← This is not a compilable keyboard - a revision must be specified
         * [`rev1`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev1) ← compilable: `make clueboard/66/rev1`
         * [`rev2`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev2) ← compilable: `make clueboard/66/rev2`
-        * [`rev3`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev3) ← compilable: `make clueboard/66/rev3` or `make clueboard/66`
+        * [`rev3`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard/66/rev3) ← compilable: `make clueboard/66/rev3`
 
 ## Keyboard Folder Structure
 
-Your keyboard should be located in `qmk_firmware/keyboards/` and the folder name should be your keyboard's name as described in the previous section. Inside this folder should be several files:
+Your keyboard should be located in `qmk_firmware/keyboards/` and the folder name should be your keyboard's name as described in the previous section. Inside this folder should be several files, some of which are optional:
 
 * `readme.md`
-* `info.json`
+* `keyboard.json` (or `info.json`)
 * `config.h`
 * `rules.mk`
-* `<keyboard_name>.c`
-* `<keyboard_name>.h`
+* `<keyboard>.c`
+* `<keyboard>.h`
 
 ### `readme.md`
 
 All projects need to have a `readme.md` file that explains what the keyboard is, who made it and where it's available. If applicable, it should also contain links to more information, such as the maker's website. Please follow the [published template](documentation_templates#keyboard-readmemd-template).
 
-### `info.json`
+### `keyboard.json`/`info.json`
 
-This file is used by the [QMK API](https://github.com/qmk/qmk_api). It contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. You can also set metadata here. For more information see the [reference page](reference_info_json).
+The `keyboard.json` file is necessary for your keyboard (or keyboard revision) to be considered a buildable keyboard. The same content is valid in both `info.json` and `keyboard.json`. For the available configuration options of this file, see the [reference page](reference_info_json). This file is also used by the [QMK API](https://github.com/qmk/qmk_api), and by the [QMK Configurator](https://config.qmk.fm/) to display a representation of the available layouts of your keyboard.
+
+Additionally, this is where layouts available on your keyboard are defined. If you only have a single layout, it should be named `LAYOUT`. When defining multiple layouts, you should have a base layout, named `LAYOUT_all`, that supports all possible switch positions in your matrix, even if that layout is impossible to build physically. This is the layout that should be used in the `default` keymap. You should then have additional keymaps named `default_<layout>` that configure keymaps for the other layouts. Layout macro names are entirely lowercase, except for the prefix of `LAYOUT`.
+
+As an example, if you have a 60% PCB that supports ANSI and ISO, you might define the following layouts and keymaps:
+
+| Layout Name | Keymap Name  | Description                              |
+|-------------|--------------|------------------------------------------|
+| LAYOUT_all  | default      | A layout that supports both ISO and ANSI |
+| LAYOUT_ansi | default_ansi | An ANSI layout                           |
+| LAYOUT_iso  | default_iso  | An ISO layout                            |
+
+::: tip
+Providing only `LAYOUT_all` is invalid, as is providing a `LAYOUT` when multiple layouts are present.
+:::
 
 ### `config.h`
 
-All projects need to have a `config.h` file that sets things like the matrix size, product name, USB VID/PID, description and other settings. In general, use this file to set essential information and defaults for your keyboard that will always work.
+Some projects will need to have a `config.h` that configures parameters that are not possible to be set in `keyboard.json`. This is not a required file.
 
 The `config.h` files can also be placed in sub-folders, and the order in which they are read is as follows:
 
@@ -138,7 +156,7 @@ If you define options using `post_config.h` as in the above example, you should
 
 ### `rules.mk`
 
-The presence of this file means that the folder is a keyboard target and can be used in `make` commands. This is where you setup the build environment for your keyboard and configure the default set of features.
+This file is typically used to configure hardware drivers (eg. pointing device), or to include additional C files in compilation. This is not a required file.
 
 The `rules.mk` file can also be placed in a sub-folder, and its reading order is as follows:
 
@@ -185,9 +203,9 @@ The `post_rules.mk` file can interpret `features` of a keyboard-level before `co
 See `build_keyboard.mk` and `common_features.mk` for more details.
 :::
 
-### `<keyboard_name.c>`
+### `<keyboard>.c`
 
-This is where you will write custom code for your keyboard. Typically you will write code to initialize and interface with the hardware in your keyboard. If your keyboard consists of only a key matrix with no LEDs, speakers, or other auxiliary hardware this file can be blank.
+This file should contain C code required for the functionality of your keyboard, for example hardware initialisation code, OLED display code, and so on. This file should only contain code necessary for the keyboard to work, and *not* things that should be left to the end user to configure in their keymap. This file is automatically included in compilation if it exists. This is not a required file.
 
 The following functions are typically defined in this file:
 
@@ -196,33 +214,13 @@ The following functions are typically defined in this file:
 * `bool process_record_kb(uint16_t keycode, keyrecord_t *record)`
 * `bool led_update_kb(led_t led_state)`
 
-### `<keyboard_name.h>`
+### `<keyboard>.h`
 
-This file is used to define the matrix for your keyboard. You should define at least one C macro which translates an array into a matrix representing the physical switch matrix for your keyboard. If it's possible to build your keyboard with multiple layouts you should define additional macros.
-
-If you have only a single layout you should call this macro `LAYOUT`.
-
-When defining multiple layouts you should have a base layout, named `LAYOUT_all`, that supports all possible switch positions on your matrix, even if that layout is impossible to build physically. This is the macro you should use in your `default` keymap. You should then have additional keymaps named `default_<layout>` that use your other layout macros. This will make it easier for people to use the layouts you define.
-
-Layout macro names are entirely lowercase, except for the word `LAYOUT` at the front.
-
-As an example, if you have a 60% PCB that supports ANSI and ISO you might define the following layouts and keymaps:
-
-| Layout Name | Keymap Name | Description |
-|-------------|-------------|-------------|
-| LAYOUT_all | default | A layout that supports both ISO and ANSI |
-| LAYOUT_ansi | default_ansi | An ANSI layout |
-| LAYOUT_iso | default_iso | An ISO layout |
-
-::: tip
-Providing only `LAYOUT_all` is invalid - especially when implementing the additional layouts within 3rd party tooling.
-:::
+This file can contain function prototypes for custom functions and other header file code utilised by `<keyboard>.c`. The `<keyboard>.c` file should include this file. This is not a required file.
 
 ## Image/Hardware Files
 
-In an effort to keep the repo size down we're no longer accepting binary files of any format, with few exceptions. Hosting them elsewhere (such as <https://imgur.com>) and linking them in the `readme.md` is preferred.
-
-Hardware files (such as plates, cases, pcb) can be contributed to the [qmk.fm repo](https://github.com/qmk/qmk.fm) and they will be made available on [qmk.fm](https://qmk.fm). Downloadable files are stored in `/<keyboard>/` (name follows the same format as above) which are served at `https://qmk.fm/<keyboard>/`, and pages are generated from `/_pages/<keyboard>/` which are served at the same location (.md files are generated into .html files through Jekyll). Check out the `lets_split` folder for an example.
+In an effort to keep the repo size down we do not accept binary files of any format, with few exceptions. Hosting them elsewhere (such as <https://imgur.com>) and linking them in the `readme.md` is preferred. Hardware files such as plates, cases, and PCBs can be published in a personal repository or elsewhere, and linked to by your keyboard's `readme.md` file.
 
 ## Keyboard Defaults
 
@@ -232,8 +230,6 @@ Given the amount of functionality that QMK exposes it's very easy to confuse new
 
 [Magic Keycodes](keycodes_magic) and [Command](features/command) are two related features that allow a user to control their keyboard in non-obvious ways. We recommend you think long and hard about if you're going to enable either feature, and how you will expose this functionality. Keep in mind that users who want this functionality can enable it in their personal keymaps without affecting all the novice users who may be using your keyboard as their first programmable board.
 
-By far the most common problem new users encounter is accidentally triggering Bootmagic while they're plugging in their keyboard. They're holding the keyboard by the bottom, unknowingly pressing in alt and spacebar, and then they find that these keys have been swapped on them. We recommend leaving this feature disabled by default, but if you do turn it on consider setting `BOOTMAGIC_KEY_SALT` to a key that is hard to press while plugging your keyboard in.
-
 If your keyboard does not have 2 shift keys you should provide a working default for `IS_COMMAND`, even when you have set `COMMAND_ENABLE = no`. This will give your users a default to conform to if they do enable Command.
 
 ## Custom Keyboard Programming
@@ -242,7 +238,7 @@ As documented on [Customizing Functionality](custom_quantum_functions) you can d
 
 ## Non-Production/Handwired Projects
 
-We're happy to accept any project that uses QMK, including prototypes and handwired ones, but we have a separate `/keyboards/handwired/` folder for them, so the main `/keyboards/` folder doesn't get overcrowded. If a prototype project becomes a production project at some point in the future, we'd be happy to move it to the main `/keyboards/` folder!
+We're happy to accept any project that uses QMK, including handwired ones, but we have a separate `/keyboards/handwired/` folder for them, so the main `/keyboards/` folder doesn't get overcrowded. If a prototype project becomes a production project at some point in the future, we'd be happy to move it to the main `/keyboards/` folder!
 
 ## Warnings as Errors
 

docs/isp_flashing_guide.md

@@ -220,14 +220,18 @@ This bootloader is primarily for keyboards originally designed for the PS2AVRGB
 
 USBaspLoader is a bootloader based on V-USB that emulates a hardware USBasp device. It runs on ATmega32A and ATmega328P MCUs.
 
-Precompiled `.hex` files are generally not available, but you can compile it yourself by setting up the QMK environment and following Coseyfannitutti's guide for the appropriate MCU:
+Precompiled `.hex` files are generally not available, but you can compile it yourself by setting up the QMK environment and cloning the appropriate branch of Coseyfannitutti's USBaspLoader fork:
 
-|MCU                                                                                  |Low   |High  |Extended|USB ID     |
-|-------------------------------------------------------------------------------------|------|------|--------|-----------|
-|[ATmega32A](https://github.com/coseyfannitutti/discipline/tree/master/doc/bootloader)|`0x1F`|`0xC0`|*n/a*   |`16C0:05DC`|
-|[ATmega328P](https://github.com/coseyfannitutti/discipad/tree/master/doc/bootloader) |`0xD7`|`0xD0`|`0x04`  |`16C0:05DC`|
+|MCU                                                                          |Low   |High  |Extended|USB ID     |
+|-----------------------------------------------------------------------------|------|------|--------|-----------|
+|[ATmega32A](https://github.com/coseyfannitutti/USBaspLoader/tree/atmega32a)  |`0x1F`|`0xC0`|*n/a*   |`16C0:05DC`|
+|[ATmega328P](https://github.com/coseyfannitutti/USBaspLoader/tree/atmega328p)|`0xD7`|`0xD0`|`0x04`  |`16C0:05DC`|
 
-Note that some boards may have their own specialized build of this bootloader in a separate repository. This will usually be linked to in the board's readme.
+From there, simply `cd` to the `firmware/` directory and run `make`, which should produce a file called `main.hex`.
+
+:::tip
+Some boards may have their own specialized build of this bootloader in a separate repository. This will usually be linked to in the board's readme.
+:::
 
 ## Flashing the Bootloader
 

docs/keycodes.md

@@ -657,38 +657,38 @@ See also: [Mouse Keys](features/mouse_keys)
 
 See also: [Modifier Keys](feature_advanced_keycodes#modifier-keys)
 
-|Key       |Aliases                           |Description                                                        |
-|----------|----------------------------------|-------------------------------------------------------------------|
-|`LCTL(kc)`|`C(kc)`                           |Hold Left Control and press `kc`                                   |
-|`LSFT(kc)`|`S(kc)`                           |Hold Left Shift and press `kc`                                     |
-|`LALT(kc)`|`A(kc)`, `LOPT(kc)`               |Hold Left Alt and press `kc`                                       |
-|`LGUI(kc)`|`G(kc)`, `LCMD(kc)`, `LWIN(kc)`   |Hold Left GUI and press `kc`                                       |
-|`LCS(kc)` |                                  |Hold Left Control and Left Shift and press `kc`                    |
-|`LCA(kc)` |                                  |Hold Left Control and Left Alt and press `kc`                      |
-|`LCG(kc)` |                                  |Hold Left Control and Left GUI and press `kc`                      |
-|`LSA(kc)` |                                  |Hold Left Shift and Left Alt and press `kc`                        |
-|`LSG(kc)` |`SGUI(kc)`, `SCMD(kc)`, `SWIN(kc)`|Hold Left Shift and Left GUI and press `kc`                        |
-|`LAG(kc)` |                                  |Hold Left Alt and Left GUI and press `kc`                          |
-|`LCSG(kc)`|                                  |Hold Left Control, Left Shift and Left GUI and press `kc`          |
-|`LCAG(kc)`|                                  |Hold Left Control, Left Alt and Left GUI and press `kc`            |
-|`LSAG(kc)`|                                  |Hold Left Shift, Left Alt and Left GUI and press `kc`              |
-|`RCTL(kc)`|                                  |Hold Right Control and press `kc`                                  |
-|`RSFT(kc)`|                                  |Hold Right Shift and press `kc`                                    |
-|`RALT(kc)`|`ROPT(kc)`, `ALGR(kc)`            |Hold Right Alt and press `kc`                                      |
-|`RGUI(kc)`|`RCMD(kc)`, `RWIN(kc)`            |Hold Right GUI and press `kc`                                      |
-|`RCS(kc)` |                                  |Hold Right Control and Right Shift and press `kc`                  |
-|`RCA(kc)` |                                  |Hold Right Control and Right Alt and press `kc`                    |
-|`RCG(kc)` |                                  |Hold Right Control and Right GUI and press `kc`                    |
-|`RSA(kc)` |`SAGR(kc)`                        |Hold Right Shift and Right Alt and press `kc`                      |
-|`RSG(kc)` |                                  |Hold Right Shift and Right GUI and press `kc`                      |
-|`RAG(kc)` |                                  |Hold Right Alt and Right GUI and press `kc`                        |
-|`RCSG(kc)`|                                  |Hold Right Control, Right Shift and Right GUI and press `kc`       |
-|`RCAG(kc)`|                                  |Hold Right Control, Right Alt and Right GUI and press `kc`         |
-|`RSAG(kc)`|                                  |Hold Right Shift, Right Alt and Right GUI and press `kc`           |
-|`MEH(kc)` |                                  |Hold Left Control, Left Shift and Left Alt and press `kc`          |
-|`HYPR(kc)`|                                  |Hold Left Control, Left Shift, Left Alt and Left GUI and press `kc`|
-|`KC_MEH`  |                                  |Left Control, Left Shift and Left Alt                              |
-|`KC_HYPR` |                                  |Left Control, Left Shift, Left Alt and Left GUI                    |
+|Key       |Aliases                        |Description                                                        |
+|----------|-------------------------------|-------------------------------------------------------------------|
+|`LCTL(kc)`|`C(kc)`                        |Hold Left Control and press `kc`                                   |
+|`LSFT(kc)`|`S(kc)`                        |Hold Left Shift and press `kc`                                     |
+|`LALT(kc)`|`A(kc)`, `LOPT(kc)`            |Hold Left Alt and press `kc`                                       |
+|`LGUI(kc)`|`G(kc)`, `LCMD(kc)`, `LWIN(kc)`|Hold Left GUI and press `kc`                                       |
+|`LCS(kc)` |                               |Hold Left Control and Left Shift and press `kc`                    |
+|`LCA(kc)` |                               |Hold Left Control and Left Alt and press `kc`                      |
+|`LCG(kc)` |                               |Hold Left Control and Left GUI and press `kc`                      |
+|`LSA(kc)` |                               |Hold Left Shift and Left Alt and press `kc`                        |
+|`LSG(kc)` |                               |Hold Left Shift and Left GUI and press `kc`                        |
+|`LAG(kc)` |                               |Hold Left Alt and Left GUI and press `kc`                          |
+|`LCSG(kc)`|                               |Hold Left Control, Left Shift and Left GUI and press `kc`          |
+|`LCAG(kc)`|                               |Hold Left Control, Left Alt and Left GUI and press `kc`            |
+|`LSAG(kc)`|                               |Hold Left Shift, Left Alt and Left GUI and press `kc`              |
+|`RCTL(kc)`|                               |Hold Right Control and press `kc`                                  |
+|`RSFT(kc)`|                               |Hold Right Shift and press `kc`                                    |
+|`RALT(kc)`|`ROPT(kc)`, `ALGR(kc)`         |Hold Right Alt and press `kc`                                      |
+|`RGUI(kc)`|`RCMD(kc)`, `RWIN(kc)`         |Hold Right GUI and press `kc`                                      |
+|`RCS(kc)` |                               |Hold Right Control and Right Shift and press `kc`                  |
+|`RCA(kc)` |                               |Hold Right Control and Right Alt and press `kc`                    |
+|`RCG(kc)` |                               |Hold Right Control and Right GUI and press `kc`                    |
+|`RSA(kc)` |                               |Hold Right Shift and Right Alt and press `kc`                      |
+|`RSG(kc)` |                               |Hold Right Shift and Right GUI and press `kc`                      |
+|`RAG(kc)` |                               |Hold Right Alt and Right GUI and press `kc`                        |
+|`RCSG(kc)`|                               |Hold Right Control, Right Shift and Right GUI and press `kc`       |
+|`RCAG(kc)`|                               |Hold Right Control, Right Alt and Right GUI and press `kc`         |
+|`RSAG(kc)`|                               |Hold Right Shift, Right Alt and Right GUI and press `kc`           |
+|`MEH(kc)` |                               |Hold Left Control, Left Shift and Left Alt and press `kc`          |
+|`HYPR(kc)`|                               |Hold Left Control, Left Shift, Left Alt and Left GUI and press `kc`|
+|`KC_MEH`  |                               |Left Control, Left Shift and Left Alt                              |
+|`KC_HYPR` |                               |Left Control, Left Shift, Left Alt and Left GUI                    |
 
 ## Mod-Tap Keys {#mod-tap-keys}
 
@@ -705,7 +705,7 @@ See also: [Mod-Tap](mod_tap)
 |`LCA_T(kc)`  |                                                                 |Left Control and Left Alt when held, `kc` when tapped                      |
 |`LCG_T(kc)`  |                                                                 |Left Control and Left GUI when held, `kc` when tapped                      |
 |`LSA_T(kc)`  |                                                                 |Left Shift and Left Alt when held, `kc` when tapped                        |
-|`LSG_T(kc)`  |`SGUI_T(kc)`, `SCMD_T(kc)`, `SWIN_T(kc)`                         |Left Shift and Left GUI when held, `kc` when tapped                        |
+|`LSG_T(kc)`  |                                                                 |Left Shift and Left GUI when held, `kc` when tapped                        |
 |`LAG_T(kc)`  |                                                                 |Left Alt and Left GUI when held, `kc` when tapped                          |
 |`LCSG_T(kc)` |                                                                 |Left Control, Left Shift and Left GUI when held, `kc` when tapped          |
 |`LCAG_T(kc)` |                                                                 |Left Control, Left Alt and Left GUI when held, `kc` when tapped            |
@@ -717,14 +717,14 @@ See also: [Mod-Tap](mod_tap)
 |`RCS_T(kc)`  |                                                                 |Right Control and Right Shift when held, `kc` when tapped                  |
 |`RCA_T(kc)`  |                                                                 |Right Control and Right Alt when held, `kc` when tapped                    |
 |`RCG_T(kc)`  |                                                                 |Right Control and Right GUI when held, `kc` when tapped                    |
-|`RSA_T(kc)`  |`SAGR_T(kc)`                                                     |Right Shift and Right Alt when held, `kc` when tapped                      |
+|`RSA_T(kc)`  |                                                                 |Right Shift and Right Alt when held, `kc` when tapped                      |
 |`RSG_T(kc)`  |                                                                 |Right Shift and Right GUI when held, `kc` when tapped                      |
 |`RAG_T(kc)`  |                                                                 |Right Alt and Right GUI when held, `kc` when tapped                        |
 |`RCSG_T(kc)` |                                                                 |Right Control, Right Shift and Right GUI when held, `kc` when tapped       |
 |`RCAG_T(kc)` |                                                                 |Right Control, Right Alt and Right GUI when held, `kc` when tapped         |
 |`RSAG_T(kc)` |                                                                 |Right Shift, Right Alt and Right GUI when held, `kc` when tapped           |
 |`MEH_T(kc)`  |                                                                 |Left Control, Left Shift and Left Alt when held, `kc` when tapped          |
-|`HYPR_T(kc)` |`ALL_T(kc)`                                                      |Left Control, Left Shift, Left Alt and Left GUI when held, `kc` when tapped|
+|`HYPR_T(kc)` |                                                                 |Left Control, Left Shift, Left Alt and Left GUI when held, `kc` when tapped|
 
 ## Tapping Term Keys {#tapping-term-keys}
 

docs/mod_tap.md

@@ -37,7 +37,7 @@ For convenience, QMK includes some Mod-Tap shortcuts to make common combinations
 |`LCA_T(kc)` |                                                                 |Left Control and Left Alt when held, `kc` when tapped                                  |
 |`LCG_T(kc)` |                                                                 |Left Control and Left GUI when held, `kc` when tapped                                  |
 |`LSA_T(kc)` |                                                                 |Left Shift and Left Alt when held, `kc` when tapped                                    |
-|`LSG_T(kc)` |`SGUI_T(kc)`, `SCMD_T(kc)`, `SWIN_T(kc)`                         |Left Shift and Left GUI when held, `kc` when tapped                                    |
+|`LSG_T(kc)` |                                                                 |Left Shift and Left GUI when held, `kc` when tapped                                    |
 |`LAG_T(kc)` |                                                                 |Left Alt and Left GUI when held, `kc` when tapped                                      |
 |`LCSG_T(kc)`|                                                                 |Left Control, Left Shift and Left GUI when held, `kc` when tapped                      |
 |`LCAG_T(kc)`|                                                                 |Left Control, Left Alt and Left GUI when held, `kc` when tapped                        |
@@ -49,14 +49,14 @@ For convenience, QMK includes some Mod-Tap shortcuts to make common combinations
 |`RCS_T(kc)` |                                                                 |Right Control and Right Shift when held, `kc` when tapped                              |
 |`RCA_T(kc)` |                                                                 |Right Control and Right Alt when held, `kc` when tapped                                |
 |`RCG_T(kc)` |                                                                 |Right Control and Right GUI when held, `kc` when tapped                                |
-|`RSA_T(kc)` |`SAGR_T(kc)`                                                     |Right Shift and Right Alt when held, `kc` when tapped                                  |
+|`RSA_T(kc)` |                                                                 |Right Shift and Right Alt when held, `kc` when tapped                                  |
 |`RSG_T(kc)` |                                                                 |Right Shift and Right GUI when held, `kc` when tapped                                  |
 |`RAG_T(kc)` |                                                                 |Right Alt and Right GUI when held, `kc` when tapped                                    |
 |`RCSG_T(kc)`|                                                                 |Right Control, Right Shift and Right GUI when held, `kc` when tapped                   |
 |`RCAG_T(kc)`|                                                                 |Right Control, Right Alt and Right GUI when held, `kc` when tapped                     |
 |`RSAG_T(kc)`|                                                                 |Right Shift, Right Alt and Right GUI when held, `kc` when tapped                       |
 |`MEH_T(kc)` |                                                                 |Left Control, Left Shift and Left Alt when held, `kc` when tapped                      |
-|`HYPR_T(kc)`|`ALL_T(kc)`                                                      |Left Control, Left Shift, Left Alt and Left GUI when held, `kc` when tapped<sup>1</sup>|
+|`HYPR_T(kc)`|                                                                 |Left Control, Left Shift, Left Alt and Left GUI when held, `kc` when tapped<sup>1</sup>|
 
 <sup>1. More information on the Hyper key can be found on [this blog post by Brett Terpstra](https://brettterpstra.com/2012/12/08/a-useful-caps-lock-key/).</sup>
 

docs/newbs_building_firmware.md

@@ -33,7 +33,7 @@ qmk new-keymap
 If you did not configure your environment, or you have multiple keyboards, you can specify a keyboard name:
 
 ```sh
-qmk new-keymap -kb <keyboard_name>
+qmk new-keymap -kb <keyboard>
 ```
 
 Look at the output from that command, you should see something like this:

docs/newbs_flashing.md

@@ -60,7 +60,7 @@ open .
 The firmware file always follows this naming format:
 
 ```
-<keyboard_name>_<keymap_name>.{bin,hex}
+<keyboard>_<keymap>.{bin,hex}
 ```
 
 For example, the `planck/rev5` with a `default` keymap will have this filename:

docs/porting_your_keyboard_to_qmk.md

@@ -164,7 +164,7 @@ There are a lot of features that can be turned on or off, configured or tuned. S
 
 ### Configuration Options
 
-For available options for `config.h`, you should see the [Config Options](config_options#the-configh-file) page for more details.
+For available options for `config.h`, you should see the [Config Options](config_options#the-config-h-file) page for more details.
 
 ### Build Options
 

docs/proprietary_libs.md

@@ -0,0 +1,171 @@
+# Proprietary Vendor Libraries
+
+QMK Firmware cannot include support for any proprietary vendor libraries that impose additional restrictions beyond those in the GPL. This includes binary-only distributions, hardware-locked libraries, and code with redistribution limitations. This document explains why such libraries are incompatible with the GPL-based QMK Firmware and addresses commonly proposed workarounds.
+
+## Architecture Constraints
+
+Firmware presents unique licensing challenges:
+
+- **Monolithic binary**: All code compiles into a single executable image
+- **No OS isolation**: No operating system provides process or memory separation
+- **Shared resources**: All code shares the same memory space, peripherals, and execution context
+- **Static linking**: Everything is statically linked at compile time
+
+This monolithic nature means any proprietary code becomes inseparable from GPL code, creating immediate license violations.
+
+## Common Vendor Library Restrictions
+
+Proprietary vendor libraries typically impose restrictions incompatible with GPL freedoms:
+
+**Hardware Lock-in:**
+- Library only licensed for specific vendor's chips
+- Cannot port firmware to alternative hardware
+- Examples: Nordic's and ST's chip-only clauses in their respective licenses
+
+**No Source Distribution:**
+- Binary-only libraries without corresponding source
+- Precompiled static libraries (.a/.lib files)
+- No ability to modify or fix bugs
+- Examples: WCH CH582 precompiled libraries, Nordic SoftDevice
+
+**Redistribution Limitations:**
+- Restrictions on who can distribute
+- Limitations on commercial use
+- Required permissions or fees
+
+**Additional Legal Terms:**
+- Patent assertions beyond GPL's scope
+- Indemnification requirements
+- Jurisdiction restrictions
+- Explicit anti-GPL clauses
+
+## Bluetooth Stack Licensing Examples
+
+Both Nordic and ST provide Bluetooth stacks under restrictive licenses:
+
+**Nordic SoftDevice (under Nordic 5-clause license):**
+- Binary-only Bluetooth/radio stack
+- License restricts to Nordic hardware
+- No source code available
+- Communicates via SVC interface (still not GPL-compatible)
+
+**ST's Bluetooth Stack (under SLA0044 license):**
+- Explicitly forbids being subject to "Open Source Terms", specifically mentioning incompatibility with the GPL
+- Restricted to ST microcontrollers only
+- Similar functional role to Nordic's SoftDevice
+
+Both represent the same fundamental problem: critical wireless functionality locked behind proprietary licenses.
+
+## Why the System Library Exception Doesn't Apply
+
+The GPL's System Library exception **cannot** rescue proprietary vendor libraries.
+
+### System Library Requirements
+
+The exception only covers libraries that:
+1. Are part of the "normal form of packaging a Major Component"
+2. The Major Component is an OS kernel, compiler, or similar system software
+3. Are not distributed with the application
+4. Are not part of the application itself
+
+### Why Vendor Libraries Fail These Requirements
+
+1. **No operating system**: Bare-metal firmware has no OS to provide system libraries
+2. **Not Major Components**: Hardware drivers and HALs aren't kernels or compilers
+3. **Distributed together**: Vendor code becomes part of the firmware binary
+4. **Application-level code**: Peripheral drivers are application functionality
+
+The exception covers things like Windows system DLLs or Linux glibc, not microcontroller vendor libraries or Bluetooth stacks.
+
+## Attempted Workarounds
+
+### Architectural Separation Attempts
+
+**Supervisor Call (SVC) Interfaces:**
+
+Nordic's SoftDevice uses supervisor call based APIs instead of direct linking:
+- Fixed memory regions for proprietary code
+- Communication through CPU exception mechanisms
+- Claims of "no linking" between components
+
+**Why this fails:** The GPL considers functional integration, not just linking methods. In Bluetooth-capable boards, these would require the proprietary component to function, thus they form a single work regardless of the communication mechanism. This applies equally to Nordic's SoftDevice and any similar architecture ST provides.
+
+**Binary-Only Distributions:**
+
+Multiple vendors provide precompiled libraries:
+- WCH: Precompiled BLE stack
+- Nordic: Binary-only SoftDevice library
+- ST: Same solution as Nordic
+
+**Why this fails:** This is classic static linking of proprietary code into GPL code. The inability to modify these libraries violates GPL's fundamental requirements.
+
+### Loader-Based Separation
+
+- Write a GPL bootloader/loader
+- Load proprietary firmware (such as Nordic/ST Bluetooth) from external storage
+- Claim they're separate works
+
+**Problems:**
+- If designed as a system, courts view as single work
+- Distribution patterns matter (shipped together?)
+- Functional interdependence suggests unity
+- Appears designed to circumvent GPL
+
+## Real-World Examples
+
+### Bluetooth/Wireless Stacks
+- **Nordic SoftDevice**: Binary-only, SVC-interface, hardware-locked
+- **ST Bluetooth**: Binary-only, license explicitly GPL-incompatible
+- **WCH CH582**: Precompiled Bluetooth libraries
+
+### HAL and Driver Libraries
+- **ST HAL/LL drivers**: Source available but SLA0044 restricted
+- **Nordic SDK**: Source visible but 5-Clause restricted
+- **Various vendor HALs**: Platform-locked licenses
+
+### Mixed Proprietary/Open
+- Open peripheral drivers with closed protocol stacks
+- Basic HAL with proprietary performance libraries
+- Partially documented systems requiring binary supplements
+
+## Legal and Practical Consequences
+
+Including any proprietary vendor library means:
+
+1. **License Violation**: Immediate GPL non-compliance
+2. **Distribution Ban**: Users cannot legally share modified firmware
+3. **Commercial Risk**: Products using the firmware face legal liability
+4. **Contributor Tainting**: All GPL contributions become legally problematic
+5. **Update Restrictions**: Cannot fix bugs in proprietary components
+
+## Evaluation Criteria for Libraries
+
+Before including any library, QMK needs to verify:
+- Complete source code available
+- GPL-compatible license (GPL, LGPL, MIT, BSD, Apache)
+- No hardware restrictions
+- No redistribution limitations
+- No additional legal terms
+- No anti-GPL clauses
+
+## Policy Implementation
+
+QMK Firmware maintains a strict policy:
+
+1. **No proprietary libraries**: Regardless of technical workarounds
+2. **No binary blobs**: All code must have source available
+3. **No platform restrictions**: Must allow porting to any hardware
+4. **No additional terms**: Only GPL restrictions permitted
+
+## Summary
+
+There is no legally safe way to include proprietary vendor libraries in GPL firmware. This applies whether they're:
+- Bluetooth stacks (Nordic SoftDevice, ST Bluetooth)
+- Precompiled static libraries
+- Binary blobs with SVC interfaces
+- Source code with restrictive licenses
+- Mixed open/closed systems
+
+**Technical architectures cannot overcome license obligations.**
+
+QMK chooses GPL compliance, ensuring users receive all freedoms the GPL promises.

docs/quantum_painter_lvgl.md

@@ -5,7 +5,7 @@ LVGL (Light and Versatile Graphics Library) is an open-source graphics library p
 LVGL integrates with [Quantum Painter's](quantum_painter) API and drivers to render to the display, the hardware supported by Quantum Painter is also supported by LVGL.
 
 ::: tip
-Keep in mind that enabling the LVGL integration has a big impact in firmware size, it is recommeded to use a supported MCU with >256 kB of flash space.
+Keep in mind that enabling the LVGL integration has a big impact in firmware size, it is recommended to use a supported MCU with >256 kB of flash space.
 :::
 
 To learn more about LVGL and how to use it please take a look at their [official documentation](https://docs.lvgl.io/8.2/intro/)
@@ -35,7 +35,7 @@ static painter_device_t display;
 void keyboard_post_init_kb(void) {
     display = qp_make_.......;         // Create the display
     qp_init(display, QP_ROTATION_0);   // Initialise the display
-    
+
     if (qp_lvgl_attach(display)) {     // Attach LVGL to the display
         ...Your code to draw           // Run LVGL specific code to draw
     }

docs/reference_info_json.md

@@ -2,7 +2,7 @@
 
 The information contained in `info.json` is combined with the `config.h` and `rules.mk` files, dynamically generating the necessary configuration for your keyboard at compile time. It is also used by the [QMK API](https://github.com/qmk/qmk_api), and contains the information [QMK Configurator](https://config.qmk.fm/) needs to display a representation of your keyboard. Its key/value pairs are ruled by the [`data/schemas/keyboard.jsonschema`](https://github.com/qmk/qmk_firmware/blob/master/data/schemas/keyboard.jsonschema) file. To learn more about the why and how of the schema file see the [Data Driven Configuration](data_driven_config) page.
 
-You can create `info.json` files at every level under `qmk_firmware/keyboards/<keyboard_name>`. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies information common to all Clueboard products, such as `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` contains more specific information about Clueboard 66%.
+You can create `info.json` files at every level under `qmk_firmware/keyboards/<keyboard>`. These files are combined, with more specific files overriding keys in less specific files. This means you do not need to duplicate your metadata information. For example, `qmk_firmware/keyboards/clueboard/info.json` specifies information common to all Clueboard products, such as `manufacturer` and `maintainer`, while `qmk_firmware/keyboards/clueboard/66/info.json` contains more specific information about Clueboard 66%.
 
 ## General Metadata {#general-metadata}
 
@@ -179,6 +179,32 @@ Configures the [Backlight](features/backlight) feature.
     * `pins` <Badge type="info">Array: Pin</Badge>
         * A list of GPIO pins connected to the backlight LEDs (`software` and `timer` drivers only).
 
+## Battery
+
+Configures the [Battery](features/battery) feature.
+
+* `battery`
+    * `adc`
+        * `pin` <Badge type="info">Pin</Badge> <Badge>Required</Badge>
+            * The GPIO pin connected to the voltage divider.
+        * `reference_voltage` <Badge type="info">Number</Badge>
+            * The ADC reverence voltage, in millivolts. 
+            * Default: `3300`
+        * `divider_r1` <Badge type="info">Number</Badge>
+            * The voltage divider resistance, in kOhm. Set to 0 to disable.
+            * Default: `100`
+        * `divider_r2` <Badge type="info">Number</Badge>
+            * The voltage divider resistance, in kOhm. Set to 0 to disable.
+            * Default: `100`
+        * `resolution` <Badge type="info">Number</Badge>
+            * The ADC resolution configured for the ADC Driver.
+            * Default: `10`
+    * `driver` <Badge type="info">String</Badge> <Badge>Required</Badge>
+        * The driver to use. Must be one of `adc`, `custom`, `vendor`.
+    * `sample_interval` <Badge type="info">Number</Badge>
+        * The delay between sampling the battery in milliseconds.
+        * Default: `30000` (30 s)
+
 ## Wireless/Bluetooth {#bluetooth}
 
 Configures the [Wireless](features/wireless) feature.
@@ -480,6 +506,9 @@ Configures the [LED Matrix](features/led_matrix) feature.
     * `io_delay` <Badge type="info">Number</Badge>
         * The amount of time to wait between row/col selection and col/row pin reading, in microseconds.
         * Default: `30` (30 µs)
+    * `masked` <Badge type="info">Boolean</Badge>
+        * Whether configured intersections should be ignored.
+        * Default: `false`
     * `rows` <Badge type="info">Array: Pin</Badge>
         * A list of GPIO pins connected to the matrix rows.
         * Example: `["B0", "B1", "B2"]`
@@ -750,9 +779,9 @@ Configures the [Split Keyboard](features/split_keyboard) feature.
             * Default: `"bitbang"`
         * `pin` <Badge type="info">Pin</Badge>
             * The GPIO pin to use for transmit and receive.
-    * `soft_serial_speed` <Badge type="info">Number</Badge>
-        * The protocol speed, from `0` to `5` (`serial` transport protocol only).
-        * Default: `1`
+        * `speed` <Badge type="info">Number</Badge>
+            * The protocol speed, from `0` to `5` (fastest to slowest).
+            * Default: `1`
     * `transport`
         * `protocol` <Badge type="info">String</Badge>
             * The split transport protocol to use. Must be one of `custom`, `i2c`, `serial`.

docs/squeezing_avr.md

@@ -5,14 +5,14 @@ AVR is severely resource-constrained, and as QMK continues to grow, it is approa
 However, if you need to reduce the compiled size of your firmware to fit the controller's limited flash size, there are a number of options to do so.
 
 ## `rules.mk` Settings
-First and foremost is enabling link time optimization. To do so, add this to your rules.mk: 
+First and foremost is enabling link time optimization. To do so, add this to your rules.mk:
 ```make
 LTO_ENABLE = yes
 ```
 This will cause the final step to take longer, but should get you a smaller compiled size. This also disables Action Functions, and Action Macros, both of which are deprecated.
 This will get you the most savings, in most situations.
 
-From there, disabling extraneous systems will help -- e.g.: 
+From there, disabling extraneous systems will help -- e.g.:
 ```make
 CONSOLE_ENABLE = no
 COMMAND_ENABLE = no
@@ -21,10 +21,10 @@ EXTRAKEY_ENABLE = no
 ```
 This disables some of the functionality that you may not need. But note that extrakeys disables stuff like the media keys and system volume control.
 
-If that isn't enough to get your firmware down to size, then there are some additional features that you can disable: 
+If that isn't enough to get your firmware down to size, then there are some additional features that you can disable:
 ```make
 SPACE_CADET_ENABLE = no
-GRAVE_ESC_ENABLE = no 
+GRAVE_ESC_ENABLE = no
 MAGIC_ENABLE = no
 ```
 These features are enabled by default, but they may not be needed. Double check to make sure. The [Magic Keycodes](keycodes_magic) are the largest and control things like NKRO toggling, GUI and ALT/CTRL swapping, etc. Disabling them will disable those functions. See [Magic Functions](#magic-functions) for disabling related functions.
@@ -51,7 +51,7 @@ Starting with Lock Key support. If you have a Cherry MX Lock switch (lucky you!)
 #undef LOCKING_SUPPORT_ENABLE
 #undef LOCKING_RESYNC_ENABLE
 ```
-Oneshots. If you're not using these, you can disable the feature by adding this to your `config.h`: 
+Oneshots. If you're not using these, you can disable the feature by adding this to your `config.h`:
 ```c
 #define NO_ACTION_ONESHOT
 ```
@@ -61,7 +61,7 @@ The same with tapping keys (mod tap, layer tap, etc)
 ```
 ## Audio Settings
 
-If you're using the Audio feature, by default that includes the music mode feature. This tranlates matrix positions into notes. It's neat for sure, but most likely, you're not using it. You can disable it by adding this to your `config.h`:
+If you're using the Audio feature, by default that includes the music mode feature. This translates matrix positions into notes. It's neat for sure, but most likely, you're not using it. You can disable it by adding this to your `config.h`:
 ```c
 #define NO_MUSIC_MODE
 ```
@@ -124,7 +124,7 @@ into this:
     oled_write_P(PSTR("WPM: "), false);
     oled_write(get_u8_str(get_current_wpm(), ' '), false);
 ```
-which outputs `WPM:   5`. Or this: 
+which outputs `WPM:   5`. Or this:
 ```c
     // NEW CODE
     oled_write_P(PSTR("WPM: "), false);

docs/usb_nkro.txt

@@ -58,7 +58,7 @@ USB NKRO methods
 
 Report Format
 -------------
-Other report formats than followings are possible, though these format are typical one.
+Other report formats than following are possible, though these format are typical one.
 
 1. Standard             8bytes
     modifiers(bitmap)       1byte

drivers/battery/battery_adc.c

@@ -1,23 +1,24 @@
 // Copyright 2025 QMK
 // SPDX-License-Identifier: GPL-2.0-or-later
 
+#include "battery_driver.h"
 #include "analog.h"
 #include "gpio.h"
 
-#ifndef BATTERY_PIN
-#    error("BATTERY_PIN not configured!")
+#ifndef BATTERY_ADC_PIN
+#    error("BATTERY_ADC_PIN not configured!")
 #endif
 
-#ifndef BATTERY_REF_VOLTAGE_MV
-#    define BATTERY_REF_VOLTAGE_MV 3300
+#ifndef BATTERY_ADC_REF_VOLTAGE_MV
+#    define BATTERY_ADC_REF_VOLTAGE_MV 3300
 #endif
 
-#ifndef BATTERY_VOLTAGE_DIVIDER_R1
+#ifndef BATTERY_ADC_VOLTAGE_DIVIDER_R1
 #    define BATTERY_VOLTAGE_DIVIDER_R1 100
 #endif
 
-#ifndef BATTERY_VOLTAGE_DIVIDER_R2
-#    define BATTERY_VOLTAGE_DIVIDER_R2 100
+#ifndef BATTERY_ADC_VOLTAGE_DIVIDER_R2
+#    define BATTERY_ADC_VOLTAGE_DIVIDER_R2 100
 #endif
 
 // TODO: infer from adc config?
@@ -26,16 +27,16 @@
 #endif
 
 void battery_driver_init(void) {
-    gpio_set_pin_input(BATTERY_PIN);
+    gpio_set_pin_input(BATTERY_ADC_PIN);
 }
 
 uint16_t battery_driver_get_mv(void) {
-    uint32_t raw = analogReadPin(BATTERY_PIN);
+    uint32_t raw = analogReadPin(BATTERY_ADC_PIN);
 
-    uint32_t bat_mv = raw * BATTERY_REF_VOLTAGE_MV / (1 << BATTERY_ADC_RESOLUTION);
+    uint32_t bat_mv = raw * BATTERY_ADC_REF_VOLTAGE_MV / (1 << BATTERY_ADC_RESOLUTION);
 
-#if BATTERY_VOLTAGE_DIVIDER_R1 > 0 && BATTERY_VOLTAGE_DIVIDER_R2 > 0
-    bat_mv = bat_mv * (BATTERY_VOLTAGE_DIVIDER_R1 + BATTERY_VOLTAGE_DIVIDER_R2) / BATTERY_VOLTAGE_DIVIDER_R2;
+#if BATTERY_VOLTAGE_DIVIDER_R1 > 0 && BATTERY_ADC_VOLTAGE_DIVIDER_R2 > 0
+    bat_mv = bat_mv * (BATTERY_VOLTAGE_DIVIDER_R1 + BATTERY_ADC_VOLTAGE_DIVIDER_R2) / BATTERY_ADC_VOLTAGE_DIVIDER_R2;
 #endif
 
     return bat_mv;

drivers/lcd/st7565.h

@@ -116,12 +116,12 @@ void st7565_render(void);
 void st7565_set_cursor(uint8_t col, uint8_t line);
 
 // Advances the cursor to the next page, writing ' ' if true
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void st7565_advance_page(bool clearPageRemainder);
 
 // Moves the cursor forward 1 character length
 // Advance page if there is not enough room for the next character
-// Wraps to the begining when out of bounds
+// Wraps to the beginning when out of bounds
 void st7565_advance_char(void);
 
 // Writes a single character to the buffer at current cursor position

drivers/oled/glcdfont.c

@@ -1,16 +1,256 @@
+// Copyright 2025 QMK
+// SPDX-License-Identifier: GPL-2.0-or-later WITH BSD-2-Clause
+
 #include "progmem.h"
 
-// Helidox 8x6 font with QMK Firmware Logo
-// Online editor: http://teripom.x0.com/
-
+/**
+ * QMK 6x8 Font for LCD and OLED displays
+ *
+ * Derived from the first half of the Adafruit GFX Library font:
+ *   https://github.com/adafruit/Adafruit-GFX-Library
+ *
+ * The first 128 characters match that of code page 437, the character set used by the original IBM PC, which includes all printable ASCII characters.
+ * Each byte represents a column of 8 pixels, with the least significant bit being the top of the glyph.
+ *
+ * A large 21x3 character QMK Firmware logo is encoded from 0x80-0x94, 0xA0-0xB4, and 0xC0-0xD4.
+ * 2x2 character OS logos for Apple, Windows, Linux and Android are encoded from 0x95-0x9C and 0xB5-0xBC.
+ */
 static const unsigned char font[] PROGMEM = {
-    0x07, 0x08, 0x7F, 0x08, 0x07, 0x00, 0x3E, 0x5B, 0x4F, 0x5B, 0x3E, 0x00, 0x3E, 0x6B, 0x4F, 0x6B, 0x3E, 0x00, 0x1C, 0x3E, 0x7C, 0x3E, 0x1C, 0x00, 0x18, 0x3C, 0x7E, 0x3C, 0x18, 0x00, 0x1C, 0x57, 0x7D, 0x57, 0x1C, 0x00, 0x1C, 0x5E, 0x7F, 0x5E, 0x1C, 0x00, 0x00, 0x18, 0x3C, 0x18, 0x00, 0x00, 0xFF, 0xE7, 0xC3, 0xE7, 0xFF, 0x00, 0x00, 0x18, 0x24, 0x18, 0x00, 0x00, 0xFF, 0xE7, 0xDB, 0xE7, 0xFF, 0x00, 0x30, 0x48, 0x3A, 0x06, 0x0E, 0x00, 0x26, 0x29, 0x79, 0x29, 0x26, 0x00, 0x40, 0x7F, 0x05, 0x05, 0x07, 0x00, 0x40, 0x7F, 0x05, 0x25, 0x3F, 0x00, 0x5A, 0x3C, 0xE7, 0x3C, 0x5A, 0x00, 0x7F, 0x3E, 0x1C, 0x1C, 0x08, 0x00, 0x08, 0x1C, 0x1C, 0x3E, 0x7F, 0x00, 0x14, 0x22, 0x7F, 0x22, 0x14, 0x00, 0x5F, 0x5F, 0x00, 0x5F, 0x5F, 0x00, 0x06, 0x09, 0x7F, 0x01, 0x7F, 0x00, 0x00, 0x66, 0x89, 0x95, 0x6A, 0x00, 0x60, 0x60, 0x60, 0x60, 0x60, 0x00, 0x94, 0xA2, 0xFF, 0xA2, 0x94, 0x00, 0x08, 0x04, 0x7E, 0x04, 0x08, 0x00,
-    0x10, 0x20, 0x7E, 0x20, 0x10, 0x00, 0x08, 0x08, 0x2A, 0x1C, 0x08, 0x00, 0x08, 0x1C, 0x2A, 0x08, 0x08, 0x00, 0x1E, 0x10, 0x10, 0x10, 0x10, 0x00, 0x0C, 0x1E, 0x0C, 0x1E, 0x0C, 0x00, 0x30, 0x38, 0x3E, 0x38, 0x30, 0x00, 0x06, 0x0E, 0x3E, 0x0E, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x5F, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x07, 0x00, 0x00, 0x14, 0x7F, 0x14, 0x7F, 0x14, 0x00, 0x24, 0x2A, 0x7F, 0x2A, 0x12, 0x00, 0x23, 0x13, 0x08, 0x64, 0x62, 0x00, 0x36, 0x49, 0x56, 0x20, 0x50, 0x00, 0x00, 0x08, 0x07, 0x03, 0x00, 0x00, 0x00, 0x1C, 0x22, 0x41, 0x00, 0x00, 0x00, 0x41, 0x22, 0x1C, 0x00, 0x00, 0x2A, 0x1C, 0x7F, 0x1C, 0x2A, 0x00, 0x08, 0x08, 0x3E, 0x08, 0x08, 0x00, 0x00, 0x80, 0x70, 0x30, 0x00, 0x00, 0x08, 0x08, 0x08, 0x08, 0x08, 0x00, 0x00, 0x00, 0x60, 0x60, 0x00, 0x00, 0x20, 0x10, 0x08, 0x04, 0x02, 0x00, 0x3E, 0x51, 0x49, 0x45, 0x3E, 0x00, 0x00, 0x42, 0x7F, 0x40, 0x00, 0x00,
-    0x72, 0x49, 0x49, 0x49, 0x46, 0x00, 0x21, 0x41, 0x49, 0x4D, 0x33, 0x00, 0x18, 0x14, 0x12, 0x7F, 0x10, 0x00, 0x27, 0x45, 0x45, 0x45, 0x39, 0x00, 0x3C, 0x4A, 0x49, 0x49, 0x31, 0x00, 0x41, 0x21, 0x11, 0x09, 0x07, 0x00, 0x36, 0x49, 0x49, 0x49, 0x36, 0x00, 0x46, 0x49, 0x49, 0x29, 0x1E, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00, 0x00, 0x40, 0x34, 0x00, 0x00, 0x00, 0x00, 0x08, 0x14, 0x22, 0x41, 0x00, 0x14, 0x14, 0x14, 0x14, 0x14, 0x00, 0x00, 0x41, 0x22, 0x14, 0x08, 0x00, 0x02, 0x01, 0x59, 0x09, 0x06, 0x00, 0x3E, 0x41, 0x5D, 0x59, 0x4E, 0x00, 0x7C, 0x12, 0x11, 0x12, 0x7C, 0x00, 0x7F, 0x49, 0x49, 0x49, 0x36, 0x00, 0x3E, 0x41, 0x41, 0x41, 0x22, 0x00, 0x7F, 0x41, 0x41, 0x41, 0x3E, 0x00, 0x7F, 0x49, 0x49, 0x49, 0x41, 0x00, 0x7F, 0x09, 0x09, 0x09, 0x01, 0x00, 0x3E, 0x41, 0x41, 0x51, 0x73, 0x00, 0x7F, 0x08, 0x08, 0x08, 0x7F, 0x00, 0x00, 0x41, 0x7F, 0x41, 0x00, 0x00, 0x20, 0x40, 0x41, 0x3F, 0x01, 0x00,
-    0x7F, 0x08, 0x14, 0x22, 0x41, 0x00, 0x7F, 0x40, 0x40, 0x40, 0x40, 0x00, 0x7F, 0x02, 0x1C, 0x02, 0x7F, 0x00, 0x7F, 0x04, 0x08, 0x10, 0x7F, 0x00, 0x3E, 0x41, 0x41, 0x41, 0x3E, 0x00, 0x7F, 0x09, 0x09, 0x09, 0x06, 0x00, 0x3E, 0x41, 0x51, 0x21, 0x5E, 0x00, 0x7F, 0x09, 0x19, 0x29, 0x46, 0x00, 0x26, 0x49, 0x49, 0x49, 0x32, 0x00, 0x03, 0x01, 0x7F, 0x01, 0x03, 0x00, 0x3F, 0x40, 0x40, 0x40, 0x3F, 0x00, 0x1F, 0x20, 0x40, 0x20, 0x1F, 0x00, 0x3F, 0x40, 0x38, 0x40, 0x3F, 0x00, 0x63, 0x14, 0x08, 0x14, 0x63, 0x00, 0x03, 0x04, 0x78, 0x04, 0x03, 0x00, 0x61, 0x59, 0x49, 0x4D, 0x43, 0x00, 0x00, 0x7F, 0x41, 0x41, 0x41, 0x00, 0x02, 0x04, 0x08, 0x10, 0x20, 0x00, 0x00, 0x41, 0x41, 0x41, 0x7F, 0x00, 0x04, 0x02, 0x01, 0x02, 0x04, 0x00, 0x40, 0x40, 0x40, 0x40, 0x40, 0x00, 0x00, 0x03, 0x07, 0x08, 0x00, 0x00, 0x20, 0x54, 0x54, 0x78, 0x40, 0x00, 0x7F, 0x28, 0x44, 0x44, 0x38, 0x00, 0x38, 0x44, 0x44, 0x44, 0x28, 0x00,
-    0x38, 0x44, 0x44, 0x28, 0x7F, 0x00, 0x38, 0x54, 0x54, 0x54, 0x18, 0x00, 0x00, 0x08, 0x7E, 0x09, 0x02, 0x00, 0x18, 0xA4, 0xA4, 0x9C, 0x78, 0x00, 0x7F, 0x08, 0x04, 0x04, 0x78, 0x00, 0x00, 0x44, 0x7D, 0x40, 0x00, 0x00, 0x20, 0x40, 0x40, 0x3D, 0x00, 0x00, 0x7F, 0x10, 0x28, 0x44, 0x00, 0x00, 0x00, 0x41, 0x7F, 0x40, 0x00, 0x00, 0x7C, 0x04, 0x78, 0x04, 0x78, 0x00, 0x7C, 0x08, 0x04, 0x04, 0x78, 0x00, 0x38, 0x44, 0x44, 0x44, 0x38, 0x00, 0xFC, 0x18, 0x24, 0x24, 0x18, 0x00, 0x18, 0x24, 0x24, 0x18, 0xFC, 0x00, 0x7C, 0x08, 0x04, 0x04, 0x08, 0x00, 0x48, 0x54, 0x54, 0x54, 0x24, 0x00, 0x04, 0x04, 0x3F, 0x44, 0x24, 0x00, 0x3C, 0x40, 0x40, 0x20, 0x7C, 0x00, 0x1C, 0x20, 0x40, 0x20, 0x1C, 0x00, 0x3C, 0x40, 0x30, 0x40, 0x3C, 0x00, 0x44, 0x28, 0x10, 0x28, 0x44, 0x00, 0x4C, 0x90, 0x90, 0x90, 0x7C, 0x00, 0x44, 0x64, 0x54, 0x4C, 0x44, 0x00, 0x00, 0x08, 0x36, 0x41, 0x00, 0x00, 0x00, 0x00, 0x77, 0x00, 0x00, 0x00,
-    0x00, 0x41, 0x36, 0x08, 0x00, 0x00, 0x02, 0x01, 0x02, 0x04, 0x02, 0x00, 0x3C, 0x26, 0x23, 0x26, 0x3C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x40, 0x40, 0xF0, 0xF8, 0xF8, 0xFF, 0x38, 0xFF, 0xF8, 0xF8, 0x3F, 0xF8, 0xF8, 0xFF, 0x38, 0xFF, 0xF8, 0xF8, 0xF0, 0x40, 0x40, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0xC0, 0xC0, 0xC0, 0x80, 0x00, 0x00, 0xC0, 0xC0, 0x80, 0x00, 0x00, 0x00, 0x80, 0xC0, 0xC0, 0x00, 0xC0, 0xC0, 0x00, 0x00, 0x80, 0xC0, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0xC0, 0xC0, 0xC0, 0xC0, 0x00, 0xC0, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0xF0, 0xF8, 0xFC, 0x3E,
-    0x1E, 0x06, 0x01, 0x00, 0x00, 0x00, 0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, 0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, 0x00, 0x80, 0xC0, 0xE0, 0x7E, 0x5B, 0x4F, 0x5B, 0xFE, 0xC0, 0x00, 0x00, 0xC0, 0x00, 0xDC, 0xD7, 0xDE, 0xDE, 0xDE, 0xD7, 0xDC, 0x00, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x49, 0x49, 0x49, 0xFF, 0xFF, 0xFF, 0xFF, 0xE0, 0xDF, 0xBF, 0xBF, 0x00, 0xBF, 0xBF, 0xDF, 0xE0, 0xFF, 0xFF, 0xFF, 0xFF, 0x49, 0x49, 0x49, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1F, 0x3F, 0x60, 0x60, 0xE0, 0xBF, 0x1F, 0x00, 0x7F, 0x7F, 0x07, 0x1E, 0x38, 0x1E, 0x07, 0x7F, 0x7F, 0x00, 0x7F, 0x7F, 0x0E, 0x1F, 0x3B, 0x71, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x7F, 0x7F, 0x0C, 0x0C, 0x0C, 0x00, 0x7E, 0x7E, 0x00, 0x7F, 0x7E, 0x03, 0x03, 0x00, 0x7F, 0x7E, 0x03, 0x03, 0x7E, 0x7E, 0x03, 0x03, 0x7F, 0x7E, 0x00, 0x0F,
-    0x3E, 0x70, 0x3C, 0x06, 0x3C, 0x70, 0x3E, 0x0F, 0x00, 0x32, 0x7B, 0x49, 0x49, 0x3F, 0x7E, 0x00, 0x7F, 0x7E, 0x03, 0x03, 0x00, 0x1E, 0x3F, 0x69, 0x69, 0x6F, 0x26, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x0F, 0x1F, 0x3F, 0x3C, 0x78, 0x70, 0x60, 0x00, 0x00, 0x00, 0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, 0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, 0x30, 0x7B, 0x7F, 0x78, 0x30, 0x20, 0x20, 0x30, 0x78, 0x7F, 0x3B, 0x00, 0x03, 0x00, 0x0F, 0x7F, 0x0F, 0x0F, 0x0F, 0x7F, 0x0F, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x07, 0x0F, 0x0F, 0x7F, 0x0F, 0x7F, 0x0F, 0x0F, 0x7E, 0x0F, 0x0F, 0x7F, 0x0F, 0x7F, 0x0F, 0x0F, 0x07, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0x07, 0x08, 0x7F, 0x08, 0x07, 0x00, // 0x00 NUL / Ψ
+    0x3E, 0x6B, 0x4F, 0x6B, 0x3E, 0x00, // 0x01 SOH / ☺︎
+    0xC1, 0x94, 0xB0, 0x94, 0xC1, 0x00, // 0x02 STX / ☻
+    0x1C, 0x3E, 0x7C, 0x3E, 0x1C, 0x00, // 0x03 ETX / ♥︎
+    0x18, 0x3C, 0x7E, 0x3C, 0x18, 0x00, // 0x04 EOT / ♦︎
+    0x1C, 0x57, 0x7D, 0x57, 0x1C, 0x00, // 0x05 ENQ / ♣︎
+    0x1C, 0x5E, 0x7F, 0x5E, 0x1C, 0x00, // 0x06 ACK / ♠︎
+    0x00, 0x18, 0x3C, 0x18, 0x00, 0x00, // 0x07 BEL / •
+    0xFF, 0xE7, 0xC3, 0xE7, 0xFF, 0x00, // 0x08 BS  / ◘
+    0x00, 0x18, 0x24, 0x18, 0x00, 0x00, // 0x09 HT  / ○
+    0xFF, 0xE7, 0xDB, 0xE7, 0xFF, 0x00, // 0x0A LF  / ◙
+    0x30, 0x48, 0x3A, 0x06, 0x0E, 0x00, // 0x0B VT  / ♂︎
+    0x26, 0x29, 0x79, 0x29, 0x26, 0x00, // 0x0C FF  / ♀︎
+    0x40, 0x7F, 0x05, 0x05, 0x07, 0x00, // 0x0D CR  / ♪
+    0x40, 0x7F, 0x05, 0x25, 0x3F, 0x00, // 0x0E SO  / ♫
+    0x5A, 0x3C, 0xE7, 0x3C, 0x5A, 0x00, // 0x0F SI  / ☼
+
+    0x7F, 0x3E, 0x1C, 0x1C, 0x08, 0x00, // 0x10 DLE / ►
+    0x08, 0x1C, 0x1C, 0x3E, 0x7F, 0x00, // 0x11 DC1 / ◄
+    0x14, 0x22, 0x7F, 0x22, 0x14, 0x00, // 0x12 DC2 / ↕︎
+    0x5F, 0x5F, 0x00, 0x5F, 0x5F, 0x00, // 0x13 DC3 / ‼︎
+    0x06, 0x09, 0x7F, 0x01, 0x7F, 0x00, // 0x14 DC4 / ¶
+    0x00, 0x66, 0x89, 0x95, 0x6A, 0x00, // 0x15 NAK / §
+    0x60, 0x60, 0x60, 0x60, 0x60, 0x00, // 0x16 SYN / ▬
+    0x94, 0xA2, 0xFF, 0xA2, 0x94, 0x00, // 0x17 ETB / ↨
+    0x08, 0x04, 0x7E, 0x04, 0x08, 0x00, // 0x18 CAN / ↑
+    0x10, 0x20, 0x7E, 0x20, 0x10, 0x00, // 0x19 EM  / ↓
+    0x08, 0x08, 0x2A, 0x1C, 0x08, 0x00, // 0x1A SUB / →
+    0x08, 0x1C, 0x2A, 0x08, 0x08, 0x00, // 0x1B ESC / ←
+    0x1E, 0x10, 0x10, 0x10, 0x10, 0x00, // 0x1C FS  / ∟
+    0x0C, 0x1E, 0x0C, 0x1E, 0x0C, 0x00, // 0x1D GS  / ↔︎
+    0x30, 0x38, 0x3E, 0x38, 0x30, 0x00, // 0x1E RS  / ▲
+    0x06, 0x0E, 0x3E, 0x0E, 0x06, 0x00, // 0x1F US  / ▼
+
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x20 Space
+    0x00, 0x00, 0x5F, 0x00, 0x00, 0x00, // 0x21 !
+    0x00, 0x07, 0x00, 0x07, 0x00, 0x00, // 0x22 "
+    0x14, 0x7F, 0x14, 0x7F, 0x14, 0x00, // 0x23 #
+    0x24, 0x2A, 0x7F, 0x2A, 0x12, 0x00, // 0x24 $
+    0x23, 0x13, 0x08, 0x64, 0x62, 0x00, // 0x25 %
+    0x36, 0x49, 0x56, 0x20, 0x50, 0x00, // 0x26 &
+    0x00, 0x08, 0x07, 0x03, 0x00, 0x00, // 0x27 '
+    0x00, 0x1C, 0x22, 0x41, 0x00, 0x00, // 0x28 (
+    0x00, 0x41, 0x22, 0x1C, 0x00, 0x00, // 0x29 )
+    0x2A, 0x1C, 0x7F, 0x1C, 0x2A, 0x00, // 0x2A *
+    0x08, 0x08, 0x3E, 0x08, 0x08, 0x00, // 0x2B +
+    0x00, 0x80, 0x70, 0x30, 0x00, 0x00, // 0x2C ,
+    0x08, 0x08, 0x08, 0x08, 0x08, 0x00, // 0x2D -
+    0x00, 0x00, 0x60, 0x60, 0x00, 0x00, // 0x2E .
+    0x20, 0x10, 0x08, 0x04, 0x02, 0x00, // 0x2F /
+
+    0x3E, 0x51, 0x49, 0x45, 0x3E, 0x00, // 0x30 0
+    0x00, 0x42, 0x7F, 0x40, 0x00, 0x00, // 0x31 1
+    0x72, 0x49, 0x49, 0x49, 0x46, 0x00, // 0x32 2
+    0x21, 0x41, 0x49, 0x4D, 0x33, 0x00, // 0x33 3
+    0x18, 0x14, 0x12, 0x7F, 0x10, 0x00, // 0x34 4
+    0x27, 0x45, 0x45, 0x45, 0x39, 0x00, // 0x35 5
+    0x3C, 0x4A, 0x49, 0x49, 0x31, 0x00, // 0x36 6
+    0x41, 0x21, 0x11, 0x09, 0x07, 0x00, // 0x37 7
+    0x36, 0x49, 0x49, 0x49, 0x36, 0x00, // 0x38 8
+    0x46, 0x49, 0x49, 0x29, 0x1E, 0x00, // 0x39 9
+    0x00, 0x00, 0x14, 0x00, 0x00, 0x00, // 0x3A :
+    0x00, 0x40, 0x34, 0x00, 0x00, 0x00, // 0x3B ;
+    0x00, 0x08, 0x14, 0x22, 0x41, 0x00, // 0x3C <
+    0x14, 0x14, 0x14, 0x14, 0x14, 0x00, // 0x3D =
+    0x00, 0x41, 0x22, 0x14, 0x08, 0x00, // 0x3E >
+    0x02, 0x01, 0x59, 0x09, 0x06, 0x00, // 0x3F ?
+
+    0x3E, 0x41, 0x5D, 0x59, 0x4E, 0x00, // 0x40 @
+    0x7C, 0x12, 0x11, 0x12, 0x7C, 0x00, // 0x41 A
+    0x7F, 0x49, 0x49, 0x49, 0x36, 0x00, // 0x42 B
+    0x3E, 0x41, 0x41, 0x41, 0x22, 0x00, // 0x43 C
+    0x7F, 0x41, 0x41, 0x41, 0x3E, 0x00, // 0x44 D
+    0x7F, 0x49, 0x49, 0x49, 0x41, 0x00, // 0x45 E
+    0x7F, 0x09, 0x09, 0x09, 0x01, 0x00, // 0x46 F
+    0x3E, 0x41, 0x41, 0x51, 0x73, 0x00, // 0x47 G
+    0x7F, 0x08, 0x08, 0x08, 0x7F, 0x00, // 0x48 H
+    0x00, 0x41, 0x7F, 0x41, 0x00, 0x00, // 0x49 I
+    0x20, 0x40, 0x41, 0x3F, 0x01, 0x00, // 0x4A J
+    0x7F, 0x08, 0x14, 0x22, 0x41, 0x00, // 0x4B K
+    0x7F, 0x40, 0x40, 0x40, 0x40, 0x00, // 0x4C L
+    0x7F, 0x02, 0x1C, 0x02, 0x7F, 0x00, // 0x4D M
+    0x7F, 0x04, 0x08, 0x10, 0x7F, 0x00, // 0x4E N
+    0x3E, 0x41, 0x41, 0x41, 0x3E, 0x00, // 0x4F O
+
+    0x7F, 0x09, 0x09, 0x09, 0x06, 0x00, // 0x50 P
+    0x3E, 0x41, 0x51, 0x21, 0x5E, 0x00, // 0x51 Q
+    0x7F, 0x09, 0x19, 0x29, 0x46, 0x00, // 0x52 R
+    0x26, 0x49, 0x49, 0x49, 0x32, 0x00, // 0x53 S
+    0x03, 0x01, 0x7F, 0x01, 0x03, 0x00, // 0x54 T
+    0x3F, 0x40, 0x40, 0x40, 0x3F, 0x00, // 0x55 U
+    0x1F, 0x20, 0x40, 0x20, 0x1F, 0x00, // 0x56 V
+    0x3F, 0x40, 0x38, 0x40, 0x3F, 0x00, // 0x57 W
+    0x63, 0x14, 0x08, 0x14, 0x63, 0x00, // 0x58 X
+    0x03, 0x04, 0x78, 0x04, 0x03, 0x00, // 0x59 Y
+    0x61, 0x59, 0x49, 0x4D, 0x43, 0x00, // 0x5A Z
+    0x00, 0x7F, 0x41, 0x41, 0x41, 0x00, // 0x5B [
+    0x02, 0x04, 0x08, 0x10, 0x20, 0x00, // 0x5C Backslash
+    0x00, 0x41, 0x41, 0x41, 0x7F, 0x00, // 0x5D ]
+    0x04, 0x02, 0x01, 0x02, 0x04, 0x00, // 0x5E ^
+    0x40, 0x40, 0x40, 0x40, 0x40, 0x00, // 0x5F _
+
+    0x00, 0x03, 0x07, 0x08, 0x00, 0x00, // 0x60 `
+    0x20, 0x54, 0x54, 0x78, 0x40, 0x00, // 0x61 a
+    0x7F, 0x28, 0x44, 0x44, 0x38, 0x00, // 0x62 b
+    0x38, 0x44, 0x44, 0x44, 0x28, 0x00, // 0x63 c
+    0x38, 0x44, 0x44, 0x28, 0x7F, 0x00, // 0x64 d
+    0x38, 0x54, 0x54, 0x54, 0x18, 0x00, // 0x65 e
+    0x00, 0x08, 0x7E, 0x09, 0x02, 0x00, // 0x66 f
+    0x18, 0xA4, 0xA4, 0x9C, 0x78, 0x00, // 0x67 g
+    0x7F, 0x08, 0x04, 0x04, 0x78, 0x00, // 0x68 h
+    0x00, 0x44, 0x7D, 0x40, 0x00, 0x00, // 0x69 i
+    0x20, 0x40, 0x40, 0x3D, 0x00, 0x00, // 0x6A j
+    0x7F, 0x10, 0x28, 0x44, 0x00, 0x00, // 0x6B k
+    0x00, 0x41, 0x7F, 0x40, 0x00, 0x00, // 0x6C l
+    0x7C, 0x04, 0x78, 0x04, 0x78, 0x00, // 0x6D m
+    0x7C, 0x08, 0x04, 0x04, 0x78, 0x00, // 0x6E n
+    0x38, 0x44, 0x44, 0x44, 0x38, 0x00, // 0x6F o
+
+    0xFC, 0x18, 0x24, 0x24, 0x18, 0x00, // 0x70 p
+    0x18, 0x24, 0x24, 0x18, 0xFC, 0x00, // 0x71 q
+    0x7C, 0x08, 0x04, 0x04, 0x08, 0x00, // 0x72 r
+    0x48, 0x54, 0x54, 0x54, 0x24, 0x00, // 0x73 s
+    0x04, 0x04, 0x3F, 0x44, 0x24, 0x00, // 0x74 t
+    0x3C, 0x40, 0x40, 0x20, 0x7C, 0x00, // 0x75 u
+    0x1C, 0x20, 0x40, 0x20, 0x1C, 0x00, // 0x76 v
+    0x3C, 0x40, 0x30, 0x40, 0x3C, 0x00, // 0x77 w
+    0x44, 0x28, 0x10, 0x28, 0x44, 0x00, // 0x78 x
+    0x4C, 0x90, 0x90, 0x90, 0x7C, 0x00, // 0x79 y
+    0x44, 0x64, 0x54, 0x4C, 0x44, 0x00, // 0x7A z
+    0x00, 0x08, 0x36, 0x41, 0x00, 0x00, // 0x7B {
+    0x00, 0x00, 0x77, 0x00, 0x00, 0x00, // 0x7C |
+    0x00, 0x41, 0x36, 0x08, 0x00, 0x00, // 0x7D }
+    0x02, 0x01, 0x02, 0x04, 0x02, 0x00, // 0x7E ~
+    0x3C, 0x26, 0x23, 0x26, 0x3C, 0x00, // 0x7F DEL / ⌂
+
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x80 QMK Logo Top 1
+    0x00, 0x00, 0x80, 0x80, 0xE0, 0xF0, // 0x81 QMK Logo Top 2
+    0xF0, 0xFC, 0x70, 0xFC, 0xF0, 0x7C, // 0x82 QMK Logo Top 3
+    0xF0, 0xFC, 0x70, 0xFC, 0xF0, 0xF0, // 0x83 QMK Logo Top 4
+    0xE0, 0x80, 0x80, 0x00, 0x00, 0x00, // 0x84 QMK Logo Top 5
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x85 QMK Logo Top 6
+    0x80, 0x80, 0x80, 0x00, 0x00, 0x00, // 0x86 QMK Logo Top 7
+    0x80, 0x80, 0x00, 0x00, 0x00, 0x00, // 0x87 QMK Logo Top 8
+    0x00, 0x80, 0x80, 0x00, 0x80, 0x80, // 0x88 QMK Logo Top 9
+    0x00, 0x00, 0x00, 0x80, 0x80, 0x00, // 0x89 QMK Logo Top 10
+    0x00, 0x00, 0x00, 0x00, 0x80, 0x80, // 0x8A QMK Logo Top 11
+    0x80, 0x80, 0x80, 0x00, 0x80, 0x80, // 0x8B QMK Logo Top 12
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x8C QMK Logo Top 13
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x8D QMK Logo Top 14
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x8E QMK Logo Top 15
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x8F QMK Logo Top 16
+
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x90 QMK Logo Top 17
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x91 QMK Logo Top 18
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x92 QMK Logo Top 19
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x93 QMK Logo Top 20
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x94 QMK Logo Top 21
+    0x00, 0xC0, 0xF0, 0xF8, 0xFC, 0x3E, // 0x95 Apple Logo TL
+    0x1E, 0x06, 0x01, 0x00, 0x00, 0x00, // 0x96 Apple Logo TR
+    0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, // 0x97 Windows Logo TL
+    0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, // 0x98 Windows Logo TR
+    0x00, 0x80, 0xC0, 0xE0, 0x7E, 0x5B, // 0x99 Linux Logo TL
+    0x4F, 0x5B, 0xFE, 0xC0, 0x00, 0x00, // 0x9A Linux Logo TR
+    0xC0, 0x00, 0xDC, 0xD7, 0xDE, 0xDE, // 0x9B Android Logo TL
+    0xDE, 0xD7, 0xDC, 0x00, 0xC0, 0x00, // 0x9C Android Logo TR
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x9D
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x9E
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x9F
+
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xA0 QMK Logo Middle 1
+    0x00, 0x00, 0xAA, 0xAA, 0xFF, 0xFF, // 0xA1 QMK Logo Middle 2
+    0xFF, 0xFF, 0xE0, 0xDF, 0xDF, 0x00, // 0xA2 QMK Logo Middle 3
+    0xDF, 0xDF, 0xE0, 0xFF, 0xFF, 0xFF, // 0xA3 QMK Logo Middle 4
+    0xFF, 0xAA, 0xAA, 0x00, 0x00, 0x00, // 0xA4 QMK Logo Middle 5
+    0x00, 0x00, 0x00, 0x00, 0x3E, 0x7F, // 0xA5 QMK Logo Middle 6
+    0xC1, 0xC1, 0xC1, 0x7F, 0x3E, 0x00, // 0xA6 QMK Logo Middle 7
+    0xFF, 0xFF, 0x0F, 0x3C, 0x78, 0x3C, // 0xA7 QMK Logo Middle 8
+    0x0F, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, // 0xA8 QMK Logo Middle 9
+    0x1C, 0x3E, 0x77, 0xE3, 0xC1, 0x00, // 0xA9 QMK Logo Middle 10
+    0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, // 0xAA QMK Logo Middle 11
+    0x19, 0x19, 0x19, 0x00, 0xFD, 0xFD, // 0xAB QMK Logo Middle 12
+    0x00, 0xFE, 0xFC, 0x06, 0x06, 0x00, // 0xAC QMK Logo Middle 13
+    0xFE, 0xFC, 0x06, 0x06, 0xFC, 0xFC, // 0xAD QMK Logo Middle 14
+    0x06, 0x06, 0xFE, 0xFC, 0x00, 0x1E, // 0xAE QMK Logo Middle 15
+    0x7C, 0xE0, 0x78, 0x0C, 0x78, 0xE0, // 0xAF QMK Logo Middle 16
+
+    0x7C, 0x1E, 0x00, 0x64, 0xF6, 0x92, // 0xB0 QMK Logo Middle 17
+    0x92, 0x7E, 0xFC, 0x00, 0xFE, 0xFC, // 0xB1 QMK Logo Middle 18
+    0x06, 0x06, 0x00, 0x3C, 0x7E, 0xD2, // 0xB2 QMK Logo Middle 19
+    0xD2, 0xDE, 0x4C, 0x00, 0x00, 0x00, // 0xB3 QMK Logo Middle 20
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xB4 QMK Logo Middle 21
+    0x00, 0x03, 0x0F, 0x1F, 0x3F, 0x3C, // 0xB5 Apple Logo BL
+    0x78, 0x70, 0x60, 0x00, 0x00, 0x00, // 0xB6 Apple Logo BR
+    0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, // 0xB7 Windows Logo BL
+    0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00, // 0xB8 Windows Logo BR
+    0x30, 0x7B, 0x7F, 0x78, 0x30, 0x20, // 0xB9 Linux Logo BL
+    0x20, 0x30, 0x78, 0x7F, 0x3B, 0x00, // 0xBA Linux Logo BR
+    0x03, 0x00, 0x0F, 0x7F, 0x0F, 0x0F, // 0xBB Android Logo BL
+    0x0F, 0x7F, 0x0F, 0x00, 0x03, 0x00, // 0xBC Android Logo BR
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xBD
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xBE
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xBF
+
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC0 QMK Logo Bottom 1
+    0x00, 0x00, 0x00, 0x00, 0x03, 0x07, // 0xC1 QMK Logo Bottom 2
+    0x07, 0x1F, 0x07, 0x1F, 0x07, 0x1F, // 0xC2 QMK Logo Bottom 3
+    0x07, 0x1F, 0x07, 0x1F, 0x07, 0x07, // 0xC3 QMK Logo Bottom 4
+    0x03, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC4 QMK Logo Bottom 5
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC5 QMK Logo Bottom 6
+    0x00, 0x00, 0x01, 0x03, 0x02, 0x00, // 0xC6 QMK Logo Bottom 7
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC7 QMK Logo Bottom 8
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC8 QMK Logo Bottom 9
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xC9 QMK Logo Bottom 10
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xCA QMK Logo Bottom 11
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xCB QMK Logo Bottom 12
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xCC QMK Logo Bottom 13
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xCD QMK Logo Bottom 14
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xCE QMK Logo Bottom 15
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xCF QMK Logo Bottom 16
+
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD0 QMK Logo Bottom 17
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD1 QMK Logo Bottom 18
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD2 QMK Logo Bottom 19
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD3 QMK Logo Bottom 10
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD4 QMK Logo Bottom 21
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD5
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD6
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD7
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD8
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xD9
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xDA
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xDB
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xDC
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xDD
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0xDE
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x00  // 0xDF
 };

drivers/sensors/adns5050.c

@@ -55,7 +55,7 @@ const pointing_device_driver_t adns5050_pointing_device_driver = {
 
 static bool powered_down = false;
 
-void adns5050_init(void) {
+bool adns5050_init(void) {
     // Initialize the ADNS serial pins.
     gpio_set_pin_output(ADNS5050_SCLK_PIN);
     gpio_set_pin_output(ADNS5050_SDIO_PIN);
@@ -75,6 +75,8 @@ void adns5050_init(void) {
     // gets the adns ready for write commands
     // (for example, setting the dpi).
     adns5050_read_burst();
+
+    return adns5050_check_signature();
 }
 
 // Perform a synchronization with the ADNS.
@@ -220,7 +222,7 @@ uint16_t adns5050_get_cpi(void) {
     return (uint16_t)((cpival & 0b10000) * 125);
 }
 
-bool adns5050_check_signature(void) {
+bool __attribute__((weak)) adns5050_check_signature(void) {
     uint8_t pid  = adns5050_read_reg(REG_PRODUCT_ID);
     uint8_t rid  = adns5050_read_reg(REG_REVISION_ID);
     uint8_t pid2 = adns5050_read_reg(REG_PRODUCT_ID2);

drivers/sensors/adns5050.h

@@ -70,12 +70,12 @@ typedef struct {
     int8_t dy;
 } report_adns5050_t;
 
-const pointing_device_driver_t adns5050_pointing_device_driver;
+extern const pointing_device_driver_t adns5050_pointing_device_driver;
 
 // A bunch of functions to implement the ADNS5050-specific serial protocol.
 // Note that the "serial.h" driver is insufficient, because it does not
 // manually manipulate a serial clock signal.
-void              adns5050_init(void);
+bool              adns5050_init(void);
 void              adns5050_sync(void);
 uint8_t           adns5050_serial_read(void);
 void              adns5050_serial_write(uint8_t data);

drivers/sensors/adns9800.c

@@ -115,7 +115,14 @@ uint8_t adns9800_read(uint8_t reg_addr) {
     return data;
 }
 
-void adns9800_init(void) {
+bool __attribute__((weak)) adns9800_check_signature(void) {
+    if (adns9800_read(REG_Product_ID) != 0x33) {
+        return false;
+    }
+    return true;
+}
+
+bool adns9800_init(void) {
     gpio_set_pin_output(ADNS9800_CS_PIN);
 
     spi_init();
@@ -178,6 +185,8 @@ void adns9800_init(void) {
     adns9800_write(REG_LASER_CTRL0, laser_ctrl0 & 0xf0);
 
     adns9800_set_cpi(ADNS9800_CPI);
+
+    return adns9800_check_signature();
 }
 
 config_adns9800_t adns9800_get_config(void) {

drivers/sensors/adns9800.h

@@ -61,9 +61,9 @@ typedef struct {
     int16_t y;
 } report_adns9800_t;
 
-const pointing_device_driver_t adns9800_pointing_device_driver;
+extern const pointing_device_driver_t adns9800_pointing_device_driver;
 
-void              adns9800_init(void);
+bool              adns9800_init(void);
 config_adns9800_t adns9800_get_config(void);
 void              adns9800_set_config(config_adns9800_t);
 uint16_t          adns9800_get_cpi(void);

drivers/sensors/analog_joystick.c

@@ -135,7 +135,7 @@ report_analog_joystick_t analog_joystick_read(void) {
     return report;
 }
 
-void analog_joystick_init(void) {
+bool analog_joystick_init(void) {
     gpio_set_pin_input_high(ANALOG_JOYSTICK_X_AXIS_PIN);
     gpio_set_pin_input_high(ANALOG_JOYSTICK_Y_AXIS_PIN);
 
@@ -152,6 +152,8 @@ void analog_joystick_init(void) {
     maxAxisValues[0] = xOrigin + 100;
     maxAxisValues[1] = yOrigin + 100;
 #endif
+
+    return true;
 }
 
 report_mouse_t analog_joystick_get_report(report_mouse_t mouse_report) {