Merge branch 'master' into sjb/all-keyboard

* master: (46 commits) [Doc] Improve converter references (qmk#21801) [Keyboard] Add dnworks 997pt3 (qmk#22466) Add leonardo build target for leonardo + usb2.0 shield based projects (qmk#22243) [Keyboard] Add Eden (qmk#22467) Update stale.yml Update stale.yml (qmk#22473) Bs equals (qmk#21690) Fix typos: key-modifer→key-modifier and interacton→interaction (qmk#22464) add `68_ansi` Community Layout to nebula68b (qmk#22433) [Keyboard] Fixes to make snes_macropad play nicer with qmk configurator (qmk#22432) studiokestra/line_tkl: correct layout data (qmk#22455) add 5087 keyboard (qmk#20557) Add `qmk license-check` developer-level CLI command. (qmk#22075) [Keyboard] Add MariOrion v2.5 (qmk#22273) Add Ploopy Madromys mouse (qmk#21989) [Keyboard] Add alpaca/wfeclipse (qmk#22230) Update gregandcin/teaqueen (qmk#22402) Add SNES Macropad keyboard (qmk#22377) Update layer state of Lily58 from 'Default' to 'Base' (qmk#22397) Fix indicator LED definition for Sofle RGB. (qmk#22408) ...
SjB · Nov 17, 2023 · 7ee3e88 · 7ee3e88
2 parents b2ab717 + a6521b8
commit 7ee3e88
Show file tree

Hide file tree

Showing 235 changed files with 11,862 additions and 335 deletions.
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
@@ -3,6 +3,7 @@ name: 'Close stale issues and PRs'
 permissions:
   issues: write
   pull-requests: write
+  actions: write
 
 on:
   schedule:
@@ -13,7 +14,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/stale@v8
+      - uses: actions/stale@main
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
 

diff --git a/data/mappings/info_config.hjson b/data/mappings/info_config.hjson
@@ -190,4 +190,9 @@
     "PRODUCT": {"info_key": "keyboard_name", "warn_duplicate": false, "value_type": "str", "deprecated": true, "replace_with": "`keyboard_name` in info.json"},
     "PRODUCT_ID": {"info_key": "usb.pid", "value_type": "hex", "deprecated": true, "replace_with": "`usb.pid` in info.json"},
     "VENDOR_ID": {"info_key": "usb.vid", "value_type": "hex", "deprecated": true, "replace_with": "`usb.vid` in info.json"},
+
+    // Items we want flagged in lint
+    "VIAL_KEYBOARD_UID": {"info_key": "_invalid.vial_uid", "invalid": true},
+    "VIAL_UNLOCK_COMBO_COLS": {"info_key": "_invalid.vial_unlock_cols", "invalid": true},
+    "VIAL_UNLOCK_COMBO_ROWS": {"info_key": "_invalid.vial_unlock_rows", "invalid": true}
 }
diff --git a/docs/feature_converters.md b/docs/feature_converters.md
@@ -1,12 +1,10 @@
 # Converters
 
-Since many drop-in replacement controllers now exist, we've done our best to make them easy to use in existing designs.
+This page documents the automated process for converting keyboards to use drop-in replacement controllers. This process is designed to be easy to use and can be completed in a few simple steps.
 
-This page documents the handy automated process for converting keyboards.
+## Supported Converters
 
-### Supported Converters
-
-Currently the following converters are available:
+The following converters are available at this time:
 
 | From       | To                |
 |------------|-------------------|
@@ -28,14 +26,10 @@ Currently the following converters are available:
 | `elite_c`  | `helios`          |
 | `elite_c`  | `liatris`         |
 
-See below for more in depth information on each converter.
 
 ## Overview
 
