Satisfaction75 post merge updates

.clangd

@@ -1,4 +1,4 @@
 CompileFlags:
   Add: [-Wno-unknown-attributes, -Wno-maybe-uninitialized, -Wno-unknown-warning-option]
-  Remove: [-W*, -mmcu=*, -mcpu=*, -mfpu=*, -mfloat-abi=*, -mno-unaligned-access, -mno-thumb-interwork, -mcall-prologues]
+  Remove: [-W*, -mcall-prologues]
   Compiler: clang

.editorconfig

@@ -4,39 +4,39 @@
 root = true
 
 [*]
-end_of_line = lf
 indent_style = space
 indent_size = 4
+
+# We recommend you to keep these unchanged
 charset = utf-8
 trim_trailing_whitespace = true
 insert_final_newline = true
 
-[{*.yaml,*.yml}] # To match GitHub Actions formatting
-indent_size = 2
-
 [*.md]
 trim_trailing_whitespace = false
+indent_size = 4
 
-[{Makefile,*.mk}]
+[{qmk,*.py}]
+charset = utf-8
+max_line_length = 200
+
+# Make these match what we have in .gitattributes
+[*.mk]
+end_of_line = lf
 indent_style = tab
 
-# Don't override anything in `lib/`...
-[lib/**]
-indent_style = unset
-indent_size = unset
-tab_width = unset
-end_of_line = unset
-charset = unset
-spelling_language = unset
-trim_trailing_whitespace = unset
-insert_final_newline = unset
-
-# ...except QMK's `lib/python`.
-[{*.py,lib/python/**.py}]
+[Makefile]
 end_of_line = lf
-indent_style = space
-indent_size = 4
-charset = utf-8
-trim_trailing_whitespace = true
-insert_final_newline = true
-max_line_length = 200
+indent_style = tab
+
+[*.sh]
+end_of_line = lf
+
+# The gitattributes file will handle the line endings conversion properly according to the operating system settings for other files
+
+
+# We don't have gitattributes properly for these
+# So if the user have for example core.autocrlf set to true
+# the line endings would be wrong.
+[lib/**]
+end_of_line = unset

.github/workflows/ci_build_major_branch.yml

@@ -1,123 +0,0 @@
-name: CI Build Major Branch
-
-permissions:
-  contents: read
-  actions: write
-
-on:
-  push:
-    branches: [master, develop]
-  workflow_dispatch:
-    inputs:
-      branch:
-        type: choice
-        description: "Branch to build"
-        options: [master, develop]
-
-env:
-  # https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
-  # We've decreased it from 20 to 15 to allow for other GHA to run unimpeded
-  CONCURRENT_JOBS: 15
-
-# Ensure we only have one build running at a time, cancelling any active builds if a new commit is pushed to the respective branch
-concurrency:
-  group: ci_build-${{ github.event.inputs.branch || github.ref_name }}
-  cancel-in-progress: true
-
-jobs:
-  determine_concurrency:
-    name: "Determine concurrency"
-    if: github.repository == 'qmk/qmk_firmware'
-    runs-on: ubuntu-latest
-    container: ghcr.io/qmk/qmk_cli
-
-    outputs:
-      slice_length: ${{ steps.generate_slice_length.outputs.slice_length }}
-
-    steps:
-      - name: Install prerequisites
-        run: |
-          apt-get update
-          apt-get install -y jq
-
-      - name: Disable safe.directory check
-        run: |
-          git config --global --add safe.directory '*'
-
-      - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
-
-      - name: Determine concurrency
-        id: generate_slice_length
-        run: |
-          target_count=$( {
-            qmk find -km default 2>/dev/null
-            qmk find -km via 2>/dev/null
-          } | sort | uniq | wc -l)
-          slice_length=$((target_count / ($CONCURRENT_JOBS - 1))) # Err on the side of caution as we're splitting default and via
-          echo "slice_length=$slice_length" >> $GITHUB_OUTPUT
-
-  build_targets:
-    name: "Compile keymap ${{ matrix.keymap }}"
-    needs: determine_concurrency
-    strategy:
-      fail-fast: false
-      matrix:
-        keymap: [default, via]
-    uses: ./.github/workflows/ci_build_major_branch_keymap.yml
-    with:
-      branch: ${{ inputs.branch || github.ref_name }}
-      keymap: ${{ matrix.keymap }}
-      slice_length: ${{ needs.determine_concurrency.outputs.slice_length }}
-    secrets: inherit
-
-  rollup_tasks:
-    name: "Consolidation"
-    needs: build_targets
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Download firmwares
-        uses: actions/download-artifact@v4
-        with:
-          pattern: firmware-*
-          path: firmwares
-          merge-multiple: true
-
-      - name: Upload to https://ci.qmk.fm/${{ inputs.branch || github.ref_name }}/${{ github.sha }}
-        uses: jakejarvis/s3-sync-action@master
-        with:
-          args: --acl public-read --follow-symlinks --delete
-        env:
-          AWS_S3_BUCKET: ${{ vars.CI_QMK_FM_SPACES_BUCKET }}
-          AWS_ACCESS_KEY_ID: ${{ secrets.CI_QMK_FM_SPACES_KEY }}
-          AWS_SECRET_ACCESS_KEY: ${{ secrets.CI_QMK_FM_SPACES_SECRET }}
-          AWS_REGION: ${{ vars.CI_QMK_FM_SPACES_REGION }}
-          AWS_S3_ENDPOINT: ${{ vars.CI_QMK_FM_SPACES_ENDPOINT }}
-          SOURCE_DIR: firmwares
-          DEST_DIR: ${{ inputs.branch || github.ref_name }}/${{ github.sha }}
-
-      - name: Upload to https://ci.qmk.fm/${{ inputs.branch || github.ref_name }}/latest
-        uses: jakejarvis/s3-sync-action@master
-        with:
-          args: --acl public-read --follow-symlinks --delete
-        env:
-          AWS_S3_BUCKET: ${{ vars.CI_QMK_FM_SPACES_BUCKET }}
-          AWS_ACCESS_KEY_ID: ${{ secrets.CI_QMK_FM_SPACES_KEY }}
-          AWS_SECRET_ACCESS_KEY: ${{ secrets.CI_QMK_FM_SPACES_SECRET }}
-          AWS_REGION: ${{ vars.CI_QMK_FM_SPACES_REGION }}
-          AWS_S3_ENDPOINT: ${{ vars.CI_QMK_FM_SPACES_ENDPOINT }}
-          SOURCE_DIR: firmwares
-          DEST_DIR: ${{ inputs.branch || github.ref_name }}/latest
-
-      - name: Check if failure marker file exists
-        id: check_failure_marker
-        uses: andstor/file-existence-action@v3
-        with:
-          files: firmwares/.failed
-
-      - name: Fail build if needed
-        if: steps.check_failure_marker.outputs.files_exists == 'true'
-        run: |
-          # Exit with failure if the compilation stage failed
-          exit 1

.github/workflows/ci_build_major_branch_keymap.yml

@@ -1,181 +0,0 @@
-name: CI Build Major Branch Keymap
-
-permissions:
-  contents: read
-  actions: write
-
-on:
-  workflow_call:
-    inputs:
-      branch:
-        type: string
-        required: true
-      keymap:
-        type: string
-        required: true
-      slice_length:
-        type: string
-        required: true
-
-jobs:
-  generate_targets:
-    name: "Generate targets (${{ inputs.keymap }})"
-    runs-on: ubuntu-latest
-    container: ghcr.io/qmk/qmk_cli
-
-    outputs:
-      targets: ${{ steps.generate_targets.outputs.targets }}
-
-    steps:
-      - name: Install prerequisites
-        run: |
-          apt-get update
-          apt-get install -y jq
-
-      - name: Disable safe.directory check
-        run: |
-          git config --global --add safe.directory '*'
-
-      - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
-
-      - name: Generate build targets
-        id: generate_targets
-        run: |
-          { # Intentionally use `shuf` here so that we share manufacturers across all build groups -- some have a lot of ARM-based boards which inherently take longer
-            counter=0
-            echo -n '{'
-            qmk find -km ${{ inputs.keymap }} 2>/dev/null | sort | uniq | shuf | xargs -L${{ inputs.slice_length }} | while IFS=$'\n' read target ; do
-                if [ $counter -gt 0 ]; then
-                    echo -n ','
-                fi
-                counter=$((counter+1))
-                printf "\"group %02d\":{" $counter
-                echo -n '"targets":"'
-                echo $target | tr ' ' '\n' | sort | uniq | xargs echo -n
-                echo -n '"}'
-            done
-            echo -n '}'
-          } | sed -e 's@\n@@g' > targets.json
-
-          # Output the target keys as a variable
-          echo "targets=$(jq -c 'keys' targets.json)" >> $GITHUB_OUTPUT
-
-      - name: Upload targets json
-        uses: actions/upload-artifact@v4
-        with:
-          name: targets-${{ inputs.keymap }}
-          path: targets.json
-
-  build_targets:
-    name: "Compile ${{ matrix.target }} (${{ inputs.keymap }})"
-    needs: generate_targets
-    runs-on: ubuntu-latest
-    container: ghcr.io/qmk/qmk_cli
-    continue-on-error: true
-
-    strategy:
-      matrix:
-        target: ${{ fromJson(needs.generate_targets.outputs.targets) }}
-
-    steps:
-      - name: Install prerequisites
-        run: |
-          apt-get update
-          apt-get install -y jq
-
-      - name: Disable safe.directory check
-        run: |
-          git config --global --add safe.directory '*'
-
-      - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
-
-      - name: Get target definitions
-        uses: actions/download-artifact@v4
-        with:
-          name: targets-${{ inputs.keymap }}
-          path: .
-
-      - name: Deploy submodules
-        run: |
-          qmk git-submodule -f
-
-      - name: Dump targets
-        run: |
-          jq -r '.["${{ matrix.target }}"].targets' targets.json | tr ' ' '\n' | sort
-
-      - name: Build targets
-        continue-on-error: true
-        run: |
-          export NCPUS=$(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || getconf _NPROCESSORS_ONLN 2>/dev/null)
-          qmk mass-compile -t -j $NCPUS -e DUMP_CI_METADATA=yes $(jq -r '.["${{ matrix.target }}"].targets' targets.json) || touch .failed
-
-      - name: Upload binaries
-        uses: actions/upload-artifact@v4
-        with:
-          name: firmware-${{ inputs.keymap }}-${{ matrix.target }}
-          if-no-files-found: ignore
-          path: |
-            *.bin
-            *.hex
-            *.uf2
-            .build/failed.*
-            .failed
-
-      - name: Fail build if any group failed
-        run: |
-          # Exit with failure if the compilation stage failed
-          [ ! -f .failed ] || exit 1
-
-  repack_firmware:
-    if: always()
-    name: "Repack artifacts"
-    needs: build_targets
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Checkout QMK Firmware
-        uses: actions/checkout@v4
-
-      - name: Download firmwares
-        uses: actions/download-artifact@v4
-        with:
-          pattern: firmware-${{ inputs.keymap }}-*
-          path: .
-          merge-multiple: true
-
-      - name: Upload all firmwares
-        uses: actions/upload-artifact@v4
-        with:
-          name: firmware-${{ inputs.keymap }}
-          if-no-files-found: ignore
-          path: |
-            *.bin
-            *.hex
-            *.uf2
-            .build/failed.*
-            .failed
-
-      - name: Generate output logs
-        run: |
-          # Generate the step summary markdown
-          ./util/ci/generate_failure_markdown.sh > $GITHUB_STEP_SUMMARY || true
-          # Truncate to a maximum of 1MB to deal with GitHub workflow limit
-          truncate --size='<960K' $GITHUB_STEP_SUMMARY || true
-
-      - name: Delete temporary build artifacts
-        uses: geekyeggo/delete-artifact@v5
-        with:
-          name: |
-            firmware-${{ inputs.keymap }}-*
-            targets-${{ inputs.keymap }}
-
-      - name: 'CI Discord Notification'
-        if: always()
-        working-directory: util/ci/
-        env:
-          DISCORD_WEBHOOK: ${{ secrets.CI_DISCORD_WEBHOOK }}
-        run: |
-          python3 -m pip install -r requirements.txt
-          python3 ./discord-results.py --branch ${{ inputs.branch || github.ref_name }} --keymap ${{ inputs.keymap }} --url ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}

.github/workflows/ci_builds.yml

@@ -0,0 +1,74 @@
+name: CI Builds
+
+permissions:
+  contents: read
+
+on:
+  push:
+    branches: [master, develop]
+  workflow_dispatch:
+    inputs:
+      branch:
+        type: choice
+        description: 'Branch to build'
+        options: [master, develop]
+
+concurrency: ci_build-${{ github.event.inputs.branch || github.ref_name }}
+
+jobs:
+  ci_builds:
+    if: github.repository == 'qmk/qmk_firmware'
+    name: "CI Build"
+    runs-on: self-hosted
+    timeout-minutes: 1380
+
+    strategy:
+      fail-fast: false
+      matrix:
+        keymap: [default, via]
+
+    container: ghcr.io/qmk/qmk_cli
+
+    steps:
+    - name: Disable safe.directory check
+      run : git config --global --add safe.directory '*'
+
+    - uses: actions/checkout@v4
+      with:
+        submodules: recursive
+        ref: ${{ github.event.inputs.branch || github.ref }}
+
+    - name: Install dependencies
+      run: pip3 install -r requirements.txt
+
+    - name: Run `qmk mass-compile` (keymap ${{ matrix.keymap }})
+      run: |
+        export NCPUS=$(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || getconf _NPROCESSORS_ONLN 2>/dev/null)
+        qmk mass-compile -t -j $NCPUS -km ${{ matrix.keymap }} -e DUMP_CI_METADATA=yes || touch .failed
+        # Generate the step summary markdown
+        ./util/ci/generate_failure_markdown.sh > $GITHUB_STEP_SUMMARY || true
+        # Truncate to a maximum of 1MB to deal with GitHub workflow limit
+        truncate --size='<960K' $GITHUB_STEP_SUMMARY || true
+        # Exit with failure if the compilation stage failed
+        [ ! -f .failed ] || exit 1
+
+    - name: 'Upload artifacts'
+      uses: actions/upload-artifact@v4
+      if: always()
+      with:
+        name: artifacts-${{ github.event.inputs.branch || github.ref_name }}-${{ matrix.keymap }}
+        if-no-files-found: ignore
+        path: |
+          *.bin
+          *.hex
+          *.uf2
+          .build/failed.*
+
+    - name: 'CI Discord Notification'
+      if: always()
+      working-directory: util/ci/
+      env:
+        DISCORD_WEBHOOK: ${{ secrets.CI_DISCORD_WEBHOOK }}
+      run: |
+        python3 -m pip install -r requirements.txt
+        python3 ./discord-results.py --branch ${{ github.event.inputs.branch || github.ref_name }} --keymap ${{ matrix.keymap }} --url ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}

.github/workflows/docs.yml

@@ -37,7 +37,7 @@ jobs:
         qmk --verbose generate-docs
 
     - name: Deploy
-      uses: JamesIves/github-pages-deploy-action@v4.6.0
+      uses: JamesIves/github-pages-deploy-action@v4.5.0
       with:
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         BASE_BRANCH: master

.github/workflows/format.yml

@@ -35,9 +35,7 @@ jobs:
 
     - name: Get changed files
       id: file_changes
-      uses: tj-actions/changed-files@v44
-      with:
-        use_rest_api: true
+      uses: tj-actions/changed-files@v42
 
     - name: Run qmk formatters
       shell: 'bash {0}'

.github/workflows/format_push.yml

@@ -47,7 +47,7 @@ jobs:
         git config user.email 'hello@qmk.fm'
 
     - name: Create Pull Request
-      uses: peter-evans/create-pull-request@v6
+      uses: peter-evans/create-pull-request@v5
       if: ${{ github.repository == 'qmk/qmk_firmware'}}
       with:
         token: ${{ secrets.QMK_BOT_TOKEN }}

.github/workflows/lint.yml

@@ -27,9 +27,7 @@ jobs:
 
     - name: Get changed files
       id: file_changes
-      uses: tj-actions/changed-files@v44
-      with:
-        use_rest_api: true
+      uses: tj-actions/changed-files@v42
 
     - name: Print info
       run: |
@@ -64,12 +62,10 @@ jobs:
 
         qmk format-text ${{ steps.file_changes.outputs.all_changed_files}} || true
         for file in ${{ steps.file_changes.outputs.all_changed_files}}; do
-          if [[ -f $file ]]; then
-            if ! git diff --quiet $file; then
-              echo "File '${file}' Requires Formatting"
-              echo "::error file=${file}::Requires Formatting"
-              exit_code=$(($exit_code + 1))
-            fi
+          if ! git diff --quiet $file; then
+            echo "File '${file}' Requires Formatting"
+            echo "::error file=${file}::Requires Formatting"
+            exit_code=$(($exit_code + 1))
           fi
         done
 

.github/workflows/regen_push.yml

@@ -34,7 +34,7 @@ jobs:
         git config user.email 'hello@qmk.fm'
 
     - name: Create Pull Request
-      uses: peter-evans/create-pull-request@v6
+      uses: peter-evans/create-pull-request@v5
       if: ${{ github.repository == 'qmk/qmk_firmware'}}
       with:
         token: ${{ secrets.QMK_BOT_TOKEN }}

builddefs/converters.mk

@@ -5,10 +5,8 @@ ifneq ($(findstring yes, $(CTPC)$(CONVERT_TO_PROTON_C)),)
 $(call CATASTROPHIC_ERROR,The `CONVERT_TO_PROTON_C` and `CTPC` options are now deprecated. `CONVERT_TO=proton_c` should be used instead.)
 endif
 
-ifneq (,$(filter $(MCU),atmega32u4))
-    # TODO: opt in rather than assume everything uses a pro micro
-    PIN_COMPATIBLE ?= promicro
-endif
+# TODO: opt in rather than assume everything uses a pro micro
+PIN_COMPATIBLE ?= promicro
 
 # Remove whitespace from any rule.mk provided vars
 #   - env cannot be overwritten but cannot have whitespace anyway
@@ -18,10 +16,6 @@ ifneq ($(CONVERT_TO),)
     # stash so we can overwrite env provided vars if needed
     ACTIVE_CONVERTER=$(CONVERT_TO)
 
-    ifeq ($(PIN_COMPATIBLE),)
-        $(call CATASTROPHIC_ERROR,Converting to '$(CONVERT_TO)' not possible!)
-    endif
-
     # glob to search each platfrorm and/or check for valid converter
     CONVERTER := $(wildcard $(PLATFORM_PATH)/*/converters/$(PIN_COMPATIBLE)_to_$(CONVERT_TO)/)
     ifeq ($(CONVERTER),)

