Merge remote-tracking branch 'upstream/develop' into comm_60_d

Doxyfile

@@ -145,7 +145,7 @@ FILE_PATTERNS          = *.c \
 RECURSIVE              = YES
 EXCLUDE                =
 EXCLUDE_SYMLINKS       = NO
-EXCLUDE_PATTERNS       = */protocol/arm_atsam/*
+EXCLUDE_PATTERNS       =
 EXCLUDE_SYMBOLS        =
 EXAMPLE_PATH           =
 EXAMPLE_PATTERNS       = *

builddefs/common_features.mk

@@ -238,10 +238,6 @@ else
         OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_TRANSIENT
         SRC += eeprom_driver.c eeprom_transient.c
       endif
-    else ifeq ($(PLATFORM),ARM_ATSAM)
-      # arm_atsam EEPROM
-      OPT_DEFS += -DEEPROM_SAMD
-      SRC += eeprom_samd.c
     else ifeq ($(PLATFORM),TEST)
       # Test harness "EEPROM"
       OPT_DEFS += -DEEPROM_TEST_HARNESS
@@ -881,7 +877,7 @@ ifeq ($(strip $(BLUETOOTH_ENABLE)), yes)
     OPT_DEFS += -DBLUETOOTH_$(strip $(shell echo $(BLUETOOTH_DRIVER) | tr '[:lower:]' '[:upper:]'))
     NO_USB_STARTUP_CHECK := yes
     COMMON_VPATH += $(DRIVER_PATH)/bluetooth
-    SRC += outputselect.c
+    SRC += outputselect.c process_connection.c
 
     ifeq ($(strip $(BLUETOOTH_DRIVER)), bluefruit_le)
         SPI_DRIVER_REQUIRED = yes

builddefs/common_rules.mk

@@ -43,25 +43,25 @@ ifneq ($(USE_CCACHE),no)
     CC_PREFIX ?= ccache
 endif
 
+#---------------- Debug Options ----------------
+
+DEBUG_ENABLE ?= no
+ifeq ($(strip $(DEBUG_ENABLE)),yes)
+	CFLAGS 	 += -ggdb3
+	CXXFLAGS += -ggdb3
+	ASFLAGS  += -ggdb3
+# Create a map file when debugging
+	LDFLAGS  += -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref
+endif
+
+
 #---------------- C Compiler Options ----------------
 
 ifeq ($(strip $(LTO_ENABLE)), yes)
-    ifeq ($(PLATFORM),ARM_ATSAM)
-        $(info Enabling LTO on arm_atsam-targeting boards is known to have a high likelihood of failure.)
-        $(info If unsure, set LTO_ENABLE = no.)
-    endif
     CDEFS += -flto
     CDEFS += -DLTO_ENABLE
 endif
 
-DEBUG_ENABLE ?= yes
-ifeq ($(strip $(SKIP_DEBUG_INFO)),yes)
-  DEBUG_ENABLE=no
-endif
-
-ifeq ($(strip $(DEBUG_ENABLE)),yes)
-  CFLAGS += -g$(DEBUG)
-endif
 CFLAGS += $(CDEFS)
 CFLAGS += -O$(OPT)
 # add color
@@ -83,9 +83,6 @@ CFLAGS += -fcommon
 
 #---------------- C++ Compiler Options ----------------
 
-ifeq ($(strip $(DEBUG_ENABLE)),yes)
-  CXXFLAGS += -g$(DEBUG)
-endif
 CXXFLAGS += $(CXXDEFS)
 CXXFLAGS += -O$(OPT)
 # to suppress "warning: only initialized variables can be placed into program memory area"
@@ -106,14 +103,10 @@ endif
 
 #---------------- Linker Options ----------------
 
-CREATE_MAP ?= yes
-ifeq ($(CREATE_MAP),yes)
-	LDFLAGS += -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref
-endif
 ifeq ($(VERBOSE_LD_CMD),yes)
 	LDFLAGS += -v
 endif
-#LDFLAGS += -Wl,--relax
+
 LDFLAGS += $(EXTMEMOPTS)
 LDFLAGS += $(patsubst %,-L%,$(EXTRALIBDIRS))
 LDFLAGS += -lm
@@ -126,15 +119,11 @@ ADHLNS_ENABLE ?= no
 ifeq ($(ADHLNS_ENABLE),yes)
   # Avoid "Options to '-Xassembler' do not match" - only specify assembler options at LTO link time
   ifeq ($(strip $(LTO_ENABLE)), yes)
-    LDFLAGS += -Wa,-adhlns=$(BUILD_DIR)/$(TARGET).lst
+    LDFLAGS  += -Wa,-adhlns=$(BUILD_DIR)/$(TARGET).lst
   else
-    CFLAGS += -Wa,-adhlns=$(@:%.o=%.lst)
+    CFLAGS   += -Wa,-adhlns=$(@:%.o=%.lst)
     CXXFLAGS += -Wa,-adhlns=$(@:%.o=%.lst)
-    ifeq ($(strip $(DEBUG_ENABLE)),yes)
-      ASFLAGS = -Wa,-adhlns=$(@:%.o=%.lst),-gstabs,--listing-cont-lines=100
-    else
-      ASFLAGS = -Wa,-adhlns=$(@:%.o=%.lst),--listing-cont-lines=100
-    endif
+	ASFLAGS  += -Wa,-adhlns=$(@:%.o=%.lst),--listing-cont-lines=100
   endif
 endif
 

data/constants/keycodes/keycodes_0.0.6_connection.hjson

@@ -0,0 +1,109 @@
+{
+    "ranges": {
+        "0x7780/0x003F": {
+            "define": "QK_CONNECTION"
+        }
+    }
+    "keycodes": {
+        "0x7780": {
+            "group": "connection",
+            "key": "QK_OUTPUT_NEXT",
+            "aliases": [
+                "OU_NEXT",
+                "OU_AUTO"
+            ]
+        },
+        "0x7781": {
+            "group": "connection",
+            "key": "QK_OUTPUT_PREV",
+            "aliases": [
+                "OU_PREV"
+            ]
+        },
+        "0x7782": {
+            "group": "connection",
+            "key": "QK_OUTPUT_NONE",
+            "aliases": [
+                "OU_NONE"
+            ]
+        },
+        "0x7783": {
+            "group": "connection",
+            "key": "QK_OUTPUT_USB",
+            "aliases": [
+                "OU_USB"
+            ]
+        },
+        "0x7784": {
+            "group": "connection",
+            "key": "QK_OUTPUT_2P4GHZ",
+            "aliases": [
+                "OU_2P4G"
+            ]
+        },
+        "0x7785": {
+            "group": "connection",
+            "key": "QK_OUTPUT_BLUETOOTH",
+            "aliases": [
+                "OU_BT"
+            ]
+        },
+
+        "0x7790": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_PROFILE_NEXT",
+            "aliases": [
+                "BT_NEXT"
+            ]
+        },
+        "0x7791": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_PROFILE_PREV",
+            "aliases": [
+                "BT_PREV"
+            ]
+        },
+        "0x7792": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_UNPAIR",
+            "aliases": [
+                "BT_UNPR"
+            ]
+        }
+        "0x7793": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_PROFILE1",
+            "aliases": [
+                "BT_PRF1"
+            ]
+        },
+        "0x7794": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_PROFILE2",
+            "aliases": [
+                "BT_PRF2"
+            ]
+        },
+        "0x7795": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_PROFILE3",
+            "aliases": [
+                "BT_PRF3"
+            ]
+        },
+        "0x7796": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_PROFILE4",
+            "aliases": [
+                "BT_PRF4"
+            ]
+        },
+        "0x7797": {
+            "group": "connection",
+            "key": "QK_BLUETOOTH_PROFILE5",
+            "aliases": [
+                "BT_PRF5"
+            ]
+        },
+    }
+}

data/constants/keycodes/keycodes_0.0.6_quantum.hjson

@@ -0,0 +1,7 @@
+{
+    "keycodes": {
+        "0x7C20": "!delete!", // old QK_OUTPUT_AUTO
+        "0x7C21": "!delete!", // old QK_OUTPUT_USB
+        "0x7C22": "!delete!", // old QK_OUTPUT_BLUETOOTH
+    }
+}

docs/ChangeLog/20240825.md

@@ -4,7 +4,7 @@
 
 August 2024 brings another maintenance release of QMK. Almost all PRs this cycle were to do with cleanup or re-organization of existing features and code.
 
-One key item is that there are no longer any `via`-enabled keymaps in the QMK repository -- these have all transitioned to an [External Userspace](../newbs_external_userspace) repository under the VIA team's control. Going forward, all PRs to `qmk_firmware` must not contain `via` keymaps; these should instead be redirected to the the VIA team's repo: `https://github.com/the-via/qmk_userspace_via` (link placeholder until transfer is completed).
+One key item is that there are no longer any `via`-enabled keymaps in the QMK repository -- these have all transitioned to an [External Userspace](../newbs_external_userspace) repository under the VIA team's control. Going forward, all PRs to `qmk_firmware` must not contain `via` keymaps; these should instead be redirected to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository.
 
 ## Changes Requiring User Action
 
@@ -76,7 +76,7 @@ In line with the [notice period](../support_deprecation_policy#how-much-advance-
 
 ### Migration of VIA keymaps to VIA team control
 
-Last breaking changes cycle, the QMK team informed that [`via` keymaps are moving](./20240526#migration-of-via-keymaps-to-via-team-control) to the control of the VIA team. As of this merge, any `via`-enabled keymaps should now be PR'ed to `https://github.com/the-via/qmk_userspace_via` (link placeholder until transfer is completed).
+Last breaking changes cycle, the QMK team informed that [`via` keymaps are moving](./20240526#migration-of-via-keymaps-to-via-team-control) to the control of the VIA team. As of this merge, any `via`-enabled keymaps should now be PR'ed to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository.
 
 Any existing or newly-opened PRs against `qmk_firmware` will now be asked to remove any `via`-enabled keymaps from their submissions.
 

docs/compatible_microcontrollers.md

@@ -75,10 +75,6 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
 
 For a detailed overview about the RP2040 support by QMK see the [dedicated RP2040 page](platformdev_rp2040).
 
-## Atmel ATSAM
-
-There is limited support for one of Atmel's ATSAM microcontrollers, that being the [ATSAMD51J18A](https://www.microchip.com/wwwproducts/en/ATSAMD51J18A) used by the [Massdrop keyboards](https://github.com/qmk/qmk_firmware/tree/master/keyboards/massdrop). However, it is not recommended to design a board with this microcontroller as the support is quite specialized to Massdrop hardware.
-
 ## RISC-V
 
 ### GigaDevice

docs/drivers/gpio.md

@@ -13,7 +13,7 @@ The following macros provide basic control of GPIOs and are found in `platforms/
 |`gpio_set_pin_input_low(pin)`        |Set pin as input with builtin pull-down resistor (unavailable on AVR)|
 |`gpio_set_pin_output(pin)`           |Set pin as output (alias of `gpio_set_pin_output_push_pull`)         |
 |`gpio_set_pin_output_push_pull(pin)` |Set pin as output, push/pull mode                                    |
-|`gpio_set_pin_output_open_drain(pin)`|Set pin as output, open-drain mode (unavailable on AVR and ATSAM)    |
+|`gpio_set_pin_output_open_drain(pin)`|Set pin as output, open-drain mode (unavailable on AVR)              |
 |`gpio_write_pin_high(pin)`           |Set pin level as high, assuming it is an output                      |
 |`gpio_write_pin_low(pin)`            |Set pin level as low, assuming it is an output                       |
 |`gpio_write_pin(pin, level)`         |Set pin level, assuming it is an output                              |

docs/features/bluetooth.md

@@ -39,8 +39,8 @@ BLUETOOTH_DRIVER = bluefruit_le # or rn42
 
 This is used when multiple keyboard outputs can be selected. Currently this only allows for switching between USB and Bluetooth on keyboards that support both.
 
-|Key                  |Aliases  |Description                                   |
-|---------------------|---------|----------------------------------------------|
-|`QK_OUTPUT_AUTO`     |`OU_AUTO`|Automatically switch between USB and Bluetooth|
-|`QK_OUTPUT_USB`      |`OU_USB` |USB only                                      |
-|`QK_OUTPUT_BLUETOOTH`|`OU_BT`  |Bluetooth only                                |
+| Key                   | Aliases              | Description                                    |
+|-----------------------|----------------------|------------------------------------------------|
+| `QK_OUTPUT_NEXT`      | `OU_NEXT`, `OU_AUTO` | Automatically switch between USB and Bluetooth |
+| `QK_OUTPUT_USB`       | `OU_USB`             | USB only                                       |
+| `QK_OUTPUT_BLUETOOTH` | `OU_BT`              | Bluetooth only                                 |

docs/features/joystick.md

@@ -18,6 +18,8 @@ By default the joystick driver is `analog`, but you can change this with:
 JOYSTICK_DRIVER = digital
 ```
 
+When using `analog` with ARM, [you must use 3.3v with your Joystick](../drivers/adc). Although ARM boards such as the [Helios](https://keeb.supply/products/0xcb-helios) have 5v pin output, the ADC driver does not support it.
+
 ## Configuration {#configuration}
 
 By default, two axes and eight buttons are defined, with a reported resolution of 8 bits (-127 to +127). This can be changed in your `config.h`:

docs/getting_started_docker.md

@@ -5,6 +5,7 @@ This project includes a Docker workflow that will allow you to build a new firmw
 ## Requirements
 
 The main prerequisite is a working `docker` or `podman` install.
+
 * [Docker CE](https://docs.docker.com/install/#supported-platforms)
 * [Podman](https://podman.io/getting-started/installation)
 
@@ -18,6 +19,7 @@ cd qmk_firmware
 ```
 
 Run the following command to build a keymap:
+
 ```
 util/docker_build.sh <keyboard>:<keymap>
 # For example: util/docker_build.sh planck/rev6:default
@@ -32,6 +34,8 @@ util/docker_build.sh keyboard:keymap:target
 # For example: util/docker_build.sh planck/rev6:default:flash
 ```
 
+Note that mass storage bootloaders are not supported by the `flash` target. In this case you will have to manually copy the firmware file to the keyboard.
+
 You can also start the script without any parameters, in which case it will ask you to input the build parameters one by one, which you may find easier to use:
 
 ```

docs/keycodes.md

@@ -294,11 +294,11 @@ See also: [Backlighting](features/backlight)
 
 See also: [Bluetooth](features/bluetooth)
 
-|Key                  |Aliases  |Description                                   |
-|---------------------|---------|----------------------------------------------|
-|`QK_OUTPUT_AUTO`     |`OU_AUTO`|Automatically switch between USB and Bluetooth|
-|`QK_OUTPUT_USB`      |`OU_USB` |USB only                                      |
-|`QK_OUTPUT_BLUETOOTH`|`OU_BT`  |Bluetooth only                                |
+| Key                   | Aliases              | Description                                    |
+|-----------------------|----------------------|------------------------------------------------|
+| `QK_OUTPUT_NEXT`      | `OU_NEXT`, `OU_AUTO` | Automatically switch between USB and Bluetooth |
+| `QK_OUTPUT_USB`       | `OU_USB`             | USB only                                       |
+| `QK_OUTPUT_BLUETOOTH` | `OU_BT`              | Bluetooth only                                 |
 
 ## Caps Word {#caps-word}
 

docs/other_vscode.md

@@ -177,12 +177,13 @@ You'll need to perform some modifications to the file above in order to target y
 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:
+The following modifications must be made to the keyboard's `rules.mk` file to enable debug information and disable optimisations -- this will ensure breakpoints and variable viewing works correctly:
 ```makefile
+# Enable debug information in the final binaries
+DEBUG_ENABLE = yes
 # 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 ...`).

docs/pr_checklist.md

@@ -44,12 +44,14 @@ If there are any inconsistencies with these recommendations, you're best off [cr
 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.
 :::
 
-- 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.
+- PRs for vendor specific keymaps will be permitted. The naming convention for these should be `default_${vendor}` i.e. `default_clueboard`.
+    - vendor specific keymaps do not necessarily need to be "vanilla" and can be more richly featured than `default` stock keymaps.
 - `#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
+- keymaps should not enable VIA
+    - keymaps targeting VIA support should be submitted to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository
 
 ## Keyboard PRs
 
@@ -136,12 +138,12 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
 - `keymaps/default/keymap.c`
     - `QMKBEST`/`QMKURL` example macros removed
     - if using `MO(1)` and `MO(2)` keycodes together to access a third layer, the [Tri Layer](features/tri_layer) feature should be used, rather than manually implementing this using `layer_on/off()` and `update_tri_layer()` functions in the keymap's `process_record_user()`.
-- default (and via) keymaps should be "pristine"
+- default keymaps should be "pristine"
     - bare minimum to be used as a "clean slate" for another user to develop their own user-specific keymap
     - what does pristine mean? no custom keycodes. no advanced features like tap dance or macros. basic mod taps and home row mods would be acceptable where their use is necessary
     - standard layouts preferred in these keymaps, if possible
     - should use [encoder map feature](features/encoders#encoder-map), rather than `encoder_update_user()`
-    - default keymap should not enable VIA -- the VIA integration documentation requires a keymap called `via`
+    - default keymap should not enable VIA -- keymaps targeting VIA support should be submitted to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository
 - submitters can add an example (or bells-and-whistles) keymap showcasing capabilities in the same PR but it shouldn't be embedded in the 'default' keymap
 - submitters can also have a "manufacturer-matching" keymap that mirrors existing functionality of the commercial product, if porting an existing board
 - Do not include VIA json files in the PR. These do not belong in the QMK repository as they are not used by QMK firmware -- they belong in the [VIA Keyboard Repo](https://github.com/the-via/keyboards)
@@ -174,7 +176,7 @@ Also, specific to ChibiOS:
 - all core PRs must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
 - as indicated above, the smallest set of changes to core components should be included in each PR
     - PRs containing multiple areas of change will be asked to be split up and raised separately
-    - keyboard and keymap changes should only be included if they affect base keyboard builds, or the default-like `default`, `via`, `default_????` keymaps etc.
+    - keyboard and keymap changes should only be included if they affect base keyboard builds, or the default-like `default`, `default_????` keymaps etc.
         - keymap modifications for anything other than the default-like keymaps **should not be included in the initial PR** in order to simplify the review process
         - the core PR submitter should submit a followup PR affecting other keymaps after initial PR merge
         - large-scale refactoring or consolidation PRs that affect other keymaps (such as renaming keycodes) should always be raised separately