-Each converter category is broken down by its declared `pin compatibility`.
-This ensures that only valid combinations are attempted.
-
-You can generate the firmware by appending `-e CONVERT_TO=<target>` to your compile/flash command. For example:
+Each converter category is broken down by its declared `pin compatibility`. This ensures that only valid combinations are attempted. You can generate the firmware by appending `-e CONVERT_TO=<target>` to your compile/flash command. For example:
 
 ```sh
 qmk flash -c -kb keebio/bdn9/rev1 -km default -e CONVERT_TO=proton_c
@@ -59,14 +53,12 @@ Once a converter is enabled, it exposes the `CONVERT_TO_<target_uppercase>` flag
 
 ### Pin Compatibility
 
-To ensure compatibility, provide validation, and power future workflows, a keyboard should declare its `pin compatibility`. For legacy reasons, this is currently assumed to be `promicro`.
-
-Currently the following pin compatibility interfaces are defined:
+To ensure compatibility, provide validation, and enable future workflows, a keyboard should declare its `pin compatibility`. For legacy reasons, this is currently assumed to be `promicro`. The following pin compatibility interfaces are currently defined:
 
-| Pinout     | Notes                             |
-|------------|-----------------------------------|
-| `promicro` | Includes RX/TX LEDs               |
-| `elite_c`  | Includes bottom row pins, no LEDs |
+| Pin Compatibility | Notes                             |
+|-------------------|-----------------------------------|
+| `promicro`        | Includes RX/TX LEDs               |
+| `elite_c`         | Includes bottom row pins, no LEDs |
 
 To declare the base for conversions, add this line to your keyboard's `rules.mk`:
 
@@ -140,7 +132,7 @@ The following defaults are based on what has been implemented for [RP2040](platf
 
 ### SparkFun Pro Micro - RP2040, Blok, Bit-C PRO and Michi :id=promicro_rp2040 
 
-Currently identical to [Adafruit KB2040](#kb2040).
+Feature set is identical to [Adafruit KB2040](#kb2040).
 
 ### STeMCell :id=stemcell
 
@@ -150,9 +142,7 @@ There are two versions of STeMCell available, with different pinouts:
   - v2.0.0 (pre-release v1.0.1, v1.0.2)
 Default official firmware only supports v2.0.0 STeMCell.
 
-STeMCell has support to swap UART and I2C pins, to enable single-wire uart communication in STM chips.
-
-The following additional flags has to be used while compiling, based on the pin used for split communication.
+STeMCell has support to swap UART and I2C pins to enable single-wire uart communication in STM chips. The following additional flags has to be used while compiling, based on the pin used for split communication:
 
 | Split Pin | Compile flags |
 |-----------|---------------|
@@ -173,11 +163,8 @@ The Bonsai C4 only has one on-board LED (B2), and by default, both the Pro Micro
 
 ### RP2040 Community Edition - Elite-Pi, Helios, and Liatris :id=rp2040_ce
 
-Feature set currently identical to [Adafruit KB2040](#kb2040).
-
-Enables VBUS detection by default for superior split keyboard support.
+Feature set is identical to [Adafruit KB2040](#kb2040). VBUS detection is enabled by default for superior split keyboard support. For more information, refer to the [Community Edition pinout](platformdev_rp2040.md#rp2040_ce) docs.
 
-For more information, refer to the [RP2040 Community Edition](platformdev_rp2040.md#rp2040_ce) docs.
 
 ## Elite-C
 
@@ -202,8 +189,8 @@ Converter summary:
 
 ### STeMCell :id=stemcell_elite
 
-Currently identical to [STeMCell](#stemcell) with support for the additional bottom row of pins.
+Identical to [Pro Micro - STeMCell](#stemcell) with support for the additional bottom row of pins.
 
 ### RP2040 Community Edition :id=rp2040_ce_elite
 
-Currently identical to [RP2040 Community Edition](#rp2040_ce), with support for the additional bottom row of pins.
+Identical to [Pro Micro - RP2040 Community Edition](#rp2040_ce) with support for the additional bottom row of pins.
diff --git a/docs/feature_key_overrides.md b/docs/feature_key_overrides.md
@@ -21,7 +21,7 @@ Then, in your `keymap.c` file, you'll need to define the array `key_overrides`,
 The `key_override_t` struct has many options that allow you to precisely tune your overrides. The full reference is shown below. Instead of manually creating a `key_override_t` value, it is recommended to use these dedicated initializers:
 
 #### `ko_make_basic(modifiers, key, replacement)`
-Returns a `key_override_t`, which sends `replacement` (can be a key-modifer combination), when `key` and `modifiers` are all pressed down. This override still activates if any additional modifiers not specified in `modifiers` are also pressed down. See `ko_make_with_layers_and_negmods` to customize this behavior.
+Returns a `key_override_t`, which sends `replacement` (can be a key-modifier combination), when `key` and `modifiers` are all pressed down. This override still activates if any additional modifiers not specified in `modifiers` are also pressed down. See `ko_make_with_layers_and_negmods` to customize this behavior.
 
 #### `ko_make_with_layers(modifiers, key, replacement, layers)`
 Additionally takes a bitmask `layers` that defines on which layers the override is used.
@@ -224,7 +224,7 @@ The duration of the key repeat delay is controlled with the `KEY_OVERRIDE_REPEAT
 
 ## Difference to Combos :id=difference-to-combos
 
