wip

.github/workflows/info.yml

@@ -1,49 +0,0 @@
-name: PR Lint keyboards
-
-on:
-  pull_request:
-    paths:
-    - 'keyboards/**'
-
-jobs:
-  info:
-    runs-on: ubuntu-latest
-
-    container: qmkfm/base_container
-
-    steps:
-    - uses: actions/checkout@v2
-      with:
-        fetch-depth: 0
-
-    - name: Print info
-      run: |
-        git rev-parse --short HEAD
-        echo ${{ github.event.pull_request.base.sha }}
-        git diff --name-only ${{ github.event.pull_request.base.sha }}...
-
-    - name: Run qmk info
-      shell: 'bash {0}'
-      run: |
-        QMK_CHANGES=$(git diff --name-only ${{ github.event.pull_request.base.sha }}...)
-        QMK_KEYBOARDS=$(qmk list-keyboards)
-
-        exit_code=0
-        for KB in $QMK_KEYBOARDS; do
-          KEYBOARD_CHANGES=$(echo "$QMK_CHANGES" | grep -E '^(keyboards/'${KB}'/)')
-          if [[ -z "$KEYBOARD_CHANGES" ]]; then
-            # skip as no changes for this keyboard
-            continue
-          fi
-
-          KEYMAP_ONLY=$(echo "$KEYBOARD_CHANGES" | grep -cv /keymaps/)
-          if [[ $KEYMAP_ONLY -gt 0 ]]; then
-            echo "linting ${KB}"
-
-            # TODO: info info always returns 0 - right now the only way to know failure is to inspect log lines
-            qmk info -kb ${KB} 2>&1 | tee /tmp/$$
-            !(grep -cq ☒ /tmp/$$)
-            : $((exit_code = $exit_code + $?))
-          fi
-        done
-        exit $exit_code

.gitmodules

@@ -12,13 +12,7 @@
 	branch = master
 [submodule "lib/googletest"]
 	path = lib/googletest
-	url = https://github.com/qmk/googletest
+	url = https://github.com/google/googletest
 [submodule "lib/lufa"]
 	path = lib/lufa
 	url = https://github.com/qmk/lufa
-[submodule "lib/vusb"]
-	path = lib/vusb
-	url = https://github.com/qmk/v-usb
-[submodule "lib/printf"]
-	path = lib/printf
-	url = https://github.com/qmk/printf

Makefile

@@ -29,9 +29,6 @@ $(info QMK Firmware $(QMK_VERSION))
 endif
 endif
 
-# avoid 'Entering|Leaving directory' messages
-MAKEFLAGS += --no-print-directory
-
 ON_ERROR := error_occurred=1
 
 BREAK_ON_ERRORS = no
@@ -294,8 +291,8 @@ define PARSE_RULE
         $$(info |  QMK's make format recently changed to use folder locations and colons:)
         $$(info |     make project_folder:keymap[:target])
         $$(info |  Examples:)
-        $$(info |     make dz60:default)
-        $$(info |     make planck/rev6:default:flash)
+        $$(info |     make planck/rev4:default:dfu)
+        $$(info |     make planck:default)
         $$(info |)
     endif
 endef
@@ -560,57 +557,38 @@ endef
 # Let's match everything, we handle all the rule parsing ourselves
 .PHONY: %
 %:
-	# Check if we have the CMP tool installed
-	cmp $(ROOT_DIR)/Makefile $(ROOT_DIR)/Makefile >/dev/null 2>&1; if [ $$? -gt 0 ]; then printf "$(MSG_NO_CMP)"; exit 1; fi;
-	# Ensure that bin/qmk works. This will be a failing check after the next develop merge on 2020 Aug 29.
-	if ! bin/qmk hello 1> /dev/null 2>&1; then printf "$(MSG_PYTHON_MISSING)"; fi
-	# Check if the submodules are dirty, and display a warning if they are
-ifndef SKIP_GIT
-	if [ ! -e lib/chibios ]; then git submodule sync lib/chibios && git submodule update --depth 50 --init lib/chibios; fi
-	if [ ! -e lib/chibios-contrib ]; then git submodule sync lib/chibios-contrib && git submodule update --depth 50 --init lib/chibios-contrib; fi
-	if [ ! -e lib/ugfx ]; then git submodule sync lib/ugfx && git submodule update --depth 50 --init lib/ugfx; fi
-	if [ ! -e lib/lufa ]; then git submodule sync lib/lufa && git submodule update --depth 50 --init lib/lufa; fi
-	if [ ! -e lib/vusb ]; then git submodule sync lib/vusb && git submodule update --depth 50 --init lib/vusb; fi
-	if [ ! -e lib/printf ]; then git submodule sync lib/printf && git submodule update --depth 50 --init lib/printf; fi
-	git submodule status --recursive 2>/dev/null | \
-	while IFS= read -r x; do \
-		case "$$x" in \
-			\ *) ;; \
-			*) printf "$(MSG_SUBMODULE_DIRTY)";break;; \
-		esac \
-	done
-endif
-	rm -f $(ERROR_FILE) > /dev/null 2>&1
-	$(eval $(call PARSE_RULE,$@))
-	$(eval $(call SET_SILENT_MODE))
-	# Run all the commands in the same shell, notice the + at the first line
-	# it has to be there to allow parallel execution of the submake
-	# This always tries to compile everything, even if error occurs in the middle
-	# But we return the error code at the end, to trigger travis failures
-	# The sort at this point is to remove duplicates
-	$(foreach COMMAND,$(sort $(COMMANDS)),$(RUN_COMMAND))
-	if [ -f $(ERROR_FILE) ]; then printf "$(MSG_ERRORS)" & exit 1; fi;
-	$(foreach TEST,$(sort $(TESTS)),$(RUN_TEST))
-	if [ -f $(ERROR_FILE) ]; then printf "$(MSG_ERRORS)" & exit 1; fi;
+#	# Check if we have the CMP tool installed
+#	cmp $(ROOT_DIR)/Makefile $(ROOT_DIR)/Makefile >/dev/null 2>&1; if [ $$? -gt 0 ]; then printf "$(MSG_NO_CMP)"; exit 1; fi;
+#	# Ensure that python3 is installed. This check can be removed after python is used in more places.
+#	if ! python3 --version 1> /dev/null 2>&1; then printf "$(MSG_PYTHON_MISSING)"; fi
+#	# Check if the submodules are dirty, and display a warning if they are
+#ifndef SKIP_GIT
+#	if [ ! -e lib/chibios ]; then git submodule sync lib/chibios && git submodule update --depth 50 --init lib/chibios; fi
+#	if [ ! -e lib/chibios-contrib ]; then git submodule sync lib/chibios-contrib && git submodule update --depth 50 --init lib/chibios-contrib; fi
+#	if [ ! -e lib/ugfx ]; then git submodule sync lib/ugfx && git submodule update --depth 50 --init lib/ugfx; fi
+#	if [ ! -e lib/lufa ]; then git submodule sync lib/lufa && git submodule update --depth 50 --init lib/lufa; fi
+#	git submodule status --recursive 2>/dev/null | \
+#	while IFS= read -r x; do \
+#		case "$$x" in \
+#			\ *) ;; \
+#			*) printf "$(MSG_SUBMODULE_DIRTY)";break;; \
+#		esac \
+#	done
+#endif
+#	rm -f $(ERROR_FILE) > /dev/null 2>&1
+#	$(eval $(call PARSE_RULE,$@))
+#	$(eval $(call SET_SILENT_MODE))
+#	# Run all the commands in the same shell, notice the + at the first line
+#	# it has to be there to allow parallel execution of the submake
+#	# This always tries to compile everything, even if error occurs in the middle
+#	# But we return the error code at the end, to trigger travis failures
+#	# The sort at this point is to remove duplicates
+#	$(foreach COMMAND,$(sort $(COMMANDS)),$(RUN_COMMAND))
+#	if [ -f $(ERROR_FILE) ]; then printf "$(MSG_ERRORS)" & exit 1; fi;
+#	$(foreach TEST,$(sort $(TESTS)),$(RUN_TEST))
+#	if [ -f $(ERROR_FILE) ]; then printf "$(MSG_ERRORS)" & exit 1; fi;
 
