Merge branch 'master' into sjb/all-keyboard

* master: (53 commits)
  Add debounce time description (qmk#20333)
  Manibus keyboard, update pinout (qmk#20309)
  Use table for debounce algorithm description (qmk#20322)
  [keyboard] Adding OSAv2 numpad (qmk#20209)
  Add Ripple TKL Keyboard firmware (qmk#20301)
  Add Ripple TKL Hotswap Firmware (qmk#20302)
  Personal keymaps for crkbd and kyria (qmk#20009)
  Adding Oceanographer to QMK. (qmk#20324)
  Modify default encoder mappings, change PID, enable mousekeys (qmk#20329)
  PR checklist: keyboard updates must go to `develop` (qmk#20323)
  Data-driven updates to overnumpad controller keyboards (qmk#20259)
  Suggest `qmk list-keyboards` when testing build environment (qmk#19471)
  Add an alternate layout definition for Keyboardio Model 01 (qmk#20245)
  Refactor Galatea (qmk#20011)
  Adding Unextended Standard PCB (qmk#20190)
  New layer added to giabalanai keyboard (qmk#20118)
  onekey: Fix console output on AVR (qmk#19930)
  Update WT60-H1, WT60-H3 layouts (qmk#20114)
  Adding my keymap (qmk#19964)
  [Bugfix] Check QGF's bpp against display's native_bits_per_pixel (qmk#19995)
  ...

.github/workflows/ci_builds.yml

@@ -4,10 +4,9 @@ permissions:
   contents: read
 
 on:
-  push:
-    branches:
-    - master
-    - develop
+  workflow_dispatch:
+  schedule:
+    - cron: '0 0,12 * * *'
 
 jobs:
   ci_builds:
@@ -18,7 +17,9 @@ jobs:
     if: github.repository == 'qmk/qmk_firmware'
 
     strategy:
+      fail-fast: false
       matrix:
+        branch: [master, develop]
         keymap: [default, via]
 
     container: qmkfm/qmk_cli
@@ -30,19 +31,30 @@ jobs:
     - uses: actions/checkout@v3
       with:
         submodules: recursive
+        ref: ${{ matrix.branch }}
 
     - name: Install dependencies
       run: pip3 install -r requirements.txt
 
     - name: Run `qmk mass-compile` (keymap ${{ matrix.keymap }})
-      run: qmk mass-compile -j $(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || getconf _NPROCESSORS_ONLN 2>/dev/null) -km ${{ matrix.keymap }}
-
-    - name: 'Upload binaries'
+      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@v3
+      if: always()
       with:
-        name: binaries-${{ matrix.keymap }}
+        name: artifacts-${{ matrix.branch }}-${{ matrix.keymap }}
         if-no-files-found: ignore
         path: |
           *.bin
           *.hex
           *.uf2
+          .build/failed.*

builddefs/build_keyboard.mk

@@ -29,6 +29,11 @@ KEYBOARD_FILESAFE := $(subst /,_,$(KEYBOARD))
 TARGET ?= $(KEYBOARD_FILESAFE)_$(KEYMAP)
 KEYBOARD_OUTPUT := $(BUILD_DIR)/obj_$(KEYBOARD_FILESAFE)
 
+ifeq ($(strip $(DUMP_CI_METADATA)),yes)
+    $(info CI Metadata: KEYBOARD=$(KEYBOARD))
+    $(info CI Metadata: KEYMAP=$(KEYMAP))
+endif
+
 # Force expansion
 TARGET := $(TARGET)
 

docs/feature_debounce_type.md

@@ -57,78 +57,78 @@ susceptible to noise, you must choose a debounce method that will also mitigate
      if the scanning is slow, and you are using a timestamp-based algorithm, you might end up making a debouncing decision based on only two
      sampled values, which will limit the noise-resistance of the algorithm.
    * Currently all built-in debounce algorithms support timestamp-based debouncing only. In the future we might
-     implement cycles-based debouncing, and it will be selectable via a ```config.h``` macro.
+     implement cycles-based debouncing, and it will be selectable via a `config.h` macro.
 
 2) Symmetric vs Asymmetric
    * Symmetric - apply the same debouncing algorithm, to both key-up and key-down events.
-     * Recommended naming convention: ```sym_*```
+     * Recommended naming convention: `sym_*`
    * Asymmetric - apply different debouncing algorithms to key-down and key-up events. E.g. Eager key-down, Defer key-up.
-     * Recommended naming convention: ```asym_*``` followed by details of the type of algorithm in use, in order, for key-down and then key-up
+     * Recommended naming convention: `asym_*` followed by details of the type of algorithm in use, in order, for key-down and then key-up
 
 3) Eager vs Defer
    * Eager - any key change is reported immediately. All further inputs for DEBOUNCE ms are ignored.
      * Eager algorithms are not noise-resistant.
      * Recommended naming conventions:
-        * ```sym_eager_*```
-        * ```asym_eager_*_*```: key-down is using eager algorithm
-        * ```asym_*_eager_*```: key-up is using eager algorithm
+        * `sym_eager_*`
+        * `asym_eager_*_*`: key-down is using eager algorithm
+        * `asym_*_eager_*`: key-up is using eager algorithm
    * Defer - wait for no changes for DEBOUNCE ms before reporting change.
      * Defer algorithms are noise-resistant
      * Recommended naming conventions:
-        * ```sym_defer_*```
-        * ```asym_defer_*_*```: key-down is using defer algorithm
-        * ```asym_*_defer_*```: key-up is using defer algorithm
+        * `sym_defer_*`
+        * `asym_defer_*_*`: key-down is using defer algorithm
+        * `asym_*_defer_*`: key-up is using defer algorithm
 
 4) Global vs Per-Key vs Per-Row
    * Global - one timer for all keys. Any key change state affects global timer
-     * Recommended naming convention: ```*_g```
+     * Recommended naming convention: `*_g`
    * Per-key - one timer per key
-     * Recommended naming convention: ```*_pk```
+     * Recommended naming convention: `*_pk`
    * Per-row - one timer per row
-     * Recommended naming convention: ```*_pr```
+     * Recommended naming convention: `*_pr`
    * Per-key and per-row algorithms consume more resources (in terms of performance,
      and ram usage), but fast typists might prefer them over global.
 
-## Debounce algorithms supported by QMK
+## Supported Debounce Algorithms
 
-QMK supports multiple debounce algorithms through its debounce API.
+QMK supports multiple algorithms through its debounce API.
 
-### Debounce selection
+### Debounce Time
 
-| DEBOUNCE_TYPE    | Description                                          | What else is needed           |
-| -------------    | ---------------------------------------------------  | ----------------------------- |
-| Not defined      | Use the default algorithm, currently sym_defer_g     | Nothing                       |
-| custom           | Use your own debounce code                           | ```SRC += debounce.c``` add your own debounce.c and implement necessary functions |
-| Anything Else    | Use another algorithm from quantum/debounce/*        | Nothing                       |
+Default debounce time is 5 milliseconds and it can be changed with the following line in `config.h`:
+```
+#define DEBOUNCE 10
+```
+?> Setting `DEBOUNCE` to `0` will disable this feature.
 
-**Regarding split keyboards**:
-The debounce code is compatible with split keyboards.
+### Debounce Method
 
-### Selecting an included debouncing method
-Keyboards may select one of the already implemented debounce methods, by adding to ```rules.mk``` the following line:
+Keyboards may select one of the core debounce methods by adding the following line into `rules.mk`:
 ```
 DEBOUNCE_TYPE = <name of algorithm>
 ```
-Where name of algorithm is one of:
-* ```sym_defer_g``` - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE``` milliseconds of no changes has occurred, all input changes are pushed.
-  * This is the current default algorithm. This is the highest performance algorithm with lowest memory usage, and it's also noise-resistant.
-* ```sym_eager_pr``` - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE``` milliseconds of no further input for that row.
-For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be
-appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
-* ```sym_eager_pk``` - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key
-* ```sym_defer_pr``` - debouncing per row. On any state change, a per-row timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that row, the entire row is pushed. Can improve responsiveness over `sym_defer_g` while being less susceptible than per-key debouncers to noise.
-* ```sym_defer_pk``` - debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key status change is pushed.
-* ```asym_eager_defer_pk``` - debouncing per key. On a key-down state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key. On a key-up state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key-up status change is pushed.
-
-### A couple algorithms that could be implemented in the future:
-* ```sym_defer_pr```
-* ```sym_eager_g```
-
-### Use your own debouncing code
-You have the option to implement you own debouncing algorithm. To do this:
-* Set ```DEBOUNCE_TYPE = custom``` in ```rules.mk```.
-* Add ```SRC += debounce.c``` in ```rules.mk```
-* Add your own ```debounce.c```. Look at current implementations in ```quantum/debounce``` for examples.
+Name of algorithm is one of:
+
+| Algorithm             | Description |
+| --------------------- | ----------- |
+| `sym_defer_g`         | Debouncing per keyboard. On any state change, a global timer is set. When `DEBOUNCE` milliseconds of no changes has occurred, all input changes are pushed. This is the highest performance algorithm with lowest memory usage and is noise-resistant. |
+| `sym_defer_pr`        | Debouncing per row. On any state change, a per-row timer is set. When `DEBOUNCE` milliseconds of no changes have occurred on that row, the entire row is pushed. This can improve responsiveness over `sym_defer_g` while being less susceptible to noise than per-key algorithm. |
+| `sym_defer_pk`        | Debouncing per key. On any state change, a per-key timer is set. When `DEBOUNCE` milliseconds of no changes have occurred on that key, the key status change is pushed. |
+| `sym_eager_pr`        | Debouncing per row. On any state change, response is immediate, followed by `DEBOUNCE` milliseconds of no further input for that row. |
+| `sym_eager_pk`        | Debouncing per key. On any state change, response is immediate, followed by `DEBOUNCE` milliseconds of no further input for that key. |
+| `asym_eager_defer_pk` | Debouncing per key. On a key-down state change, response is immediate, followed by `DEBOUNCE` milliseconds of no further input for that key. On a key-up state change, a per-key timer is set. When `DEBOUNCE` milliseconds of no changes have occurred on that key, the key-up status change is pushed. |
+
+?> `sym_defer_g` is the default if `DEBOUNCE_TYPE` is undefined.
+
+?> `sym_eager_pr` is suitable for use in keyboards where refreshing `NUM_KEYS` 8-bit counters is computationally expensive or has low scan rate while fingers usually hit one row at a time. This could be appropriate for the ErgoDox models where the matrix is rotated 90°. Hence its "rows" are really columns and each finger only hits a single "row" at a time with normal usage.
+
+### Implementing your own debouncing code
+
+You have the option to implement you own debouncing algorithm with the following steps:
+
+* Set `DEBOUNCE_TYPE = custom` in `rules.mk`.
+* Add `SRC += debounce.c` in `rules.mk`
+* Implement your own `debounce.c`. See `quantum/debounce` for examples.
 * Debouncing occurs after every raw matrix scan.
-* Use num_rows rather than MATRIX_ROWS, so that split keyboards are supported correctly.
-* If the algorithm might be applicable to other keyboards, please consider adding it to ```quantum/debounce```
+* Use num_rows instead of MATRIX_ROWS to support split keyboards correctly.
+* If your custom algorithm is applicable to other keyboards, please consider making a pull request.

docs/newbs_getting_started.md

@@ -172,6 +172,8 @@ For example, to build a firmware for a Clueboard 66% you would use:
 
     qmk compile -kb clueboard/66/rev3 -km default
 
+?> The keyboard option is the path relative to the keyboard directory, the above example would be found in `qmk_firmware/keyboards/clueboard/66/rev3`. If you're unsure you can view a full list of supported keyboards with `qmk list-keyboards`.
+
 When it is done you should have a lot of output that ends similar to this:
 
 ```

docs/other_vscode.md

@@ -46,16 +46,7 @@ Before starting, you will want to make sure that you have all of the build tools
 
 This part is super simple.  However, there is some configuration that we need to do to ensure things are configured correctly.
 
-### Configuring VS Code
-
-First, we need to set up IntelliSense. This isn't strictly required, but it will make your life a LOT easier. To do this, we need to create the `.vscode/c_cpp_properties.json` file in the QMK Firmware folder, You can do this all manually, but I've done most of the work already. 
-
-Grab [this file](https://gist.github.com/drashna/48e2c49ce877be592a1650f91f8473e8) and save it.  You may need to edit this file, if you didn't install MSYS2 to the default location, or are using WSL/LxSS.  
-
-Once you have saved this file, you will need to reload VS Code, if it was already running. 
-
-?> You should see an `extensions.json` and `settings.json` file in the `.vscode` folder, as well.
-
+#### MSYS2 Setup
 
 Now, we will set up the MSYS2 window to show up in VSCode as the integrated terminal.  This has a number of advantages. Mostly, you can control+click on errors and jump to those files.  This makes debugging much easier.  It's also nice, in that you don't have to jump to another window. 
 
@@ -110,8 +101,50 @@ This installs a bunch of Git related tools that may make using Git with QMK Firm
 Restart once you've installed any extensions
 
 # Configure VS Code for QMK
+
 1. Click <kbd><kbd>File</kbd> > <kbd>Open Folder</kbd></kbd>
 2. Open the QMK Firmware folder that you cloned from GitHub. 
 3. Click <kbd><kbd>File</kbd> > <kbd>Save Workspace As...</kbd></kbd>
 
+## Configuring VS Code
+
+Using the [standard `compile_commands.json` database](https://clang.llvm.org/docs/JSONCompilationDatabase.html), we can get VS code C/C++ extension to use the exact same includes and defines used for your keyboard and keymap. 
+
+1. Run `qmk generate-compilation-database -kb <keyboard> -km <keymap>` to generate the `compile_commands.json`.
+1. Create `.vscode/c_cpp_properties.json` with the following content:
+```
+{
+    "configurations": [
+        {
+            "name": "qmk",
+            "compilerArgs": ["-mmcu=atmega32u4"],
+            "compilerPath": "/usr/bin/avr-gcc",
+            "cStandard": "gnu11",
+            "cppStandard": "gnu++14",
+            "compileCommands": "${workspaceFolder}/compile_commands.json",
+            "intelliSenseMode": "linux-gcc-arm",
+            "browse": {
+                "path": [
+                    "${workspaceFolder}"
+                ],
+                "limitSymbolsToIncludedHeaders": true,
+                "databaseFilename": ""
+            }
+        }
+    ],
+    "version": 4
+}
+```
+
+Change values in `.vscode/c_cpp_properties.json` for your environment:
+
+1. Copy the `-mmcu` argument from `compile_commands.json` into your `compilerArgs`. This is to work around a [bug in vscode c/c++ extension](https://github.com/microsoft/vscode-cpptools/issues/6478).
+1. Use the `compilerPath` from `compile_commands.json`.
+1. Modify `cStandard`, `cppStandard` and `intelliSenseMode` values to the correct values for your platform. See [this section](https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference#_configuration-properties) for reference. For WSL, it should still be gcc-x64.
+
 And now you're ready to code QMK Firmware in VS Code
+
+
+## Troubleshooting VSCode C/C++ extension
+
+If the defines are not matching what you expect, open the source code and run action `C/C++: Log Diagnostics`. This will list the exact list of defines and include paths defined in `compile_commands.json`, and if it's not part of your compilation database, it will tell you so.

docs/pr_checklist.md

@@ -53,6 +53,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
 
 - keyboard moves within the repository *must* go through the `develop` branch instead of `master`, so as to ensure compatibility for users
     - `data/mappings/keyboard_aliases.hjson` must be updated to reflect the move, so users with pre-created configurator keymap.json files continue to detect the correct keyboard
+- keyboard updates and refactors (eg. to data driven) *must* go through `develop` to reduce `master` -> `develop` merge conflicts
 - PR submissions from a `kbfirmware` export (or equivalent) will not be accepted unless converted to new QMK standards -- try `qmk import-kbfirmware` first
 - `info.json`
     - With the move to [data driven](https://docs.qmk.fm/#/data_driven_config) keyboard configuration, we encourage contributors to utilise as many features as possible of the info.json [schema](https://github.com/qmk/qmk_firmware/blob/master/data/schemas/keyboard.jsonschema).