-Note that key overrides are very different from [combos](https://docs.qmk.fm/#/feature_combo). Combos require that you press down several keys almost _at the same time_ and can work with any combination of non-modifier keys. Key overrides work like keyboard shortcuts (e.g. `ctrl` + `z`): They take combinations of _multiple_ modifiers and _one_ non-modifier key to then perform some custom action. Key overrides are implemented with much care to behave just like normal keyboard shortcuts would in regards to the order of pressed keys, timing, and interacton with other pressed keys. There are a number of optional settings that can be used to really fine-tune the behavior of each key override as well. Using key overrides also does not delay key input for regular key presses, which inherently happens in combos and may be undesirable.
+Note that key overrides are very different from [combos](https://docs.qmk.fm/#/feature_combo). Combos require that you press down several keys almost _at the same time_ and can work with any combination of non-modifier keys. Key overrides work like keyboard shortcuts (e.g. `ctrl` + `z`): They take combinations of _multiple_ modifiers and _one_ non-modifier key to then perform some custom action. Key overrides are implemented with much care to behave just like normal keyboard shortcuts would in regards to the order of pressed keys, timing, and interaction with other pressed keys. There are a number of optional settings that can be used to really fine-tune the behavior of each key override as well. Using key overrides also does not delay key input for regular key presses, which inherently happens in combos and may be undesirable.
 
 ## Solution to the problem of flashing modifiers :id=neutralize-flashing-modifiers
 

diff --git a/docs/feature_rgblight.md b/docs/feature_rgblight.md
@@ -524,7 +524,6 @@ By defining `RGBLIGHT_LED_MAP` as in the example below, you can specify the LED
 ```
 <img src="https://user-images.githubusercontent.com/2170248/55743725-08ad7a80-5a6e-11e9-83ed-126a2b0209fc.JPG" alt="simple mapped" width="50%"/>
 
-```
 ## Clipping Range
 
 Using the `rgblight_set_clipping_range()` function, you can prepare more buffers than the actual number of LEDs, and output some of the buffers to the LEDs. This is useful if you want the split keyboard to treat left and right LEDs as logically contiguous.
@@ -544,8 +543,8 @@ In addition to setting the Clipping Range, you can use `RGBLIGHT_LED_MAP` togeth
 #define RGBLED_NUM 8
 #define RGBLIGHT_LED_MAP { 7, 6, 5, 4, 3, 2, 1, 0 }
 
-// some soruce
-  rgblight_set_clipping_range(3, 4);
+// some source
+rgblight_set_clipping_range(3, 4);
 ```
 <img src="https://user-images.githubusercontent.com/2170248/55743747-119e4c00-5a6e-11e9-91e5-013203ffae8a.JPG" alt="clip mapped" width="70%"/>
 

diff --git a/docs/serial_driver.md b/docs/serial_driver.md
@@ -235,7 +235,7 @@ Where 'n' matches the peripheral number of your selected USART on the MCU.
 
 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.
 
-Configure the hardware via your 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
 ```

diff --git a/docs/ws2812_driver.md b/docs/ws2812_driver.md
@@ -170,7 +170,7 @@ To configure it, add this to your rules.mk:
 WS2812_DRIVER = vendor
 ```
 
-Configure the hardware via your config.h:
+You may optionally switch the PIO peripheral used with the following define in config.h:
 ```c
 #define WS2812_PIO_USE_PIO1 // Force the usage of PIO1 peripheral, by default the WS2812 implementation uses the PIO0 peripheral
 ```

diff --git a/keyboards/4pplet/waffling60/rev_e_ansi/config.h b/keyboards/4pplet/waffling60/rev_e_ansi/config.h
@@ -0,0 +1,20 @@
+/*
+Copyright 2023 Stefan Sundin "4pplet" <mail@4pplet.com>
+
+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/>.
+*/
+#pragma once
+
+#define WS2812_EXTERNAL_PULLUP
+