-# These no longer work because of the colon system
-
-# All should compile everything
-# .PHONY: all
-# all: all-keyboards test-all
-
-# Define some shortcuts, mostly for compatibility with the old syntax
-# .PHONY: all-keyboards
-# all-keyboards: all\:all\:all
-
-# .PHONY: all-keyboards-defaults
-# all-keyboards-defaults: all\:default
-
-# .PHONY: test
-# test: test-all
-
-# .PHONY: test-clean
-# test-clean: test-all-clean
+	bin/qmk makehandler $@
 
 lib/%:
 	git submodule sync $?

Vagrantfile

@@ -89,7 +89,7 @@ Vagrant.configure(2) do |config|
 
   Examples:
      make planck/rev4:default:dfu
-     make planck/rev4:default
+     make planck:default
 
   EOT
 end

common_features.mk

@@ -70,7 +70,7 @@ ifeq ($(strip $(POINTING_DEVICE_ENABLE)), yes)
     SRC += $(QUANTUM_DIR)/pointing_device.c
 endif
 
-VALID_EEPROM_DRIVER_TYPES := vendor custom transient i2c spi
+VALID_EEPROM_DRIVER_TYPES := vendor custom transient i2c
 EEPROM_DRIVER ?= vendor
 ifeq ($(filter $(EEPROM_DRIVER),$(VALID_EEPROM_DRIVER_TYPES)),)
   $(error EEPROM_DRIVER="$(EEPROM_DRIVER)" is not a valid EEPROM driver)
@@ -85,11 +85,6 @@ else
     COMMON_VPATH += $(DRIVER_PATH)/eeprom
     QUANTUM_LIB_SRC += i2c_master.c
     SRC += eeprom_driver.c eeprom_i2c.c
-  else ifeq ($(strip $(EEPROM_DRIVER)), spi)
-    OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_SPI
-    COMMON_VPATH += $(DRIVER_PATH)/eeprom
-    QUANTUM_LIB_SRC += spi_master.c
-    SRC += eeprom_driver.c eeprom_spi.c
   else ifeq ($(strip $(EEPROM_DRIVER)), transient)
     OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_TRANSIENT
     COMMON_VPATH += $(DRIVER_PATH)/eeprom
@@ -144,7 +139,7 @@ ifeq ($(strip $(RGBLIGHT_ENABLE)), yes)
     endif
 endif
 
-VALID_MATRIX_TYPES := yes IS31FL3731 IS31FL3733 IS31FL3737 IS31FL3741 WS2812 custom
+VALID_MATRIX_TYPES := yes IS31FL3731 IS31FL3733 IS31FL3737 WS2812 custom
 
 LED_MATRIX_ENABLE ?= no
 ifneq ($(strip $(LED_MATRIX_ENABLE)), no)
@@ -205,13 +200,6 @@ ifeq ($(strip $(RGB_MATRIX_ENABLE)), IS31FL3737)
     QUANTUM_LIB_SRC += i2c_master.c
 endif
 
-ifeq ($(strip $(RGB_MATRIX_ENABLE)), IS31FL3741)
-    OPT_DEFS += -DIS31FL3741 -DSTM32_I2C -DHAL_USE_I2C=TRUE
-    COMMON_VPATH += $(DRIVER_PATH)/issi
-    SRC += is31fl3741.c
-    QUANTUM_LIB_SRC += i2c_master.c
-endif
-
 ifeq ($(strip $(RGB_MATRIX_ENABLE)), WS2812)
     OPT_DEFS += -DWS2812
     WS2812_DRIVER_REQUIRED := yes

docs/ChangeLog/20200530.md