data/constants/keycodes/extras/keycodes_spanish_latin_america_0.0.1.hjson

@@ -335,9 +335,5 @@
             "key": "ES_CIRC",
             "label": "^",
         }
-        "ALGR(KC_NUHS)": {
-            "key": "ES_GRV",
-            "label": "`",
-        }
     }
 }

docs/__capabilities.md

@@ -1,261 +0,0 @@
-# Documentation Capabilities
-
-This page lays out the capabilities used by the QMK Firmware documentation, in order to aid future transitions to other page generators. Focuses mainly on things other than normal Markdown, as it's assumed that markdown generators should still function accordingly.
-
-## Overall capabilities
-
-Unrelated to styling, high-level tech.
-
-* I18n -- translations to other languages: [_langs.md](_langs.md)
-* Sidebar -- listing of pages by category: [_summary.md](_summary.md)
-* Title anchors -- `:id=some-anchor-name`, used for direct linking to sections
-    * Links to anchors:
-        * Style 1: [early initialization](platformdev_chibios_earlyinit.md?id=board-init)
-        * Style 2: [early initialization](platformdev_chibios_earlyinit.md#board-init)
-        * Links to anchors on the same page, i.e. [Emoji](#emoji)
-* Specifying CNAME for root domain -- `docs.qmk.fm`
-* Moved pages, see `index.html`
-* Text search
-* Footnotes [like this][1]
-
-<!-- Comments should not show up -->
-
-<!-- Nor should
-     multiline
-     
-     comments with
-     
-     newlines show up -->
-     
-     
-### Dividing lines
-
----
-
-<hr>
-
-<hr/>
-
-### Images
-
-![QMK Color Wheel with HSV Values](https://i.imgur.com/vkYVo66.jpg)
-
-<img src="gitbook/images/color-wheel.svg" alt="HSV Color Wheel" width="250"/>
-
-### Lists
-
-Newlines with `<br>`:
-
-Line one<br>
-Line two<br/>
-Line three
-
-Nested dotted:
-
-* The PR is complete and ready to merge
-* GitHub checks for the PR are green whenever possible
-    * A "red" check may be disregarded by maintainers if the items flagged are unrelated to the change proposed in the PR
-        * Modifications to existing files should not need to add license headers to pass lint, for instance.
-        * If it's not directly related to your PR's functionality, prefer avoiding making a change.
-
-Nested dashed:
-
-- The PR is complete and ready to merge
-- GitHub checks for the PR are green whenever possible
-    - A "red" check may be disregarded by maintainers if the items flagged are unrelated to the change proposed in the PR
-        - Modifications to existing files should not need to add license headers to pass lint, for instance.
-        - If it's not directly related to your PR's functionality, prefer avoiding making a change.
-
-Nested numbered:
-
-1. The PR is complete and ready to merge
-1. GitHub checks for the PR are green whenever possible
-    1. A "red" check may be disregarded by maintainers if the items flagged are unrelated to the change proposed in the PR
-        1. Modifications to existing files should not need to add license headers to pass lint, for instance.
-        1. If it's not directly related to your PR's functionality, prefer avoiding making a change.
-        
-Nested mixed:
-
-1. Add it to the schema in `data/schemas/keyboards.jsonschema`
-1. Add a mapping in `data/maps`
-1. (optional and discouraged) Add code to extract/generate it to:
-  * `lib/python/qmk/info.py`
-  * `lib/python/qmk/cli/generate/config_h.py`
-  * `lib/python/qmk/cli/generate/rules_mk.py`
-
-### Emoji :id=emoji
-
-#### Direct:
-
-👍🎉 First off, thanks for taking the time to read this and contribute! 🎉👍
-
-#### As colon-name-colon:
-
-:heavy_check_mark: : works and was tested
-
-:o: : does not apply
-
-:x: : not supported by MCU
-
-### XML Entities
-
-[`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard)  &larr; This is the organization folder, there's no `rules.mk` file
-
-1&ndash;4
-
-Command+<code>&#96;</code>
-
-## Styling
-
-### CSS-ish
-
-<b style="font-size:150%">This is 150% of normal sizing, and bold!</b>
-
-
-### Tables
-
-| Column A | Column B |
-|----------|----------|
-| Left     | Right    |
-
-### Indented sections
-
-> Indent without any sort of marker
-
-?> Query, this?
-
-!> Notification, damnit!
-
-### Keyboard keys
-
-<kbd>,</kbd>
-
-<kbd>Right Alt</kbd>+<kbd>Right Shift</kbd>
-
-1. Click <kbd>File</kbd> > <kbd>New</kbd> > <kbd>Makefile Project with Existing Code</kbd>
-
-1. Click <kbd><kbd>File</kbd> > <kbd>Preferences ></kbd> > <kbd>Settings</kbd> </kbd>
-
-1. Hit Ctrl-<code>&#96;</code> (Grave) to bring up the terminal or go to <kbd><kbd>View</kbd> > <kbd>Terminal</kbd></kbd> (command `workbench.action.terminal.toggleTerminal`). A new terminal will be opened if there isn‘t one already.
-
-   This should start the terminal in the workspace's folder (so the `qmk_firmware` folder), and then you can compile your keyboard. 
-
-
-### Code Blocks
-
-Inline code with tag: <code>test</code>
-
-Inline code with backticks: `test`
-
-    This is preformatted
-    Indented by 4 spaces
-    The letters lined up
-
-```c
-int c_code(void) {
-    return -1;
-}
-```
-
-```makefile
-ifeq ($(BUILD),)
-     CHUNDER_REQUIRED = yes
-endif
-```
-
-```python
-from pathlib import Path
-
-p = Path('/path/to/qmk_firmware')
-```
-
-```json
-{
-    "a": "b",
-    "c": 4,
-    "d": {
-        "e": [
-            0, 1, 2, 3
-        ]
-    }
-}
-```
-
-```diff
- #undef RGBLIGHT_LED_COUNT
-+#undef RGBLIGHT_EFFECT_STATIC_GRADIENT
-+#undef RGBLIGHT_EFFECT_RAINBOW_SWIRL
- #define RGBLIGHT_LED_COUNT 12
- #define RGBLIGHT_HUE_STEP 8
- #define RGBLIGHT_SAT_STEP 8
-```
-
-Indented code as part of a list:
-
-* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (recommended GUI)
-* [Teensy Loader](https://www.pjrc.com/teensy/loader.html)
-* [Teensy Loader Command Line](https://www.pjrc.com/teensy/loader_cli.html) / `:teensy` target in QMK (recommended command line)
-  ```
-  teensy_loader_cli -v -mmcu=<mcu> <filename>
-  ```
-
-
-### Sub/Superscript
-
-<sub>This is subscripted, apparently.</sub>
-
-<sup>This is superscripted, apparently.</sup>
-
-I<sup>2</sup>C
-
-T<sub>0H</sub>, T<sub>0L</sub>
-
-### Tabs
-
-Tabs are based on section headers, with `**` enclosing the tab title.
-
-<!-- tabs:start -->
-
-#### ** Tab one **
-
-Content one
-
-<!-- tabs:start -->
-
-##### ** Nested one **
-
-Nested content one
-
-##### ** Nested two **
-
-Nested content two
-
-<!-- tabs:end -->
-
-#### ** Tab two **
-
-Content two
-
-#### ** Tab three **
-
-Content three
-
-<!-- tabs:end -->
-
-## Details sections
-
-Expandable:
-
-<details>
-    <summary>Some summary text that shows up before expanding</summary>
-
-!> Embedded notification!
-
-This is some inner content.
-</details>
-
-  [1]: https://en.wikipedia.org/wiki/Eclipse_(software)
-
-## Embed
-
-[example embed](__capabilities_inc.md ':include')

docs/__capabilities_inc.md

@@ -1 +0,0 @@
-Lorem ipsum dolor sit amet.

docs/_summary.md

@@ -138,7 +138,7 @@
   * Breaking Changes
     * [Overview](breaking_changes.md)
     * [My Pull Request Was Flagged](breaking_changes_instructions.md)
-    * [Most Recent ChangeLog](ChangeLog/20240225.md "QMK v0.24.0 - 2024 Feb 25")
+    * [Most Recent ChangeLog](ChangeLog/20231126.md "QMK v0.23.0 - 2023 Nov 26")
     * [Past Breaking Changes](breaking_changes_history.md)
 
   * C Development

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?
 
-* [2024 Feb 25](ChangeLog/20240225.md)
 * [2023 Nov 26](ChangeLog/20231126.md)
 * [2023 Aug 27](ChangeLog/20230827.md)
+* [2023 May 28](ChangeLog/20230528.md)
 * [Older Breaking Changes](breaking_changes_history.md)
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for May 26, 2024.
+The next Breaking Change is scheduled for November 26, 2023.
 
 ### Important Dates
 
-* 2024 Feb 25 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
-* 2024 Apr 28 - `develop` closed to new PRs.
-* 2024 Apr 28 - Call for testers.
-* 2024 May 5 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
-* 2024 May 19 - `develop` is locked, only critical bugfix PRs merged.
-* 2024 May 23 - `master` is locked, no PRs merged.
-* 2024 May 26 - Merge `develop` to `master`.
-* 2024 May 26 - `master` is unlocked. PRs can be merged again.
+* 2023 Nov 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
+* 2024 Jan 28 - `develop` closed to new PRs.
+* 2024 Jan 28 - Call for testers.
+* 2024 Feb 4 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
+* 2024 Feb 18 - `develop` is locked, only critical bugfix PRs merged.
+* 2024 Feb 22 - `master` is locked, no PRs merged.
+* 2024 Feb 25 - Merge `develop` to `master`.
+* 2024 Feb 25 - `master` is unlocked. PRs can be merged again.
 
 ## What changes will be included?
 
@@ -48,7 +48,7 @@ Criteria for acceptance:
 
 Strongly suggested:
 
-* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20240526`.
+* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20240225`.
     * This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PRs ID.
     * One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.
 

docs/breaking_changes_history.md

@@ -2,7 +2,6 @@
 
 This page links to all previous changelogs from the QMK Breaking Changes process.
 
-* [2024 Feb 25](ChangeLog/20240225.md) - version 0.24.0
 * [2023 Nov 26](ChangeLog/20231126.md) - version 0.23.0
 * [2023 Aug 27](ChangeLog/20230827.md) - version 0.22.0
 * [2023 May 28](ChangeLog/20230528.md) - version 0.21.0

docs/cli_commands.md

@@ -322,18 +322,6 @@ Creates a keymap.json from a keymap.c.
 qmk c2json -km KEYMAP -kb KEYBOARD [-q] [--no-cpp] [-o OUTPUT] filename
 ```
 
-**Examples**:
-
-```
-qmk c2json -km default -kb handwired/dactyl_promicro
-```
-
-or with filename:
-
-```
-qmk c2json keyboards/handwired/dactyl_promicro/keymaps/default/keymap.c
-```
-
 ## `qmk lint`
 
 Checks over a keyboard and/or keymap and highlights common errors, problems, and anti-patterns.

docs/driver_installation_zadig.md

@@ -70,13 +70,13 @@ The device name here is the name that appears in Zadig, and may not be what the
 
 |Bootloader    |Device Name                   |VID/PID       |Driver |
 |--------------|------------------------------|--------------|-------|
-|`atmel-dfu`   |ATmega16u2 DFU                |`03EB:2FEF`   |WinUSB |
-|`atmel-dfu`   |ATmega32U2 DFU                |`03EB:2FF0`   |WinUSB |
-|`atmel-dfu`   |ATm16U4 DFU V1.0.2            |`03EB:2FF3`   |WinUSB |
-|`atmel-dfu`   |ATm32U4DFU                    |`03EB:2FF4`   |WinUSB |
-|`atmel-dfu`   |*none* (AT90USB64)            |`03EB:2FF9`   |WinUSB |
-|`atmel-dfu`   |AT90USB128 DFU                |`03EB:2FFB`   |WinUSB |
-|`qmk-dfu`     |(keyboard name) Bootloader    |As `atmel-dfu`|WinUSB |
+|`atmel-dfu`   |ATmega16u2 DFU                |`03EB:2FEF`   |libusb0|
+|`atmel-dfu`   |ATmega32U2 DFU                |`03EB:2FF0`   |libusb0|
+|`atmel-dfu`   |ATm16U4 DFU V1.0.2            |`03EB:2FF3`   |libusb0|
+|`atmel-dfu`   |ATm32U4DFU                    |`03EB:2FF4`   |libusb0|
+|`atmel-dfu`   |*none* (AT90USB64)            |`03EB:2FF9`   |libusb0|
+|`atmel-dfu`   |AT90USB128 DFU                |`03EB:2FFB`   |libusb0|
+|`qmk-dfu`     |(keyboard name) Bootloader    |As `atmel-dfu`|libusb0|
 |`halfkay`     |*none*                        |`16C0:0478`   |HidUsb |
 |`caterina`    |Pro Micro 3.3V                |`1B4F:9203`   |usbser |
 |`caterina`    |Pro Micro 5V                  |`1B4F:9205`   |usbser |

docs/feature_tri_layer.md

@@ -45,4 +45,4 @@ Eg, if you wanted to set the "Adjust" layer to be layer 5, you'd add this to you
 | `get_tri_layer_upper_layer()`                | Gets the current "upper" layer.                 |
 | `get_tri_layer_adjust_layer()`               | Gets the current "adjust" layer.                |
 
-!> Note: these settings are not persistent, and will be reset to the default on power loss or power cycling of the controller.
+!> Note: these settings are not persisent, and will be reset to the default on power loss or power cycling of the controller.

docs/flashing.md

@@ -236,7 +236,7 @@ Flashing sequence:
 
 ## STM32/APM32 DFU
 
-All USB-capable STM32 and APM32 MCUs, except for a small handful (such as STM32F103 -- see the [STM32duino section](#stm32duino)) come preloaded with a factory bootloader that cannot be modified nor deleted.
+All STM32 and APM32 MCUs, except for F103 (see the [STM32duino section](#stm32duino)) come preloaded with a factory bootloader that cannot be modified nor deleted.
 
 To ensure compatibility with the STM32-DFU bootloader, make sure this block is present in your `rules.mk` (optionally with `apm32-dfu` instead):
 
@@ -464,4 +464,4 @@ CLI Flashing sequence:
 3. Flash via QMK CLI eg. `qmk flash --keyboard handwired/onekey/rpi_pico --keymap default`
 4. Wait for the keyboard to become available
 
-<sup>1</sup>: This works only if the controller has been flashed with QMK Firmware with `RP2040_BOOTLOADER_DOUBLE_TAP_RESET` defined.
+<sup>1</sup>: This works only if QMK was compiled with `RP2040_BOOTLOADER_DOUBLE_TAP_RESET` defined.

docs/getting_started_introduction.md

@@ -4,7 +4,7 @@ This page attempts to explain the basic information you need to know to work wit
 
 ## Basic QMK Structure
 
-QMK is a fork of [Jun Wako](https://github.com/tmk)'s [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk_core` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `keyboards` folder.
+QMK is a fork of [Jun Wako](https://github.com/tmk)'s [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk_core` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders.
 
 ### Userspace Structure
 

docs/hand_wire.md

@@ -175,7 +175,7 @@ As you move along, be sure that the controller is staying in place - recutting a
 
 From here, you should have a working keyboard once you program a firmware.
 
-Simple firmware can be created easily using the [Keyboard Firmware Builder](https://kbfirmware.com/) website.  Recreate your layout using [Keyboard Layout Editor](https://www.keyboard-layout-editor.com), import it and recreate the matrix (if not already done as part of [planning the matrix](#planning-the-matrix)).
+Simple firmware can be created easily using the [Keyboard Firmware Builder](https://kbfirmware.com/) website.  Recreate your layout using [Keyboard Layout Editor](https://www.keyboard-layout-editor.com), import it and recreate the matrix (if not already done as part of [planning the matrix](#planning-the-matrix).
 
 Go through the rest of the tabs, assigning keys until you get to the last one where you can compile and download your firmware.  The .hex file can be flashed straight onto your keyboard, or for advanced functionality, compiled locally after [Setting up Your Environment](newbs_getting_started.md).
 

docs/newbs.md

@@ -7,7 +7,7 @@ QMK tries to put a lot of power into your hands by making easy things easy, and
 Not sure if your keyboard can run QMK? If it's a mechanical keyboard you built yourself chances are good it can. We support a [large number of hobbyist boards](https://qmk.fm/keyboards/). If your current keyboard can't run QMK there are a lot of choices out there for boards that do.
 
 ?> **Is This Guide For Me?**<br>
-If the thought of programming intimidates you, please [take a look at our online GUI](newbs_building_firmware_configurator.md) instead.
+If the thought of programming intimidates you, please [take a look at our online GUI](newbs_building_firmware_configurator.md) instead.</div>
 
 ## Overview
 

docs/other_vscode.md

@@ -117,77 +117,3 @@ Using the [standard `compile_commands.json` database](https://clang.llvm.org/doc
 1. Start typing `clangd: Restart Language Server` and select it when it appears.
 
 Now you're ready to code QMK Firmware in VS Code!
-
-# Debugging ARM MCUs with Visual Studio Code
-
-**...and a Black Magic Probe.**
-
-Visual Studio Code has the ability to debug applications, but requires some configuration in order to get it to be able to do so for ARM targets.
-
-This documentation describes a known-working configuration for setting up the use of a Black Magic Probe to debug using VS Code.
-
-It is assumed that you've correctly set up the electrical connectivity of the Black Magic Probe with your MCU. Wiring up `NRST`, `SWDIO`, `SWCLK`, and `GND` should be enough.
-
-Install the following plugin into VS Code:
-
-* [Cortex-Debug](https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug) - 
-  This adds debugger support for ARM Cortex targets to VS Code.
-
-A debugging target for the MCU for your board needs to be defined, and can be done so by adding the following to a `.vscode/launch.json` file:
-
-```json
-{
-  // Use IntelliSense to learn about possible attributes.
-  // Hover to view descriptions of existing attributes.
-  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
-  "version": "0.2.0",
-  "configurations": [
-    {
-      "name": "Black Magic Probe (OneKey Proton-C)",
-      "type": "cortex-debug",
-      "request": "launch",
-      "cwd": "${workspaceRoot}",
-      "executable": "${workspaceRoot}/.build/handwired_onekey_proton_c_default.elf",
-      "servertype": "bmp",
-      "BMPGDBSerialPort": "COM4",
-      "svdFile": "Q:\\svd\\STM32F303.svd",
-      "device": "STM32F303",
-      "v1": false,
-      "windows": {
-        "armToolchainPath": "C:\\QMK_MSYS\\mingw64\\bin"
-      }
-    }
-  ]
-}
-```
-
-You'll need to perform some modifications to the file above in order to target your specific device:
-
-* `"name"`: Can be anything, but if you're debugging multiple targets you'll want something descriptive here.
-* `"cwd"`: The path to the QMK Firmware repository root directory -- _if using the `.vscode` directory existing in the `qmk_firmware` git repository, the default above should be correct_
-* `"executable"`: The path to the `elf` file generated as part of the build for your keyboard -- _exists in `<qmk_firmware>/.build`_
-* `"BMPGDBSerialPort"`: The `COM` port under Windows, or the `/dev/...` path for Linux/macOS. Two serial port devices will be created -- the Black Magic Probe debug port is *usually* the first. If it doesn't work, try the second.
-* `"svdFile"`: _[Optional]_ The path to the SVD file that defines the register layout for the MCU -- the appropriate file can be downloaded from the [cmsis-svd repository](https://github.com/posborne/cmsis-svd/tree/master/data/STMicro)
-* `"device"`: The name of the MCU, which matches the `<name>` tag at the top of the downloaded `svd` file.
-* `"armToolchainPath"`: _[Optional]_ The path to the ARM toolchain installation location on Windows -- under normal circumstances Linux/macOS will auto-detect this correctly and will not need to be specified. 
-
-!> Windows builds of QMK Firmware are generally compiled using QMK MSYS, and the path to gdb's location (`C:\\QMK_MSYS\\mingw64\\bin`) needs to be specified under `armToolchainPath` for it to be detected. You may also need to change the GDB path to point at `C:\\QMK_MSYS\\mingw64\\bin\\gdb-multiarch.exe` in the VSCode Cortex-Debug user settings: ![VSCode Settings](https://i.imgur.com/EGrPM1L.png)
-
-Optionally, the following modifications should also be made to the keyboard's `rules.mk` file to disable optimisations -- not strictly required but will ensure breakpoints and variable viewing works correctly:
-```makefile
-# Disable optimisations for debugging purposes
-LTO_ENABLE = no
-OPT = g
-DEBUG = 3
-```
-
-At this point, you should build and flash your firmware through normal methods (`qmk compile ...` and `qmk flash ...`).
-
-Once completed, you can:
-* Switch to the debug view in VS Code (in the sidebar, the Play button with a bug next to it)
-* Select the newly-created debug target in the dropdown at the top of the sidebar
-* Click the green play button next to the dropdown
-
-VS Code's debugger will then start executing the compiled firmware on the MCU.
-
-At this stage, you should have full debugging set up, with breakpoints and variable listings working!

docs/pr_checklist.md

@@ -9,7 +9,6 @@ If there are any inconsistencies with these recommendations, you're best off [cr
 - PR should be submitted using a non-`master` branch on the source repository
     - this does not mean you target a different branch for your PR, rather that you're not working out of your own master branch
     - if submitter _does_ use their own `master` branch, they'll be given a link to the ["how to git"](newbs_git_using_your_master_branch.md) page after merging -- (end of this document will contain the contents of the message)
-    - Note, frequently merging upstream with your branch is not needed and is discouraged. Valid reason for updating your branch may be resolving merge conflicts and pulling in new changes relevant to your PR.
 - PRs should contain the smallest amount of modifications required for a single change to the codebase
     - multiple keyboards at the same time is not acceptable
     - **the smaller the PR, the higher likelihood of a quicker review, higher likelihood of quicker merge, and less chance of conflicts**
@@ -44,10 +43,10 @@ If there are any inconsistencies with these recommendations, you're best off [cr
 
 - PRs for vendor specific keymaps will be permitted. The naming convention for these should be `default_${vendor}`, `via_${vendor}` i.e. `via_clueboard`.
     - vendor specific keymaps do not necessarily need to be "vanilla" and can be more richly featured than `default` or `via` stock keymaps.
-- `#include QMK_KEYBOARD_H` preferred to including specific board files
+- #include QMK_KEYBOARD_H preferred to including specific board files
 - prefer layer enums to #defines
-- custom keycode enums must have first entry = `QK_USER`
-- some care with spacing (e.g., alignment on commas or first char of keycodes) makes for a much nicer-looking keymap. Spaces are preferred to tabs
+- custom keycode enums must have first entry = SAFE_RANGE
+- some care with spacing (e.g., alignment on commas or first char of keycodes) makes for a much nicer-looking keymap
 
 ## Keyboard PRs
 
@@ -82,8 +81,6 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
       - Encoder Configuration
       - Bootmagic Configuration
       - LED Indicator Configuration
-      - RGB Light Configuration
-      - RGB Matrix Configuration
     - Run `qmk format-json` on this file before submitting your PR. Be sure to append the `-i` flag to directly modify the file, or paste the outputted code into the file. 
 - `readme.md`
     - must follow the [template](https://github.com/qmk/qmk_firmware/blob/master/data/templates/keyboard/readme.md)
@@ -93,7 +90,8 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
     - a picture about the keyboard and preferably about the PCB, too
         - images are not to be placed in the `qmk_firmware` repository
         - images should be uploaded to an external image hosting service, such as [imgur](https://imgur.com/).
-        - image links should link directly to the image, not a "preview" -- i.e. [https://imgur.com/vqgE7Ok](https://imgur.com/vqgE7Ok) should be [https://i.imgur.com/vqgE7Ok.jpg](https://i.imgur.com/vqgE7Ok.jpg) when using imgur
+        - if imgur is used, images should be resized appropriately: append "h" to the image url i.e. [https://i.imgur.com/vqgE7Ok.jpg](https://i.imgur.com/vqgE7Ok.jpg) becomes [https://i.imgur.com/vqgE7Ok**h**.jpg](https://i.imgur.com/vqgE7Okh.jpg)
+        - image links should link directly to the image, not a "preview" -- i.e. [https://imgur.com/vqgE7Ok](https://imgur.com/vqgE7Ok) should be [https://i.imgur.com/vqgE7Okh.jpg](https://i.imgur.com/vqgE7Okh.jpg) when using imgur
 - `rules.mk`
     - removed `MIDI_ENABLE`, `FAUXCLICKY_ENABLE` and `HD44780_ENABLE`
     - modified `# Enable Bluetooth with the Adafruit EZ-Key HID` -> `# Enable Bluetooth`
@@ -148,13 +146,6 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
   - For instance, only `wilba_tech` boards shall include `keyboards/wilba_tech/wt_main.c` and  `keyboards/wilba_tech/wt_rgb_backlight.c`. But including `drivers/sensors/pmw3360.c` is absolutely fine for any and all boards that require it.
   - Code that needs to be used by multiple boards is a candidate for core code changes, and should be separated out.
 
-Wireless-capable boards:
-- Given license abuse from vendors, QMK does not accept any vendor PRs for wireless- or Bluetooth-capable keyboards without wireless and/or Bluetooth code
-    - Historically, vendors have done this in bad faith in order to attain downstream VIA compatibility with no intention of releasing wireless sources
-    - QMK's license, the GPL2+, requires full source disclosure for any distributed binary -- including full sources for any keyboard shipped by vendors containing QMK and/or firmware-side VIA code
-    - If a vendor's wireless-capable keyboard PR submission is lacking wireless capability, then the PR will be left on-hold and unmergeable until wireless bindings are provided
-    - If a vendor's wireless-capable keyboard is merged into QMK before it's known that the board is wireless, then all existing and future PRs from the same vendor will be put on hold until wireless bindings for the offending keyboard are provided
-
 Also, specific to ChibiOS:
 - **strong** preference to using existing ChibiOS board definitions.
     - a lot of the time, an equivalent Nucleo board can be used with a different flash size or slightly different model in the same family
@@ -213,7 +204,7 @@ Additionally, PR reviews are something that is done in our free time. We are not
 ## Example GPLv2 Header
 
 ```
-/* Copyright 2024 Your Name (@yourgithub)
+/* Copyright 2021 Your Name (@yourgithub)
  *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -233,6 +224,6 @@ Additionally, PR reviews are something that is done in our free time. We are not
 Or, optionally, using [SPDX identifier](https://spdx.org/licenses/) instead:
 
 ```
-// Copyright 2024 Your Name (@yourgithub)
+// Copyright 2021 Your Name (@yourgithub)
 // SPDX-License-Identifier: GPL-2.0-or-later
 ```

docs/serial_driver.md

@@ -1,6 +1,6 @@
 # 'serial' Driver
 
-The Serial driver powers the [Split Keyboard](feature_split_keyboard.md) feature. Several implementations are available that cater to the platform and capabilites of MCU in use. Note that none of the drivers support split keyboards with more than two halves.
+The serial driver powers the [Split Keyboard](feature_split_keyboard.md) feature. Several implementations are available, depending on the platform of your split keyboard. Note that none of the drivers support split keyboards with more than two halves.
 
 | Driver                                  | AVR                | ARM                | Connection between halves                                                                     |
 | --------------------------------------- | ------------------ | ------------------ | --------------------------------------------------------------------------------------------- |
@@ -14,7 +14,7 @@ The Serial driver powers the [Split Keyboard](feature_split_keyboard.md) feature
 
 ## Bitbang
 
-This is the Default driver, absence of configuration assumes this driver. It works by [bit banging](https://en.wikipedia.org/wiki/Bit_banging) a GPIO pin using the CPU. It is therefore not as efficient as a dedicated hardware peripheral, which the Half-duplex and Full-duplex drivers use.
+This is the Default driver, the absence of configuration assumes this driver. It works by [bit banging](https://en.wikipedia.org/wiki/Bit_banging) a GPIO pin using the CPU. It is therefore not as efficient as a dedicated hardware peripheral, which the Half-duplex and Full-duplex drivers use.
 
 !> On ARM platforms the bitbang driver causes connection issues when using it together with the bitbang WS2812 driver. Choosing alternate drivers for both serial and WS2812 (instead of bitbang) is strongly recommended.
 
@@ -31,7 +31,7 @@ This is the Default driver, absence of configuration assumes this driver. It wor
 +-------+                 +-------+
 ```
 
-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 simple TRS or USB cable provides enough conductors for this driver to work. 
 
 ### Setup
 
@@ -57,7 +57,7 @@ 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 this driver or the Full-duplex driver whenever possible.
 
 ### Pin configuration
 
@@ -74,13 +74,11 @@ 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. 
-
-!> ***Note:*** A pull-up resistor isn't required for RP2040 controllers configured with PIO subsystem.
+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. Take care that the pin you chose can act as the TX pin of the USART peripheral. A simple TRS or USB cable provides enough conductors for this driver to work. As the split connection is configured to work 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.
 
 ### Setup
 
-To use the Half-duplex driver follow these steps to activate it. If you target the Raspberry Pi RP2040 PIO implementation, start at step 2.
+To use the Half-duplex driver follow these steps to activate it. If you target the Raspberry Pi RP2040 PIO implementation skip step 1.
 
 1. Change the `SERIAL_DRIVER` to `usart` in your keyboards `rules.mk` file:
 
@@ -88,9 +86,7 @@ To use the Half-duplex driver follow these steps to activate it. If you target t
 SERIAL_DRIVER = usart
 ```
 
-Skip to step 3.
-
-2. (RP2040 + PIO only!) Change the `SERIAL_DRIVER` to `vendor` in your keyboards `rules.mk` file:
+2. (RP2040 PIO only!) Change the `SERIAL_DRIVER` to `vendor` in your keyboards `rules.mk` file:
 
 ```make
 SERIAL_DRIVER = vendor
@@ -109,13 +105,13 @@ For STM32 MCUs several GPIO configuration options can be changed as well. See th
 #define SERIAL_USART_TX_PAL_MODE 7 // Pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 7
 ```
 
-4. Decide either for `SERIAL`, `SIO`, or `PIO` subsystem. See section ["Choosing a driver subsystem"](#choosing-a-driver-subsystem).
+4. Decide either for `SERIAL`, `SIO` or `PIO` subsystem, see the section ["Choosing a driver subsystem"](#choosing-a-driver-subsystem).
 
 <hr>
 
 ## USART Full-duplex
 
-Targeting ARM boards based on ChibiOS where communication is offloaded to an USART hardware device. The advantages over bitbanging are fast, accurate timings and reduced CPU usage; therefore it is advised to choose this driver over all others where possible. Due to its internal design Full-duplex is slightly more efficient than the Half-duplex driver, but Full-duplex should be primarily chosen if Half-duplex operation is not supported by the controller's USART peripheral.
+Targeting ARM boards based on ChibiOS where communication is offloaded to an USART hardware device. The advantages over bitbanging are fast, accurate timings and reduced CPU usage. Therefore it is advised to choose this driver or the Full-duplex driver whenever possible. Due to its internal design it is slightly more efficient then the Half-duplex driver, but it should be primarily chosen if Half-duplex operation is not supported by the USART peripheral.
 
 ### Pin configuration
 
@@ -133,13 +129,13 @@ Targeting ARM boards based on ChibiOS where communication is offloaded to an USA
 +-------+                 +-------+
 ```
 
-Two GPIO pins are needed for the Full-duplex driver, as two distinct wires are used for receiving and transmitting data. The pin transmitting data is the `TX` pin and refereed to as the `SERIAL_USART_TX_PIN`, the pin receiving data is the `RX` pin and refereed to as the `SERIAL_USART_RX_PIN` in this configuration. Please note that `TX` pin of the master half has to be connected with the `RX` pin of the slave half and the `RX` pin of the master half has to be connected with the `TX` pin of the slave half! Usually this pin swap has to be done outside of the MCU e.g. with cables or on the PCB. Some MCUs like the STM32F303 used on the Proton-C allow this pin swap directly inside the MCU. A TRRS or USB cable provides enough conductors for this driver to function.
+Two GPIO pins are needed for the Full-duplex driver, as two distinct wires are used for receiving and transmitting data. The pin transmitting data is the `TX` pin and refereed to as the `SERIAL_USART_TX_PIN`, the pin receiving data is the `RX` pin and refereed to as the `SERIAL_USART_RX_PIN` in this configuration. Please note that `TX` pin of the master half has to be connected with the `RX` pin of the slave half and the `RX` pin of the master half has to be connected with the `TX` pin of the slave half! Usually this pin swap has to be done outside of the MCU e.g. with cables or on the PCB. Some MCUs like the STM32F303 used on the Proton-C allow this pin swap directly inside the MCU. A simple TRRS or USB cable provides enough conductors for this driver to work.
 
-To use this driver the USART peripherals `TX` and `RX` pins must be configured with the correct Alternate-functions. If you are using a Proton-C development board everything is already setup, same is true for STM32F103 MCUs. For MCUs which are using a modern flexible GPIO configuration you have to specify these by setting `SERIAL_USART_TX_PAL_MODE` and `SERIAL_USART_RX_PAL_MODE`. Refer to the corresponding datasheets of your MCU or find those settings in the section ["Alternate Functions for selected STM32 MCUs"](#alternate-functions-for-selected-stm32-mcus).
+To use this driver the usart peripherals `TX` and `RX` pins must be configured with the correct Alternate-functions. If you are using a Proton-C everything is already setup, same is true for STM32F103 MCUs. For MCUs which are using a modern flexible GPIO configuration you have to specify these by setting `SERIAL_USART_TX_PAL_MODE` and `SERIAL_USART_RX_PAL_MODE`. Refer to the corresponding datasheets of your MCU or find those settings in the section ["Alternate Functions for selected STM32 MCUs"](#alternate-functions-for-selected-stm32-mcus).
 
 ### Setup
 
-To use the Full-duplex driver follow these steps to activate it. If you target the Raspberry Pi RP2040 PIO implementation, start at step 2
+To use the Full-duplex driver follow these steps to activate it. If you target the Raspberry Pi RP2040 PIO implementation skip step 1.
 
 1. Change the `SERIAL_DRIVER` to `usart` in your keyboards `rules.mk` file:
 
@@ -147,9 +143,7 @@ To use the Full-duplex driver follow these steps to activate it. If you target t
 SERIAL_DRIVER = usart
 ```
 
-Skip to step 3
-
-2. (RP2040 + PIO only!) Change the `SERIAL_DRIVER` to `vendor` in your keyboards `rules.mk` file:
+2. (RP2040 PIO only!) Change the `SERIAL_DRIVER` to `vendor` in your keyboards `rules.mk` file:
 
 ```make
 SERIAL_DRIVER = vendor
@@ -171,7 +165,7 @@ For STM32 MCUs several GPIO configuration options, including the ability for `TX
 #define SERIAL_USART_TX_PAL_MODE 7 // Pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 7
 ```
 
-4. Decide either for `SERIAL`, `SIO`, or `PIO` subsystem. See section ["Choosing a driver subsystem"](#choosing-a-driver-subsystem).
+1. Decide either for `SERIAL`, `SIO` or `PIO` subsystem, see the section ["Choosing a driver subsystem"](#choosing-a-driver-subsystem).
 
 <hr>
 
@@ -231,7 +225,7 @@ Just below `#include_next <mcuconf.h>` add:
 
 Where 'n' matches the peripheral number of your selected USART on the MCU.
 
-3. In the keyboard's `config.h` file: override the default USART `SIO` driver if you use a USART peripheral that does not belong to the default selected `SIOD1` driver. For instance, if you selected `STM32_SERIAL_USE_USART3` the matching driver would be `SIOD3`.
+3. In you keyboards `config.h`: override the default USART `SIO` driver if you use a USART peripheral that does not belong to the default selected `SIOD1` driver. For instance, if you selected `STM32_SERIAL_USE_USART3` the matching driver would be `SIOD3`.
 
 ```c
  #define SERIAL_USART_DRIVER SIOD3
@@ -239,9 +233,9 @@ Where 'n' matches the peripheral number of your selected USART on the MCU.
  
 ### The `PIO` driver
 
-The `PIO` subsystem is a Raspberry Pi RP2040 specific implementation, using an integrated PIO peripheral and is therefore only available on this MCU. Because of the flexible nature of PIO peripherals, **any** GPIO pin can be used as a `TX` or `RX` pin. Half-duplex and Full-duplex operation modes are fully supported with this driver. Half-duplex uses the built-in pull-ups and GPIO manipulation of the RP2040 to drive the line high by default, thus an external pull-up resistor **is not required**.
+The `PIO` subsystem is a Raspberry Pi RP2040 specific implementation, using the integrated PIO peripheral and is therefore only available on this MCU. Because of the flexible nature of the PIO peripherals, **any** GPIO pin can be used as a `TX` or `RX` pin. Half-duplex and Full-duplex operation is fully supported. The Half-duplex operation mode uses the built-in pull-ups and GPIO manipulation on the RP2040 to drive the line high by default. An external pull-up is therefore not necessary.
 
-Optionally, the PIO peripheral utilized for split communication can be changed with the following define in config.h:
+You may optionally switch the PIO peripheral used with the following define in config.h:
 ```c
 #define SERIAL_PIO_USE_PIO1 // Force the usage of PIO1 peripheral, by default the Serial implementation uses the PIO0 peripheral
 ```

docs/squeezing_avr.md

@@ -2,7 +2,7 @@
 
 AVR is severely resource-constrained, and as QMK continues to grow, it is approaching a point where support for AVR may need to be moved to legacy status as newer development is unable to fit into those constraints.
 
-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.
+However, if you need to reduce the compiled size of your firmware, 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: 
@@ -91,19 +91,15 @@ Or if you're not using layers at all, you can outright remove the functionality
 
 There are two `__attribute__ ((weak))` placeholder functions available to customize magic keycodes. If you are not using that feature to swap keycodes, such as backslash with backspace, add the following to your `keymap.c` or user space code:
 ```c
-#ifndef MAGIC_ENABLE
 uint16_t keycode_config(uint16_t keycode) {
     return keycode;
 }
-#endif
 ```
 Likewise, if you are not using magic keycodes to swap modifiers, such as Control with GUI, add the following to your `keymap.c` or user space code:
 ```c
-#ifndef MAGIC_ENABLE
 uint8_t mod_config(uint8_t mod) {
     return mod;
 }
-#endif
 ```
 Both of them will overwrite the placeholder functions with a simple return statement to reduce firmware size.
 
@@ -201,7 +197,11 @@ For RGB Matrix, these need to be explicitly enabled as well. To disable any that
 
 # Final Thoughts
 
-If you've done all of this, and your firmware is still too large, then it is time to consider making the switch to ARM. There are a number of Pro Micro replacements with an ARM controller:
+If you've done all of this, and your firmware is still too large, then it's time. It's time to consider making the switch to ARM. Unfortunately, right now is the worst possible time for that, due to the silicon shortage, and supply chain issues. Getting an ARM chip is difficult, at best, and significantly overpriced, at worst.
+ -- Drashna
+
+That said, there are a number of Pro Micro replacements with ARM controllers: 
+* [Proton C](https://qmk.fm/proton-c/) (out of stock)
 * [Bonsai C](https://github.com/customMK/Bonsai-C) (Open Source, DIY/PCBA)
 * [STeMCell](https://github.com/megamind4089/STeMCell) (Open Source, DIY/PCBA)
 * [Adafruit KB2040](https://learn.adafruit.com/adafruit-kb2040)
@@ -212,7 +212,6 @@ If you've done all of this, and your firmware is still too large, then it is tim
 * [Liatris](https://splitkb.com/products/liatris)
 * [Imera](https://splitkb.com/products/imera)
 * [Michi](https://github.com/ci-bus/michi-promicro-rp2040)
-* [Proton C](https://qmk.fm/proton-c/) (out of stock)
 
 There are other, non-Pro Micro compatible boards out there. The most popular being:
 * [WeAct Blackpill F411](https://www.aliexpress.com/item/1005001456186625.html) (~$6 USD)

keyboards/ah/haven60/haven60.c

@@ -1,46 +0,0 @@
-/* Copyright 2023 CMM.S Freather
- *
- * This program is free software: you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation, either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include "quantum.h"
-
-const rgblight_segment_t PROGMEM my_capslock_layer[] = RGBLIGHT_LAYER_SEGMENTS(
-    {0, 13, HSV_WHITE}
-);
-
-const rgblight_segment_t PROGMEM my_capsoff_layer[] = RGBLIGHT_LAYER_SEGMENTS(
-    {0, 1, HSV_BLACK}
-);
-
-// Now define the array of layers. Later layers take precedence
-const rgblight_segment_t* const PROGMEM my_rgb_layers[] = RGBLIGHT_LAYERS_LIST(
-    my_capslock_layer,
-    my_capsoff_layer
-);
-
-
-void keyboard_post_init_kb(void){
-    rgblight_layers = my_rgb_layers;
-    keyboard_post_init_user();
-}
-
-bool led_update_kb(led_t led_state){
-    bool res = led_update_user(led_state);
-    if (res) {
-        rgblight_set_layer_state(0, led_state.caps_lock);
-        rgblight_set_layer_state(1, !led_state.caps_lock);
-    }
-    return res;
-}