Merge branch 'master' into sjb/all-keyboard

* master: (147 commits) [Keyboard] Add waffling80 Rev B (qmk#18603) Enable mouse keys for momokai tap_trio (qmk#18614) [Keyboard] adafruit/macropad: Fix typo (qmk#18616) Product changes to 1up lineup (qmk#18382) width:2 → height:2 for spacetime thumb keys (qmk#18605) [Keyboard] Add encoder map support for GMMK Pro (qmk#18600) [Keyboard] Add waffling60 Rev D ANSI Hotswap (qmk#18579) [Keyboard] Add waffling60 Rev D Solder (qmk#18580) Added new issue template for "Other issues" (qmk#18578) docs: some typos (qmk#18582) RESET → QK_BOOT in nyhxis/nfr_70 (qmk#18607) Fixup builds for mechlovin/infinity87. (qmk#18604) fix: ps2_interrupt.c failed to compile (qmk#18597) Add C++ prerequisite for Fedora. (qmk#18602) [Keyboard] Add Nyhxis NFR-70 keyboard (qmk#17562) [Docs] Add a note about the print function. (qmk#17737) [Keyboard] Twig50 (qmk#18085) [Docs] Clarify how to use the bootloader LED for rp2040 (qmk#18585) Bump anothrNick/github-tag-action from 1.51.0 to 1.52.0 (qmk#18590) define `oled_write_ln_P` as `oled_write_ln` for non-AVR MCUs (qmk#18589) ...
SjB · Oct 6, 2022 · 12d219e · 12d219e
2 parents d08a897 + b820c6d
commit 12d219e
Show file tree

Hide file tree

Showing 910 changed files with 30,643 additions and 3,978 deletions.
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml
@@ -0,0 +1,41 @@
+name: Bug report
+description: Create a report to help us improve QMK Firmware.
+title: "[Bug] "
+labels: ["bug", "help wanted"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Provide a general summary of the bug in the title above.
+  - type: textarea
+    attributes:
+      label: Describe the Bug
+      description: A clear and concise description of what the bug is.
+  - type: input
+    attributes:
+      label: Keyboard Used
+      description: The name of the keyboard from the `make` or `qmk compile`/`qmk flash` commands, eg. `planck/rev6`.
+  - type: input
+    attributes:
+      label: Link to product page (if applicable)
+  - type: input
+    attributes:
+      label: Operating System
+  - type: textarea
+    attributes:
+      label: qmk doctor Output
+      description: Output from running the `qmk doctor` command.
+      render: text
+  - type: checkboxes
+    attributes:
+      label: Is AutoHotKey / Karabiner installed
+      options:
+        - label: AutoHotKey (Windows)
+        - label: Karabiner (macOS)
+  - type: input
+    attributes:
+      label: Other keyboard-related software installed
+  - type: textarea
+    attributes:
+      label: Additional Context
+      description: Add any other relevant information about the problem here.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml
@@ -0,0 +1,21 @@
+name: Feature request
+description: Suggest a new feature or changes to existing features.
+title: "[Feature Request] "
+labels: ["enhancement", "help wanted"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Provide a general summary of the changes you want in the title above.
+  - type: checkboxes
+    attributes:
+      label: Feature Request Type
+      options:
+        - label: Core functionality
+        - label: Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
+        - label: Alteration (enhancement/optimization) of existing feature(s)
+        - label: New behavior
+  - type: textarea
+    attributes:
+      label: Description
+      description: A few sentences describing what it is that you'd like to see in QMK. Additional information (such as links to spec sheets, licensing info, other related issues or PRs, etc) would be helpful.
diff --git a/.github/ISSUE_TEMPLATE/other_issues.md b/.github/ISSUE_TEMPLATE/other_issues.md
diff --git a/.github/ISSUE_TEMPLATE/other_issues.yml b/.github/ISSUE_TEMPLATE/other_issues.yml
@@ -0,0 +1,16 @@
+name: Other issues
+description: Anything else that doesn't fall into the above categories.
+labels: ["help wanted", "question"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Provide a general summary of the changes you want in the title above.
+  - type: markdown
+    attributes:
+      value: |
+        Please check [https://docs.qmk.fm/#/support](https://docs.qmk.fm/#/support) for additional resources first. If that doesn't answer your question, choose the bug report template instead, as that may be more appropriate.
+  - type: textarea
+    attributes:
+      label: Issue Description
+      description: Describe your issue in as much detail as possible.
diff --git a/.github/workflows/auto_tag.yml b/.github/workflows/auto_tag.yml
@@ -27,7 +27,7 @@ jobs:
         fetch-depth: 0
 
     - name: Bump version and push tag
-      uses: anothrNick/github-tag-action@1.45.0
+      uses: anothrNick/github-tag-action@1.52.0
       env:
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         DEFAULT_BUMP: 'patch'
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
@@ -12,7 +12,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/stale@v5
+      - uses: actions/stale@v6
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
 

diff --git a/Makefile b/Makefile
@@ -264,7 +264,7 @@ define PARSE_KEYMAP
     # The rest of the rule is the target
     # Remove the leading ":" from the target, as it acts as a separator
     MAKE_TARGET := $$(patsubst :%,%,$$(RULE))
-    # We need to generate an unique indentifer to append to the COMMANDS list
+    # We need to generate an unique identifier to append to the COMMANDS list
     CURRENT_KB_UNDER := $$(subst /,_,$$(CURRENT_KB))
     COMMAND := COMMAND_KEYBOARD_$$(CURRENT_KB_UNDER)_KEYMAP_$$(CURRENT_KM)
     # If we are compiling a keyboard without a subproject, we want to display just the name

diff --git a/builddefs/build_keyboard.mk b/builddefs/build_keyboard.mk
@@ -236,7 +236,7 @@ endif
 # that the same keymap may be used on multiple keyboards.
 #
 # We grab the most top-level include file that we can. That file should
-# use #ifdef statements to include all the neccesary subfolder includes,
+# use #ifdef statements to include all the necessary subfolder includes,
 # as described here:
 #
 #    https://docs.qmk.fm/#/feature_layouts?id=tips-for-making-layouts-keyboard-agnostic

diff --git a/builddefs/common_features.mk b/builddefs/common_features.mk
@@ -271,7 +271,7 @@ ifneq ($(strip $(WEAR_LEVELING_DRIVER)),none)
       POST_CONFIG_H += $(DRIVER_PATH)/wear_leveling/wear_leveling_flash_spi_config.h
     else ifeq ($(strip $(WEAR_LEVELING_DRIVER)), rp2040_flash)
       SRC += wear_leveling_rp2040_flash.c
-      POST_CONFIG_H += $(DRIVER_PATH)/wear_leveling/wear_leveling_rp2040_flash_config.h
+      POST_CONFIG_H += $(PLATFORM_PATH)/$(PLATFORM_KEY)/$(DRIVER_PATH)/wear_leveling/wear_leveling_rp2040_flash_config.h
     else ifeq ($(strip $(WEAR_LEVELING_DRIVER)), legacy)
       COMMON_VPATH += $(PLATFORM_PATH)/$(PLATFORM_KEY)/$(DRIVER_DIR)/flash
       SRC += flash_stm32.c wear_leveling_legacy.c

diff --git a/builddefs/common_rules.mk b/builddefs/common_rules.mk
@@ -1,7 +1,7 @@
 # Hey Emacs, this is a -*- makefile -*-
 #----------------------------------------------------------------------------
 
-# Enable vpath seraching for source files only
+# Enable vpath searching for source files only
 # Without this, output files, could be read from the wrong .build directories
 VPATH_SRC := $(VPATH)
 vpath %.c $(VPATH_SRC)
@@ -85,7 +85,7 @@ ifeq ($(strip $(DEBUG_ENABLE)),yes)
 endif
 CXXFLAGS += $(CXXDEFS)
 CXXFLAGS += -O$(OPT)
-# to supress "warning: only initialized variables can be placed into program memory area"
+# to suppress "warning: only initialized variables can be placed into program memory area"
 CXXFLAGS += -w
 CXXFLAGS += -Wall
 CXXFLAGS += -Wundef

diff --git a/docs/_summary.md b/docs/_summary.md
@@ -79,6 +79,7 @@
     * [Caps Word](feature_caps_word.md)
     * [Combos](feature_combo.md)
     * [Debounce API](feature_debounce_type.md)
+    * [EEPROM](feature_eeprom.md)
     * [Key Lock](feature_key_lock.md)
     * [Key Overrides](feature_key_overrides.md)
     * [Layers](feature_layers.md)

diff --git a/docs/api_docs.md b/docs/api_docs.md
@@ -21,7 +21,7 @@ This service is an asynchronous API for compiling custom keymaps. You POST some
 }
 ```
 
-As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports mulitple `LAYOUT` macros you can specify which macro to use.
+As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports multiple `LAYOUT` macros you can specify which macro to use.
 
 ## Submitting a Compile Job
 

diff --git a/docs/cli_commands.md b/docs/cli_commands.md
@@ -223,7 +223,7 @@ Check your environment and report problems only:
 
 ## `qmk format-json`
 
-Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if neccesary.
+Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if necessary.
 
 **Usage**:
 

diff --git a/docs/cli_development.md b/docs/cli_development.md
@@ -162,7 +162,7 @@ del(cli.config.<section>.<key>)
 
 ## Writing The Configuration File
 
-The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberitely using `qmk config`.
+The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberately using `qmk config`.
 
 You can use `cli.save_config()` to write out the configuration.
 

diff --git a/docs/coding_conventions_c.md b/docs/coding_conventions_c.md
@@ -24,7 +24,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
   * Readability is more important than consistency.
   * Follow the file's existing style. If the file is mixed, follow the style that makes sense for the section you are modifying.
   * When indenting, keep the hash at the start of the line and add whitespace between `#` and `if`, starting with 4 spaces after the `#`.
-  * You can follow the indention level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
+  * You can follow the indentation level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
 
 Here is an example for easy reference:
 

diff --git a/docs/coding_conventions_python.md b/docs/coding_conventions_python.md
@@ -2,7 +2,7 @@
 
 Most of our style follows PEP8 with some local modifications to make things less nit-picky. 
 
-* We target Python 3.7 for compatability with all supported platforms.
+* We target Python 3.7 for compatibility with all supported platforms.
 * We indent using four (4) spaces (soft tabs)
 * We encourage liberal use of comments
   * Think of them as a story describing the feature
@@ -21,7 +21,7 @@ You can use [yapf](https://github.com/google/yapf) to style your code. We provid
 
 We don't have a hard and fast rule for when to use `import ...` vs `from ... import ...`. Understandability and maintainability is our ultimate goal.
 
-Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatability module.
+Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatibility module.
 
 Imports should be one line per module. We group import statements together using the standard python rules- system, 3rd party, local.
 

diff --git a/docs/config_options.md b/docs/config_options.md
@@ -2,7 +2,17 @@
 
 QMK is nearly infinitely configurable. Wherever possible we err on the side of allowing users to customize their keyboard, even at the expense of code size. That level of flexibility makes for a daunting configuration experience, however.
 
-There are two main types of configuration files in QMK- `config.h` and `rules.mk`. These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:
+There are three main types of configuration files in QMK:
+
+* `config.h`, which contains various preprocessor directives (`#define`, `#ifdef`)
+* `rules.mk`, which contains additional variables
+* `info.json`, which is utilized for [data-driven configuration](https://docs.qmk.fm/#/data_driven_config)
+
+This page will only discuss the first two types, `config.h` and `rules.mk`.
+
+?> While not all settings have data-driven equivalents yet, keyboard makers are encouraged to utilize the `info.json` file to set the metadata for their boards when possible. See the [`info.json` Format](https://docs.qmk.fm/#/reference_info_json) page for more details.
+
+These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:
 
 * QMK Default
 * Keyboard
@@ -185,7 +195,7 @@ If you define these options you will enable the associated feature, which may in
 * `#define COMBO_TERM 200`
   * how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
 * `#define COMBO_MUST_HOLD_MODS`
-  * Flag for enabling extending timeout on Combos containing modifers
+  * Flag for enabling extending timeout on Combos containing modifiers
 * `#define COMBO_MOD_TERM 200`
   * Allows for extending COMBO_TERM for mod keys while mid-combo.
 * `#define COMBO_MUST_HOLD_PER_COMBO`
-Original file line number
+Diff line change
@@ Expand Up @@
     }
     ```
-    As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports mulitple `LAYOUT` macros you can specify which macro to use.
+    As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports multiple `LAYOUT` macros you can specify which macro to use.
     ## Submitting a Compile Job
@@ Expand Down @@