@@ -1,239 +0,0 @@
-# QMK Breaking Change - 2020 May 30 Changelog
-
-Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps.
-
-The list of changes follows.
-
-
-## Core Changes
-
-### Converting V-USB usbdrv to a submodule
-
-[#8321](https://github.com/qmk/qmk_firmware/pull/8321) and [qmk_compiler#62](https://github.com/qmk/qmk_compiler/pull/62).
-
-These PRs move the V-USB driver code out of the qmk_firmware repository and into a submodule pointed at https://github.com/obdev/v-usb. This will make it easier to update the codebase if needed, while applying any potential QMK-specific modifications by forking it to the QMK GitHub organization.
-
-### Unify Tap Hold functions and documentation
-
-[#8348](https://github.com/qmk/qmk_firmware/pull/8348)
-
-Updates all of the per key tap-hold functions to pass the `keyrecord_t` structure, and include documentation changes.
-
-Any remaining versions or code outside of the main repo will need to be converted: 
-| Old function                                         | New Function                                                              |
-|------------------------------------------------------|---------------------------------------------------------------------------|
-|`uint16_t get_tapping_term(uint16_t keycode)`         |`uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record)`         |
-|`bool get_ignore_mod_tap_interrupt(uint16_t keycode)` |`bool get_ignore_mod_tap_interrupt(uint16_t keycode, keyrecord_t *record)` |
-
-### Python Required In The Build Process
-
-[#9000](https://github.com/qmk/qmk_firmware/pull/9000)
-
-This is the last release of QMK that will work without having Python 3.6 (or later) installed. If your environment is not fully setup you will get a warning instructing you to set it up.
-
-After the next breaking change you will not be able to build if `bin/qmk hello` does not work.
-
-### Upgrade from tinyprintf to mpaland/printf
-
-[#8269](https://github.com/qmk/qmk_firmware/pull/8269)
-
-- Provides debug functionality on ChibiOS/ARM that is more compliant than previous integrations.
-- Less maintenence, fewer QMK customisations, and allows QMK to sidestep previous compile and runtime issues.
-- A `make git-submodule` may be required after pulling the latest QMK Firmware code to update to the new dependency.
-
-### Fixed RGB_DISABLE_AFTER_TIMEOUT to be seconds based & small internals cleanup
-
-[#6480](https://github.com/qmk/qmk_firmware/pull/6480)
-
-- Changes `RGB_DISABLE_AFTER_TIMEOUT` to be based on milliseconds instead of ticks.
-- Includes a code cleanup, resulting in a savings of 100 bytes, depending on features used.
-- Fixed issues with timeouts / suspending at the wrong time not turning off all LEDs in some cases.
-
-The `RGB_DISABLE_AFTER_TIMEOUT` definition is now deprecated, and has been superseded by `RGB_DISABLE_TIMEOUT`. To use the new definition, rename `RGB_DISABLE_AFTER_TIMEOUT` to `RGB_DISABLE_TIMEOUT` in your `config.h` file, and multiply the value set by 1200.
-
-Before: `#define RGB_DISABLE_AFTER_TIMEOUT 100`  
-After: `#define RGB_DISABLE_TIMEOUT 120000`
-
-### Switch to qmk forks for everything
-
-[#9019](https://github.com/qmk/qmk_firmware/pull/9019)
-
-Fork all QMK submodules to protect against upstream repositories disappearing.
-
-### code cleanup regarding deprecated macro PLAY_NOTE_ARRAY by replacing it with PLAY_SONG
-
-[#8484](https://github.com/qmk/qmk_firmware/pull/8484)
-
-Removes the deprecated `PLAY_NOTE_ARRAY` macro. References to it are replaced with `PLAY_SONG`, which references the same function.
-
-### fixing wrong configuration of AUDIO feature
-
-[#8903](https://github.com/qmk/qmk_firmware/pull/8903) and [#8974](https://github.com/qmk/qmk_firmware/pull/8974)
-
-`audio_avr.c` does not default to any pin; there has to be a #define XX_AUDIO in config.h at some level for Audio to actually work. Otherwise, the Audio code ends up cluttering the firmware, possibly breaking builds because the maximum allowed firmware size is exceeded.
-
-These changes fix this by disabling Audio on keyboards that have the feature misconfigured, and therefore non-functional.
-
-Also, add a compile-time error to alert the user to a missing pin-configuration (on AVR boards) when `AUDIO_ENABLE = yes` is set.
-
-
-## Keyboard Refactors
-
-### Migrating Lily58 to use split_common
-
-[#6260](https://github.com/qmk/qmk_firmware/pull/6260)
-
-Modifies the default firmware for Lily58 to use the `split_common` library, instead of including and depending on its own set of libraries for the following functionality:
-
-- SSD1306 display
-- i2c for OLED
-- Serial Communication
-
-This allows current lily58 firmware to advance with updates to the `split_common` library, which is shared with many other split keyboards.
-
-#### To migrate existing Lily58 firmware:
-
-[Changes to `config.h`](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-445ac369c8717dcd6fc6fc3630836fc1):
-- Remove `#define SSD1306OLED` from config.h
-
-
-[Changes to `keymap.c`](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7):
-- Find/Replace each instance of `#ifdef SSD1306OLED` with `#ifdef OLED_DRIVER_ENABLE`
-- The following changes are for compatibility with the OLED driver. If you don't use the OLED driver you may safely delete [this section](https://github.com/qmk/qmk_firmware/blob/e6b9980bd45c186f7360df68c24b6e05a80c10dc/keyboards/lily58/keymaps/default/keymap.c#L144-L190)
-- Alternatively, if you did not change the OLED code from that in `default`, you may find it easier to simply copy the [relevant section](https://github.com/qmk/qmk_firmware/blob/4ac310668501ae6786c711ecc8f01f62ddaa1c0b/keyboards/lily58/keymaps/default/keymap.c#L138-L172). Otherwise, the changes you need to make are as follows (sample change [here](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7R138-R173))
-- [Remove](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7L138-L141) the block
-```c
-#ifdef SSD1306OLED	
-  iota_gfx_init(!has_usb());   // turns on the display	
-#endif
-```
-- Within the block bounded by `#ifdef OLED_DRIVER_ENABLE` and `#endif // OLED_DRIVER_ENABLE`, add the following block to ensure that your two OLEDs are rotated correctly across the left and right sides:
-```c
-oled_rotation_t oled_init_user(oled_rotation_t rotation) {
-  if (!is_keyboard_master())
-    return OLED_ROTATION_180;  // flips the display 180 degrees if offhand
-  return rotation;
-}
-```
-- Remove the functions `matrix_scan_user`, `matrix_update` and `iota_gfx_task_user`
-- Find/Replace `matrix_render_user(struct CharacterMatrix *matrix)` with `iota_gfx_task_user(void)`
-- Find/Replace `is_master` with `is_keyboard_master()`
-- For each instance of `matrix_write_ln(matrix, display_fn())`, rewrite it as `oled_write_ln(read_layer_state(), false);`
-- For each instance of `matrix_write(matrix, read_logo());`, replace with `oled_write(read_logo(), false);`
-
-### Refactor zinc to use split_common
-
-[#7114](https://github.com/qmk/qmk_firmware/pull/7114) and [#9171](https://github.com/qmk/qmk_firmware/pull/9171)
-
-* Refactor to use split_common and remove split codes under the zinc/revx/
-* Add - backlight RGB LED and/or underglow RGB LED option
-* Add - continuous RGB animations feature (between L and R halves) 
-* Fix - keymap files to adapt to changes
-    * all authors of keymaps confirmed this PR
-* Update - documents and rules.mk
-
-### Refactor of TKC1800 to use common OLED code
-
-[#8472](https://github.com/qmk/qmk_firmware/pull/8472)
-
-Modifies the default firmware for TKC1800 to use the in-built I2C and OLED drivers, instead of including and depending on its own set of libraries for the following functionality:
-
-- SSD1306 display
-- i2c for OLED
-
-This allows current TKC1800 firmware to advance with updates to those drivers, which are shared with other keyboards.
-
-#### To migrate existing TKC1800 firmware:
-
-[Changes to `config.h`](https://github.com/qmk/qmk_firmware/pull/8472/files#diff-d10b26e676b4a55cbb00d71955116526):
-- Remove `#define SSD1306OLED` from config.h
-
-[Changes to `tkc1800.c`](https://github.com/qmk/qmk_firmware/pull/8472/files#diff-3b35bd30abe89c8110717c6972cd2cc5):
-- Add the following to avoid debug errors on HID_listen if the screen is not present
-```c
-void keyboard_pre_init_kb(void) {
-  setPinInputHigh(D0);
-  setPinInputHigh(D1);
-
-  keyboard_pre_init_user();
-}
-```
-
-[Changes to `keymap.c`](https://github.com/qmk/qmk_firmware/pull/8472/files#diff-05a2a344ce27e4d045fe68520ccd4771):
-- Find/Replace each instance of `#ifdef SSD1306OLED` with `#ifdef OLED_DRIVER_ENABLE`
-- The following changes are for compatibility with the OLED driver. If you don't use the OLED driver you may safely delete [this section](https://github.com/qmk/qmk_firmware/blob/e6b9980bd45c186f7360df68c24b6e05a80c10dc/keyboards/lily58/keymaps/default/keymap.c#L144-L190)
-- [Remove](https://github.com/qmk/qmk_firmware/pull/6260/files#diff-20943ea59856e9bdf3d99ecb2eee40b7L91-L158) the block
-```c
-#ifdef SSD1306OLED	
-  iota_gfx_init(!has_usb());   // turns on the display	
-#endif
-```
-- Within the block bounded by `#ifdef OLED_DRIVER_ENABLE` and `#endif // OLED_DRIVER_ENABLE`, add the following block to ensure that your two OLEDs are rotated correctly across the left and right sides:
-```c
-oled_rotation_t oled_init_user(oled_rotation_t rotation) {
-  if (!is_keyboard_master())
-    return OLED_ROTATION_180;  // flips the display 180 degrees if offhand
-  return rotation;
-}
-```
-- Remove the function `iota_gfx_task_user`
-
-### Split HHKB to ANSI and JP layouts and Add VIA support for each
-
-[#8582](https://github.com/qmk/qmk_firmware/pull/8582)
-
-- Splits the HHKB codebase into two separate folders `keyboards/hhkb/ansi` and `keyboards/hhkb/jp`.
-- Adds VIA Configurator support for both versions.
-
-#### Migrating existing HHKB keymaps
-
-- Remove any checks for the `HHKB_JP` definition
-  - All checks for this definition have been removed, and each version uses the source that is appropriate to that version.
-- Move the directory for your keymap into the appropriate `keymaps` directory
-  - `keyboards/hhkb/ansi/keymaps/` for ANSI HHKBs
-  - `keyboards/hhkb/jp/keymaps/` for HHKB JPs
-- Compile with the new keyboard names
-  - This PR changes the compilation instructions for the HHKB Alternate Controller. To compile firmware for this controller moving forward, use:
-    - `make hhkb/ansi` for ANSI-layout HHKBs
-    - `make hhkb/jp` for HHKB JP keyboards
-
-
-## Keyboard Moves
-
-- [#8412](https://github.com/qmk/qmk_firmware/pull/8412 "Changing board names to prevent confusion") by blindassassin111
-- [#8499](https://github.com/qmk/qmk_firmware/pull/8499 "Move the Keyboardio Model01 to a keyboardio/ subdir") by algernon
-- [#8830](https://github.com/qmk/qmk_firmware/pull/8830 "Move spaceman keyboards") by Spaceman (formerly known as Rionlion100)
-- [#8537](https://github.com/qmk/qmk_firmware/pull/8537 "Organizing my keyboards (plaid, tartan, ergoinu)") by hsgw
-
-Keyboards by Keyboardio, Spaceman, and hsgw move to vendor folders, while PCBs designed by blindassassin111 are renamed.
-
-Old Name           | New Name
-:----------------- | :-----------------
-2_milk             | spaceman/2_milk
-at101_blackheart   | at101_bh
-ergoinu            | dm9records/ergoinu
-model01            | keyboardio/model01
-omnikey_blackheart | omnikey_bh
-pancake            | spaceman/pancake
-plaid              | dm9records/plaid
-tartan             | dm9records/tartan
-z150_blackheart    | z150_bh
-
-If you own one of these PCBs, please use the new names to compile your firmware moving forward.
-
-
-## Keycode Migration PRs
-
-[#8954](https://github.com/qmk/qmk_firmware/pull/8954 "Migrate `ACTION_LAYER_TOGGLE` to `TG()`"), [#8957](https://github.com/qmk/qmk_firmware/pull/8957 "Migrate `ACTION_MODS_ONESHOT` to `OSM()`"), [#8958](https://github.com/qmk/qmk_firmware/pull/8958 "Migrate `ACTION_DEFAULT_LAYER_SET` to `DF()`"), [#8959](https://github.com/qmk/qmk_firmware/pull/8959 "Migrate `ACTION_LAYER_MODS` to `LM()`"), [#8968](https://github.com/qmk/qmk_firmware/pull/8968 "Migrate `ACTION_MODS_TAP_KEY` to `MT()`"), [#8977](https://github.com/qmk/qmk_firmware/pull/8977 "Migrate miscellaneous `fn_actions` entries"), and [#8979](https://github.com/qmk/qmk_firmware/pull/8979 "Migrate `ACTION_MODS_KEY` to chained mod keycodes")
-
-Authored by fauxpark, these pull requests remove references to deprecated TMK macros that have been superseded by native QMK keycodes.
-
-Old `fn_actions` action | New QMK keycode
-:---------------------- | :--------------
-`ACTION_DEFAULT_LAYER_SET(layer)` | `DF(layer)`
-`ACTION_LAYER_MODS(layer, mod)` | `LM(layer, mod)`
-`ACTION_LAYER_ONESHOT(mod)` | `OSL(mod)`
-`ACTION_LAYER_TOGGLE(layer)` | `TG(layer)`
-`ACTION_MODS_ONESHOT(mod)` | `OSM(mod)`
-`ACTION_MODS_TAP_KEY(mod, kc)` | `MT(mod, kc)`
-`ACTION_MODS_KEY(mod, kc)`<br>e.g. `ACTION_MODS_KEY(MOD_LCTL, KC_0)` | `MOD(kc)`<br>e.g. `LCTL(KC_0)`

docs/_summary.md

@@ -34,9 +34,7 @@
     * [Customizing Functionality](custom_quantum_functions.md)
     * [Driver Installation with Zadig](driver_installation_zadig.md)
     * [Keymap Overview](keymap.md)
-    * Development Environments
-      * [Docker Guide](getting_started_docker.md)
-      * [Vagrant Guide](getting_started_vagrant.md)
+    * [Vagrant Guide](getting_started_vagrant.md)
     * Flashing
       * [Flashing](flashing.md)
       * [Flashing ATmega32A (ps2avrgb)](flashing_bootloadhid.md)
@@ -55,7 +53,6 @@
   * Simple Keycodes
     * [Full List](keycodes.md)
     * [Basic Keycodes](keycodes_basic.md)
-    * [Language-Specific Keycodes](reference_keymap_extras.md)
     * [Modifier Keys](feature_advanced_keycodes.md)
     * [Quantum Keycodes](quantum_keycodes.md)
 
@@ -78,7 +75,6 @@
     * [Layers](feature_layers.md)
     * [One Shot Keys](one_shot_keys.md)
     * [Pointing Device](feature_pointing_device.md)
-    * [Raw HID](feature_rawhid.md)
     * [Swap Hands](feature_swap_hands.md)
     * [Tap Dance](feature_tap_dance.md)
     * [Tap-Hold Configuration](tap_hold.md)
@@ -115,7 +111,6 @@
     * [Overview](breaking_changes.md)
     * [My Pull Request Was Flagged](breaking_changes_instructions.md)
     * History
-      * [2020 May 30](ChangeLog/20200530.md)
       * [2020 Feb 29](ChangeLog/20200229.md)
       * [2019 Aug 30](ChangeLog/20190830.md)
 
@@ -130,7 +125,6 @@
       * [SPI Driver](spi_driver.md)
       * [WS2812 Driver](ws2812_driver.md)
       * [EEPROM Driver](eeprom_driver.md)
-      * ['serial' Driver](serial_driver.md)
     * [GPIO Controls](internals_gpio_control.md)
     * [Keyboard Guidelines](hardware_keyboard_guidelines.md)
 
@@ -145,7 +139,6 @@
 
   * Hardware Platform Development
     * Arm/ChibiOS
-      * [Selecting an MCU](platformdev_selecting_arm_mcu.md)
       * [Early initialization](platformdev_chibios_earlyinit.md)
 
   * QMK Reference

docs/adc_driver.md

@@ -22,7 +22,7 @@ Then place this include at the top of your code:
 
 ### AVR
 
-|Channel|AT90USB64/128|ATmega16/32U4|ATmega32A|ATmega328/P|
+|Channel|AT90USB64/128|ATmega16/32U4|ATmega32A|ATmega328P|
 |-------|-------------|-------------|---------|----------|
 |0      |`F0`         |`F0`         |`A0`     |`C0`      |
 |1      |`F1`         |`F1`         |`A1`     |`C1`      |
@@ -39,7 +39,7 @@ Then place this include at the top of your code:
 |12     |             |`B5`         |         |          |
 |13     |             |`B6`         |         |          |
 
-<sup>\* The ATmega328/P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
+<sup>\* The ATmega328P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
 
 ### ARM
 

docs/breaking_changes.md

@@ -6,28 +6,27 @@ The breaking change period is when we will merge PR's that change QMK in dangero
 
 ## What has been included in past Breaking Changes?
 
-* [2020 May 30](ChangeLog/20200530.md)
 * [2020 Feb 29](ChangeLog/20200229.md)
 * [2019 Aug 30](ChangeLog/20190830.md)
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for Aug 29, 2020.
+The next Breaking Change is scheduled for May 30, 2020.
 
 ### Important Dates
 
-* [x] 2020 May 30 - `develop` is created. It will be rebased weekly.
-* [ ] 2020 Aug 1 - `develop` closed to new PR's.
-* [ ] 2020 Aug 1 - Call for testers.
-* [ ] 2020 Aug 27 - `master` is locked, no PR's merged.
-* [ ] 2020 Aug 29 - Merge `develop` to `master`.
-* [ ] 2020 Aug 29 - `master` is unlocked. PR's can be merged again.
+* [x] 2020 Feb 29 - `future` is created. It will be rebased weekly.
+* [ ] 2020 May 2 - `future` closed to new PR's.
+* [ ] 2020 May 2 - Call for testers.
+* [ ] 2020 May 28 - `master` is locked, no PR's merged.
+* [ ] 2020 May 30 - Merge `future` to `master`.
+* [ ] 2020 May 30 - `master` is unlocked. PR's can be merged again.
 
 ## What changes will be included?
 
-To see a list of breaking change candidates you can look at the [`breaking_change` label](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). New changes might be added between now and when `develop` is closed, and a PR with that label applied is not guaranteed to be merged.
+To see a list of breaking change candidates you can look at the [`breaking_change` label](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). New changes might be added between now and when `future` is closed, and a PR with that label applied is not guaranteed to be merged.
 
-If you want your breaking change to be included in this round you need to create a PR with the `breaking_change` label and have it accepted before `develop` closes. After `develop` closes no new breaking changes will be accepted.
+If you want your breaking change to be included in this round you need to create a PR with the `breaking_change` label and have it accepted before `future` closes. After `future` closes no new breaking changes will be accepted.
 
 Criteria for acceptance:
 
@@ -38,9 +37,9 @@ Criteria for acceptance:
 
 This section documents various processes we use when running the Breaking Changes process.
 
-## Rebase `develop` from `master`
+## Rebase `future` from `master`
 
-This is run every Friday while `develop` is open.
+This is run every Friday while `future` is open.
 
 Process:
 
@@ -48,31 +47,31 @@ Process:
 cd qmk_firmware
 git checkout master
 git pull --ff-only
-git checkout develop
+git checkout future
 git rebase master
 git push --force
 ```
 
-## Creating the `develop` branch
+## Creating the `future` branch
 
-This happens immediately after the previous `develop` branch is merged.
+This happens immediately after the previous `future` branch is merged.
 
 * `qmk_firmware` git commands
     * [ ] `git checkout master`
     * [ ] `git pull --ff-only`
-    * [ ] `git checkout -b develop`
+    * [ ] `git checkout -b future`
     * [ ] Edit `readme.md`
         * [ ] Add a big notice at the top that this is a testing branch.
         * [ ] Include a link to this document
     * [ ] `git commit -m 'Branch point for <DATE> Breaking Change'`
     * [ ] `git tag breakpoint_<YYYY>_<MM>_<DD>`
     * [ ] `git tag <next_version>` # Prevent the breakpoint tag from confusing version incrementing
-    * [ ] `git push origin develop`
+    * [ ] `git push origin future`
     * [ ] `git push --tags`
 
 ## 4 Weeks Before Merge
 
-* `develop` is now closed to new PR's, only fixes for current PR's may be merged
+* `future` is now closed to new PR's, only fixes for current PR's may be merged
 * Post call for testers
     * [ ] Discord
     * [ ] GitHub PR
@@ -95,15 +94,15 @@ This happens immediately after the previous `develop` branch is merged.
 ## Day Of Merge
 
 * `qmk_firmware` git commands
-    * [ ] `git checkout develop`
+    * [ ] `git checkout future`
     * [ ] `git pull --ff-only`
     * [ ] `git rebase origin/master`
     * [ ] Edit `readme.md`
-        * [ ] Remove the notes about `develop`
+        * [ ] Remove the notes about `future`
     * [ ] Roll up the ChangeLog into one file.
     * [ ] `git commit -m 'Merge point for <DATE> Breaking Change'`
-    * [ ] `git push origin develop`
-* GitHub Actions
-    * [ ] Create a PR for `develop`
+    * [ ] `git push origin future`
+* Github Actions
+    * [ ] Create a PR for `future`
     * [ ] Make sure travis comes back clean
-    * [ ] Merge `develop` PR
+    * [ ] Merge `future` PR

docs/breaking_changes_instructions.md

@@ -27,7 +27,7 @@ If you are contributing core code, and the only reason it needs to go through br
 
 We require submissions that go through the Breaking Change process to include a changelog entry. The entry should be a short summary of the changes your pull request makes – [each section here started as a changelog](ChangeLog/20190830.md "n.b. This should link to the 2019 Aug 30 Breaking Changes doc  - @noroadsleft").
 
-Your changelog should be located at `docs/ChangeLog/YYYYMMDD/PR####.md`, where `YYYYMMDD` is the date on which QMK's breaking change branch – usually named `develop` – will be merged into the `master` branch, and `####` is the number of your pull request.
+Your changelog should be located at `docs/ChangeLog/YYYYMMDD/PR####.md`, where `YYYYMMDD` is the date on which QMK's breaking change branch – usually named `future` – will be merged into the `master` branch, and `####` is the number of your pull request.
 
 If your submission requires action on the part of users, your changelog should instruct users what action(s) must be taken, or link to a location that does so.
 

docs/cli.md

@@ -13,17 +13,18 @@ QMK requires Python 3.6 or greater. We try to keep the number of requirements sm
 If you have installed [Homebrew](https://brew.sh) you can tap and install QMK:
 
 ```
-brew install qmk/qmk/qmk
+brew tap qmk/qmk
+brew install qmk
 export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
 qmk setup  # This will clone `qmk/qmk_firmware` and optionally set up your build environment
 ```
 
-### Install Using pip :id=install-using-easy_install-or-pip
+### Install Using easy_install or pip :id=install-using-easy_install-or-pip
 
-If your system is not listed above you can install QMK manually. First ensure that you have Python 3.6 (or later) installed and have installed pip. Then install QMK with this command:
+If your system is not listed above you can install QMK manually. First ensure that you have python 3.6 (or later) installed and have installed pip. Then install QMK with this command:
 
 ```
-python3 -m pip install qmk
+pip3 install qmk
 export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
 qmk setup  # This will clone `qmk/qmk_firmware` and optionally set up your build environment
 ```

docs/cli_commands.md

@@ -6,8 +6,6 @@
 
 This command allows you to compile firmware from any directory. You can compile JSON exports from <https://config.qmk.fm>, compile keymaps in the repo, or compile the keyboard in the current working directory.
 
-This command is directory aware. It will automatically fill in KEYBOARD and/or KEYMAP if you are in a keyboard or keymap directory.
-
 **Usage for Configurator Exports**:
 
 ```
@@ -75,9 +73,8 @@ $ qmk compile -kb dz60
 
 ## `qmk flash`
 
-This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default. To specify a different bootloader, use `-bl <bootloader>`. Visit the [Flashing Firmware](flashing.md) guide for more details of the available bootloaders.
-
-This command is directory aware. It will automatically fill in KEYBOARD and/or KEYMAP if you are in a keyboard or keymap directory.
+This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default.
+To specify a different bootloader, use `-bl <bootloader>`. Visit the [Flashing Firmware](flashing.md) guide for more details of the available bootloaders.
 
 **Usage for Configurator Exports**:
 
@@ -131,32 +128,6 @@ Check your environment and report problems only:
 
     qmk doctor -n
 
-## `qmk info`
-
-Displays information about keyboards and keymaps in QMK. You can use this to get information about a keyboard, show the layouts, display the underlying key matrix, or to pretty-print JSON keymaps.
-
-**Usage**:
-
-```
-qmk info [-f FORMAT] [-m] [-l] [-km KEYMAP] [-kb KEYBOARD]
-```
-
-This command is directory aware. It will automatically fill in KEYBOARD and/or KEYMAP if you are in a keyboard or keymap directory.
-
-**Examples**:
-
-Show basic information for a keyboard:
-
-    qmk info -kb planck/rev5
-
-Show the matrix for a keyboard:
-
-    qmk info -kb ergodox_ez -m
-
-Show a JSON keymap for a keyboard:
-
-    qmk info -kb clueboard/california -km default
-
 ## `qmk json2c`
 
 Creates a keymap.c from a QMK Configurator export.
@@ -181,8 +152,6 @@ qmk list-keyboards
 
 This command lists all the keymaps for a specified keyboard (and revision).
 
-This command is directory aware. It will automatically fill in KEYBOARD if you are in a keyboard directory.
-
 **Usage**:
 
 ```
@@ -193,8 +162,6 @@ qmk list-keymaps -kb planck/ez
 
 This command creates a new keymap based on a keyboard's existing default keymap.
 
-This command is directory aware. It will automatically fill in KEYBOARD and/or KEYMAP if you are in a keyboard or keymap directory.
-
 **Usage**:
 
 ```

docs/cli_configuration.md

@@ -108,7 +108,7 @@ compile.keymap: skully -> None
 |-----|---------------|-------------|
 | user.keyboard | None | The keyboard path (Example: `clueboard/66/rev4`) |
 | user.keymap | None | The keymap name (Example: `default`) |
-| user.name | None | The user's GitHub username. |
+| user.name | None | The user's github username. |
 
 # All Configuration Options
 

docs/cli_development.md

@@ -210,7 +210,7 @@ Our tests can be found in `lib/python/qmk/tests/`. You will find both unit and i
 
 If your PR does not include a comprehensive set of tests please add comments like this to your code so that other people know where they can help:
 
-    # TODO(unassigned/<your_github_username>): Write <unit|integration> tests
+    # TODO(unassigned/<yourGithubUsername>): Write <unit|integration> tests
 
 We use [nose2](https://nose2.readthedocs.io/en/latest/getting_started.html) to run our tests. You can refer to the nose2 documentation for more details on what you can do in your test functions.
 

docs/compatible_microcontrollers.md

@@ -14,7 +14,6 @@ Certain MCUs which do not have native USB will use [V-USB](https://www.obdev.at/
 
 * [ATmega32A](https://www.microchip.com/wwwproducts/en/ATmega32A)
 * [ATmega328P](https://www.microchip.com/wwwproducts/en/ATmega328P)
-* [ATmega328](https://www.microchip.com/wwwproducts/en/ATmega328)
 
 ## ARM
 

docs/config_options.md

@@ -191,14 +191,7 @@ If you define these options you will enable the associated feature, which may in
 * `#define RGBLIGHT_ANIMATIONS`
   * run RGB animations
 * `#define RGBLIGHT_LAYERS`
-  * Lets you define [lighting layers](feature_rgblight.md?id=lighting-layers) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
-* `#define RGBLIGHT_MAX_LAYERS`
-  * Defaults to 8. Can be expanded up to 32 if more [lighting layers](feature_rgblight.md?id=lighting-layers) are needed.
-  * Note: Increasing the maximum will increase the firmware size and slow sync on split keyboards.
-* `#define RGBLIGHT_LAYER_BLINK` 
-  * Adds ability to [blink](feature_rgblight.md?id=lighting-layer-blink) a lighting layer for a specified number of milliseconds (e.g. to acknowledge an action).
-* `#define RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF`
-  * If defined, then [lighting layers](feature_rgblight?id=overriding-rgb-lighting-onoff-status) will be shown even if RGB Light is off.
+  * Lets you define [lighting layers](feature_rgblight.md) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
 * `#define RGBLED_NUM 12`
   * number of LEDs
 * `#define RGBLIGHT_SPLIT`

docs/configurator_step_by_step.md

@@ -12,7 +12,7 @@ I'll say that again because it's important:
 
 !> **MAKE SURE YOU SELECT THE RIGHT VERSION!**
 
-If your keyboard has been advertised to be powered by QMK but is not in the list, chances are a developer hasn't gotten to it yet or we haven't had a chance to merge it in yet. File an issue at [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) requesting to support that particular keyboard, if there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) for it. There are also QMK powered keyboards that are in their manufacturer's own GitHub accounts. Double check for that as well.  <!-- FIXME(skullydazed): This feels too wordy and I'm not sure we want to encourage these kinds of issues. Also, should we prompt them to bug the manufacutrer? -->
+If your keyboard has been advertised to be powered by QMK but is not in the list, chances are a developer hasn't gotten to it yet or we haven't had a chance to merge it in yet. File an issue at [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) requesting to support that particular keyboard, if there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) for it. There are also QMK powered keyboards that are in their manufacturer's own github accounts. Double check for that as well.  <!-- FIXME(skullydazed): This feels too wordy and I'm not sure we want to encourage these kinds of issues. Also, should we prompt them to bug the manufacutrer? -->
 
 ## Step 2: Select Your Keyboard Layout
 

docs/custom_quantum_functions.md

@@ -57,7 +57,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
     case KC_ENTER:
       // Play a tone when enter is pressed
       if (record->event.pressed) {
-        PLAY_SONG(tone_qwerty);
+        PLAY_NOTE_ARRAY(tone_qwerty);
       }
       return true; // Let QMK send the enter press/release events
     default:
@@ -438,7 +438,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
     case KC_ENTER:
         // Play a tone when enter is pressed
         if (record->event.pressed) {
-            PLAY_SONG(tone_qwerty);
+            PLAY_NOTE_ARRAY(tone_qwerty);
         }
         return true; // Let QMK send the enter press/release events
     case RGB_LYR:  // This allows me to use underglow as layer indication, or as normal
@@ -486,3 +486,56 @@ And you're done.  The RGB layer indication will only work if you want it to. And
 * Keymap: `void eeconfig_init_user(void)`, `uint32_t eeconfig_read_user(void)` and `void eeconfig_update_user(uint32_t val)`
 
 The `val` is the value of the data that you want to write to EEPROM.  And the `eeconfig_read_*` function return a 32 bit (DWORD) value from the EEPROM. 
+
+# Custom Tapping Term
+
+By default, the tapping term and related options (such as `IGNORE_MOD_TAP_INTERRUPT`) are defined globally, and are not configurable by key.  For most users, this is perfectly fine.  But in some cases, dual function keys would be greatly improved by different timeout behaviors than `LT` keys, or because some keys may be easier to hold than others.  Instead of using custom key codes for each, this allows for per key configurable timeout behaviors.
+
+There are two configurable options to control per-key timeout behaviors:
+
+- `TAPPING_TERM_PER_KEY`
+- `IGNORE_MOD_TAP_INTERRUPT_PER_KEY`
+
+You need to add `#define` lines to your `config.h` for each feature you want.
+
+```
+#define TAPPING_TERM_PER_KEY
+#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY
+```
+
+
+## Example `get_tapping_term` Implementation
+
+To change the `TAPPING_TERM` based on the keycode, you'd want to add something like the following to your `keymap.c` file:
+
+```c
+uint16_t get_tapping_term(uint16_t keycode) {
+  switch (keycode) {
+    case SFT_T(KC_SPC):
+      return TAPPING_TERM + 1250;
+    case LT(1, KC_GRV):
+      return 130;
+    default:
+      return TAPPING_TERM;
+  }
+}
+```
+
+## Example `get_ignore_mod_tap_interrupt` Implementation
+
+To change the `IGNORE_MOD_TAP_INTERRUPT` value based on the keycode, you'd want to add something like the following to your `keymap.c` file:
+
+```c
+bool get_ignore_mod_tap_interrupt(uint16_t keycode) {
+  switch (keycode) {
+    case SFT_T(KC_SPC):
+      return true;
+    default:
+      return false;
+  }
+}
+```
+
+## `get_tapping_term` / `get_ignore_mod_tap_interrupt` Function Documentation
+
+Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum or keyboard level function. Only user level functions are useful here, so no need to mark them as such.

docs/de/README.md

@@ -13,7 +13,7 @@ QMK (*Quantum Mechanical Keyboard*) ist eine Open-Source-Community, welche die Q
 
 ## Bezugsquelle für QMK
 
-Wenn Du vorhast, deine Tastatur, Tastaturbelegung oder Features zu QMK beizusteuern, geht das am einfachsten, indem Du das [Repository auf GitHub](https://github.com/qmk/qmk_firmware#fork-destination-box) forkst, die Änderungen in deinem lokalen Repo vornimmst und anschließend einen [Pull Request](https://github.com/qmk/qmk_firmware/pulls) einreichst.
+Wenn Du vorhast, deine Tastatur, Tastaturbelegung oder Features zu QMK beizusteuern, geht das am einfachsten, indem Du das [Repository auf Github](https://github.com/qmk/qmk_firmware#fork-destination-box) forkst, die Änderungen in deinem lokalen Repo vornimmst und anschließend einen [Pull Request](https://github.com/qmk/qmk_firmware/pulls) einreichst.
 
 Ansonsten kannst Du es als [zip](https://github.com/qmk/qmk_firmware/zipball/master) oder [tar](https://github.com/qmk/qmk_firmware/tarball/master) herunterladen, oder es direkt via git klonen (`git clone git@github.com:qmk/qmk_firmware.git` bzw. `git clone https://github.com/qmk/qmk_firmware.git`).
 

docs/de/_summary.md

@@ -11,7 +11,7 @@
   * [QMK CLI](de/cli.md)
   * [QMK CLI Konfiguration](de/cli_configuration.md)
   * [Zu QMK beitragen](de/contributing.md)
-  * [Anleitung für GitHub](de/getting_started_github.md)
+  * [Anleitung für Github](de/getting_started_github.md)
   * [Nach Hilfe fragen](de/getting_started_getting_help.md)
 
 * [Breaking Changes](de/breaking_changes.md)

docs/de/newbs_learn_more_resources.md

@@ -6,7 +6,7 @@ Git Ressourcen:
 
 * [Gutes allgemeines Tutorial](https://www.codecademy.com/learn/learn-git) (auf Englisch)
 * [Git spielerisch anhand von Beispielen lernen](https://learngitbranching.js.org/) (auf Englisch)
-* [Mehr über den allgemeinen Umgang mit GitHub](getting_started_github.md)
+* [Mehr über den allgemeinen Umgang mit Github](getting_started_github.md)
 * [Mehr über Git im Bezug zu QMK](contributing.md)
 
 Mehr über die Arbeit mit der Befehlszeile:

docs/eeprom_driver.md

@@ -1,4 +1,4 @@
-# EEPROM Driver Configuration :id=eeprom-driver-configuration
+# EEPROM Driver Configuration
 
 The EEPROM driver can be swapped out depending on the needs of the keyboard, or whether extra hardware is present.
 
@@ -6,20 +6,15 @@ Driver                             | Description
 -----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 `EEPROM_DRIVER = vendor` (default) | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. STM32L0xx and STM32L1xx will use the onboard dedicated true EEPROM. Other chips will generally act as "transient" below.
 `EEPROM_DRIVER = i2c`              | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below.
-`EEPROM_DRIVER = spi`              | Supports writing to SPI-based 25xx EEPROM chips. See the driver section below.
 `EEPROM_DRIVER = transient`        | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost.
 
-## Vendor Driver Configuration :id=vendor-eeprom-driver-configuration
-
-#### STM32 L0/L1 Configuration :id=stm32l0l1-eeprom-driver-configuration
+## Vendor Driver Configuration
 
 !> Resetting EEPROM using an STM32L0/L1 device takes up to 1 second for every 1kB of internal EEPROM used.
 
-`config.h` override                 | Description                                                                                                              | Default Value
-------------------------------------|--------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------
-`#define STM32_ONBOARD_EEPROM_SIZE` | The size of the EEPROM to use, in bytes. Erase times can be high, so it's configurable here, if not using the default value. | Minimum required to cover base _eeconfig_ data, or `1024` if VIA is enabled.
+No configurable options are available.
 
-## I2C Driver Configuration :id=i2c-eeprom-driver-configuration
+## I2C Driver Configuration
 
 Currently QMK supports 24xx-series chips over I2C. As such, requires a working i2c_master driver configuration. You can override the driver configuration via your config.h:
 
@@ -46,21 +41,7 @@ MB85RC256V FRAM  | `#define EEPROM_I2C_MB85RC256V` | <https://www.adafruit.com/p
 
 ?> If you find that the EEPROM is not cooperating, ensure you've correctly shifted up your EEPROM address by 1. For example, the datasheet might state the address as `0b01010000` -- the correct value of `EXTERNAL_EEPROM_I2C_BASE_ADDRESS` needs to be `0b10100000`.
 
-## SPI Driver Configuration :id=spi-eeprom-driver-configuration
-
-Currently QMK supports 25xx-series chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
-
-`config.h` override                            | Description                                                                          | Default Value
------------------------------------------------|--------------------------------------------------------------------------------------|--------------
-`#define EXTERNAL_EEPROM_SPI_SLAVE_SELECT_PIN` | SPI Slave select pin in order to inform that the EEPROM is currently being addressed | _none_
-`#define EXTERNAL_EEPROM_SPI_CLOCK_DIVISOR`    | Clock divisor used to divide the peripheral clock to derive the SPI frequency        | `64`
-`#define EXTERNAL_EEPROM_BYTE_COUNT`           | Total size of the EEPROM in bytes                                                    | 8192
-`#define EXTERNAL_EEPROM_PAGE_SIZE`            | Page size of the EEPROM in bytes, as specified in the datasheet                      | 32
-`#define EXTERNAL_EEPROM_ADDRESS_SIZE`         | The number of bytes to transmit for the memory location within the EEPROM            | 2
-
-!> There's no way to determine if there is an SPI EEPROM actually responding. Generally, this will result in reads of nothing but zero.
-
-## Transient Driver configuration :id=transient-eeprom-driver-configuration
+## Transient Driver configuration
 
 The only configurable item for the transient EEPROM driver is its size:
 

docs/es/README.md

@@ -13,7 +13,7 @@ QMK (*Quantum Mechanical Keyboard*) es una comunidad open source que mantiene el
 
 ## Cómo conseguirlo
 
-Si estás pensando en contribuir con un keymap, teclado, or característica a QMK, la manera más sencilla es hacer un [fork del repositorio en GitHub](https://github.com/qmk/qmk_firmware#fork-destination-box), y clonar tu repositorio localmente para hacer los cambios, subirlos, y abir un [Pull Request](https://github.com/qmk/qmk_firmware/pulls) desde tu fork.
+Si estás pensando en contribuir con un keymap, teclado, or característica a QMK, la manera más sencilla es hacer un [fork del repositorio en Github](https://github.com/qmk/qmk_firmware#fork-destination-box), y clonar tu repositorio localmente para hacer los cambios, subirlos, y abir un [Pull Request](https://github.com/qmk/qmk_firmware/pulls) desde tu fork.
 
 De cualquier manera, también puedes descargarlo directamente en formatos ([zip](https://github.com/qmk/qmk_firmware/zipball/master), [tar](https://github.com/qmk/qmk_firmware/tarball/master)), o clonarlo via git (`git@github.com:qmk/qmk_firmware.git`), o https (`https://github.com/qmk/qmk_firmware.git`).
 

docs/es/_summary.md

@@ -11,7 +11,7 @@
   * [QMK CLI](es/cli.md)
   * [Configuración de QMK CLI](es/cli_configuration.md)
   * [Contribuyendo a QMK](es/contributing.md)
-  * [Cómo usar GitHub](es/getting_started_github.md)
+  * [Cómo usar Github](es/getting_started_github.md)
   * [Obtener ayuda](es/getting_started_getting_help.md)
 
 * [Cambios incompatibles](es/breaking_changes.md)

docs/es/newbs_best_practices.md

@@ -6,7 +6,7 @@ Este documento procura instruir a los novatos en las mejores prácticas para ten
 
 En este documento suponemos un par de cosas:
 
-1. Tienes una cuenta de GitHub, y has hecho un [fork del repo qmk_firmware](getting_started_github.md) en tu cuenta.
+1. Tienes una cuenta de Github, y has hecho un [fork del repo qmk_firmware](getting_started_github.md) en tu cuenta.
 2. Has [configurado tu entorno de desarrollo](newbs_getting_started.md?id=environment-setup).
 
 

docs/es/newbs_building_firmware_configurator.md

@@ -21,7 +21,7 @@ Lo diré otra vez porque es importante
 
 !> **ASEGÚRATE DE QUE SELECCIONAS LA VERSIÓN CORRECTA!**
 
-Si se ha anunciado que tu teclado funciona con QMK pero no está en la lista, es probable que un desarrollador no se haya encargado de él aún o que todavía no hemos tenido la oportunidad de incluirlo. Abre un issue en [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) solicitando soportar ese teclado un particular, si no hay un [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) activo para ello. Hay también teclados que funcionan con QMK que están en las cuentas de GitHub de sus manufacturantes. Acuérdate de comprobar esto también.
+Si se ha anunciado que tu teclado funciona con QMK pero no está en la lista, es probable que un desarrollador no se haya encargado de él aún o que todavía no hemos tenido la oportunidad de incluirlo. Abre un issue en [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) solicitando soportar ese teclado un particular, si no hay un [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) activo para ello. Hay también teclados que funcionan con QMK que están en las cuentas de github de sus manufacturantes. Acuérdate de comprobar esto también. 
 
 ## Eligiendo el layout de tu teclado
 

docs/es/newbs_learn_more_resources.md

@@ -6,7 +6,7 @@ Recursos de Git:
 
 * [Excelente tutorial general](https://www.codecademy.com/learn/learn-git)
 * [Juego de Git para aprender usando ejemplos](https://learngitbranching.js.org/)
-* [Recursos de Git para aprender más sobre GitHub](getting_started_github.md)
+* [Recursos de Git para aprender más sobre Github](getting_started_github.md)
 * [Recursos de Git dirigidos específicamente a QMK](contributing.md)
 
 

docs/faq_build.md

@@ -28,30 +28,33 @@ sudo udevadm trigger
 **/etc/udev/rules.d/50-atmel-dfu.rules:**
 ```
 # Atmel ATMega32U4
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", TAG+="uaccess", RUN{builtin}+="uaccess"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", MODE:="0666"
 # Atmel USBKEY AT90USB1287
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", TAG+="uaccess", RUN{builtin}+="uaccess"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", MODE:="0666"
 # Atmel ATMega32U2
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", TAG+="uaccess", RUN{builtin}+="uaccess"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", MODE:="0666"
 ```
 
+**/etc/udev/rules.d/52-tmk-keyboard.rules:**
+```
+# tmk keyboard products     https://github.com/tmk/tmk_keyboard
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666"
+```
 **/etc/udev/rules.d/54-input-club-keyboard.rules:**
 
 ```
 # Input Club keyboard bootloader
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", ATTRS{idProduct}=="b007", TAG+="uaccess", RUN{builtin}+="uaccess"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", MODE:="0666"
 ```
 
 **/etc/udev/rules.d/55-caterina.rules:**
 ```
 # ModemManager should ignore the following devices
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9205", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9203", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+ATTRS{idVendor}=="2a03", ENV{ID_MM_DEVICE_IGNORE}="1"
+ATTRS{idVendor}=="2341", ENV{ID_MM_DEVICE_IGNORE}="1"
 ```
 
-**Note:** With older (before 1.12) ModemManager, filtering only works when not in strict mode, the following commands can update that settings:
+**Note:** ModemManager filtering only works when not in strict mode, the following commands can update that settings:
 ```console
 sudo sed -i 's/--filter-policy=strict/--filter-policy=default/' /lib/systemd/system/ModemManager.service
 sudo systemctl daemon-reload
@@ -61,15 +64,15 @@ sudo systemctl restart ModemManager
 **/etc/udev/rules.d/56-dfu-util.rules:**
 ```
 # stm32duino
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", TAG+="uaccess", RUN{builtin}+="uaccess"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", MODE:="0666"
 # Generic stm32
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess", RUN{builtin}+="uaccess"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE:="0666"
 ```
 
 **/etc/udev/rules.d/57-bootloadhid.rules:**
 ```
 # bootloadHID
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", TAG+="uaccess", RUN{builtin}+="uaccess"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", MODE:="0666"
 ```
 
 ### Serial device is not detected in bootloader mode on Linux
@@ -110,16 +113,26 @@ OPT_DEFS += -DBOOTLOADER_SIZE=2048
 ```
 
 ## `avr-gcc: internal compiler error: Abort trap: 6 (program cc1)` on MacOS
-
 This is an issue with updating on brew, causing symlinks that avr-gcc depend on getting mangled.
 
 The solution is to remove and reinstall all affected modules.
 
 ```
-brew rm avr-gcc avr-gcc@8 dfu-programmer dfu-util gcc-arm-none-eabi arm-gcc-bin@8 avrdude qmk
-brew install qmk/qmk/qmk
+brew rm avr-gcc
+brew rm avr-gcc@8
+brew rm dfu-programmer
+brew rm dfu-util
+brew rm gcc-arm-none-eabi
+brew rm arm-gcc-bin@8
+brew rm avrdude
+brew install avr-gcc@8
+brew install dfu-programmer
+brew install dfu-util
+brew install arm-gcc-bin@8
+brew install avrdude
 brew link --force avr-gcc@8
 brew link --force arm-gcc-bin@8
+
 ```
 
 ### `avr-gcc` and LUFA

docs/feature_backlight.md

@@ -89,7 +89,7 @@ BACKLIGHT_DRIVER = pwm
 
 Hardware PWM is supported according to the following table:
 
-|Backlight Pin|AT90USB64/128|ATmega16/32U4|ATmega16/32U2|ATmega32A|ATmega328/P|
+|Backlight Pin|AT90USB64/128|ATmega16/32U4|ATmega16/32U2|ATmega32A|ATmega328P|
 |-------------|-------------|-------------|-------------|---------|----------|
 |`B1`         |             |             |             |         |Timer 1   |
 |`B2`         |             |             |             |         |Timer 1   |

docs/feature_encoders.md

@@ -26,7 +26,7 @@ If your encoder's clockwise directions are incorrect, you can swap the A & B pad
 #define ENCODER_DIRECTION_FLIP
 ```
 
-Additionally, the resolution, which defines how many pulses the encoder registers between each detent, can be defined with:
+Additionally, the resolution can be specified in the same file (the default & suggested is 4):
 
 ```c
 #define ENCODER_RESOLUTION 4
@@ -61,7 +61,7 @@ void encoder_update_user(uint8_t index, bool clockwise) {
         } else {
             tap_code(KC_PGUP);
         }
-    } else if (index == 1) { /* Second encoder */
+        } else if (index == 1) { /* Second encoder */  
         if (clockwise) {
             tap_code(KC_DOWN);
         } else {