Merge branch 'qmk:master' into master

.github/workflows/ci_builds.yml

@@ -53,7 +53,7 @@ jobs:
         [ ! -f .failed ] || exit 1
 
     - name: 'Upload artifacts'
-      uses: actions/upload-artifact@v3
+      uses: actions/upload-artifact@v4
       if: always()
       with:
         name: artifacts-${{ github.event.inputs.branch || github.ref_name }}-${{ matrix.keymap }}

.github/workflows/format.yml

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

.github/workflows/lint.yml

@@ -27,7 +27,7 @@ jobs:
 
     - name: Get changed files
       id: file_changes
-      uses: tj-actions/changed-files@v39
+      uses: tj-actions/changed-files@v42
 
     - name: Print info
       run: |

.gitignore

@@ -18,6 +18,11 @@
 *.lst
 *.map
 *.o
+*.a
+*.so
+*.dylib
+*.dll
+*.la
 *.stackdump
 *.sym
 

builddefs/converters.mk

@@ -25,7 +25,9 @@ ifneq ($(CONVERT_TO),)
     -include $(CONVERTER)/pre_converter.mk
 
     PLATFORM_KEY = $(shell echo $(CONVERTER) | cut -d "/" -f2)
-    TARGET := $(TARGET)_$(CONVERT_TO)
+
+    # force setting as value can be from environment
+    override TARGET := $(TARGET)_$(CONVERT_TO)
 
     # Configure any defaults
     OPT_DEFS += -DCONVERT_TO_$(shell echo $(CONVERT_TO) | tr '[:lower:]' '[:upper:]')

docs/cli.md

@@ -2,7 +2,7 @@
 
 ## Overview :id=overview
 
-The QMK CLI makes building and working with QMK keyboards easier. We have provided a number of commands to simplify and streamline tasks such as obtaining and compiling the QMK firmware, creating keymaps, and more.
+The QMK CLI (command line interface) makes building and working with QMK keyboards easier. We have provided a number of commands to simplify and streamline tasks such as obtaining and compiling the QMK firmware, creating keymaps, and more.
 
 ### Requirements :id=requirements
 

docs/cli_commands.md

@@ -362,6 +362,16 @@ This command is directory aware. It will automatically fill in KEYBOARD if you a
 qmk list-keymaps -kb planck/ez
 ```
 
+## `qmk migrate`
+
+This command searches for legacy code that can be converted to the new `info.json` format and adds it to the specified keyboard's `info.json`.
+
+**Usage**:
+
+```
+qmk migrate [-h] -kb KEYBOARD [-f FILTER]
+```
+
 ## `qmk new-keyboard`
 
 This command creates a new keyboard based on available templates.

docs/feature_rawhid.md

@@ -28,7 +28,7 @@ To send data to the keyboard, you must first find a library for communicating wi
 * **Node.js:** [node-hid](https://github.com/node-hid/node-hid)
 * **C/C++:** [hidapi](https://github.com/libusb/hidapi)
 * **Java:** [purejavahidapi](https://github.com/nyholku/purejavahidapi) and [hid4java](https://github.com/gary-rowe/hid4java)
-* **Python:** [pyhidapi](https://pypi.org/project/hid/)
+* **Python:** [pyhidapi](https://pypi.org/project/hid/) and [pywinusb](https://pypi.org/project/pywinusb)
 
 Please refer to these libraries' own documentation for instructions on usage. Remember to close the device once you are finished with it!
 

docs/keymap.md

@@ -125,7 +125,7 @@ At the top of the file you'll find this:
 
 These are some handy definitions we can use when building our keymap and our custom function. The `GRAVE_MODS` definition will be used later in our custom function, and the following `_BL`, `_FL`, and `_CL` defines make it easier to refer to each of our layers.
 
-Note: You may also find some older keymap files may also have a define(s) for `_______` and/or `XXXXXXX`. These can be used in place for `KC_TRNS` and `KC_NO` respectively, making it easier to see what keys a layer is overriding. These definitions are now unecessary, as they are included by default.
+Note: You may also find some older keymap files may also have a define(s) for `_______` and/or `XXXXXXX`. These can be used in place for `KC_TRNS` and `KC_NO` respectively, making it easier to see what keys a layer is overriding. These definitions are now unnecessary, as they are included by default.
 
 ### Layers and Keymaps
 

docs/pr_checklist.md

@@ -39,12 +39,13 @@ If there are any inconsistencies with these recommendations, you're best off [cr
 
 ## Keymap PRs
 
-!> Note that personal keymap submissions will no longer be accepted. This section applies to manufacturer-supported keymaps.
+!> Note that personal keymap submissions will no longer be accepted. This section applies to manufacturer-supported keymaps. Please see this [issue](https://github.com/qmk/qmk_firmware/issues/22724) for more information.
 
-- `#include QMK_KEYBOARD_H` preferred to including specific board files
-- prefer layer `enum`s to `#define`s
-- custom keycode `enum`s must have first entry `= SAFE_RANGE`
-- terminating backslash (`\`) in lines of LAYOUT macro parameters is superfluous and should be removed
+- 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
+- prefer layer enums to #defines
+- 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