wip

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,55 +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 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;
+#	# 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

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)
@@ -77,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)
@@ -128,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)
 

docs/breaking_changes.md

@@ -102,7 +102,7 @@ This happens immediately after the previous `future` branch is merged.
     * [ ] Roll up the ChangeLog into one file.
     * [ ] `git commit -m 'Merge point for <DATE> Breaking Change'`
     * [ ] `git push origin future`
-* GitHub Actions
+* Github Actions
     * [ ] Create a PR for `future`
     * [ ] Make sure travis comes back clean
     * [ ] Merge `future` PR

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/config_options.md

@@ -191,12 +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).
+  * 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/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

@@ -113,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_encoders.md

@@ -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 {

docs/feature_hd44780.md

@@ -1,6 +1,6 @@
 # HD44780 LCD Displays
 
-This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
+This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
 
 You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes.
 
@@ -50,8 +50,8 @@ LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing
 ````
 This is best done in your keyboards `matrix_init_kb` or your keymaps `matrix_init_user`.  
 It is advised to clear the display before use.  
-To do so call `lcd_clrscr()`.
+To do so call `lcd_clrsrc()`.
 
 To now print something to your Display you first call `lcd_gotoxy(column, line)`. To go to the start of the first line you would call `lcd_gotoxy(0, 0)` and then print a string with `lcd_puts("example string")`.
 
-There are more methods available to control the display. [For in depth documentation please visit the linked page.](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
+There are more methods available to control the display. [For in depth documentation please visit the linked page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)

docs/feature_pointing_device.md

@@ -27,17 +27,20 @@ In the following example, a custom key is used to click the mouse and scroll 127
 
 ```c
 case MS_SPECIAL:
-    report_mouse_t currentReport = pointing_device_get_report();
-    if (record->event.pressed) {
+	report_mouse_t currentReport = pointing_device_get_report();
+    if (record->event.pressed)
+    {
         currentReport.v = 127;
-        currentReport.h = 127;
-        currentReport.buttons |= MOUSE_BTN1;  // this is defined in report.h
-    } else {
+		currentReport.h = 127;
+		currentReport.buttons |= MOUSE_BTN1; //this is defined in report.h
+    }
+    else
+    {
         currentReport.v = -127;
         currentReport.h = -127;
         currentReport.buttons &= ~MOUSE_BTN1;
     }
-    pointing_device_set_report(currentReport);
+	pointing_device_set_report(currentReport);
     break;
 ```
 

docs/feature_rawhid.md

@@ -1,69 +0,0 @@
-# Raw HID
-
-Raw HID allows for bidirectional communication between QMK and the host computer over an HID interface. This has many potential use cases, such as switching keymaps on the fly or changing RGB LED colors and modes.
-
-There are two main components to getting raw HID working with your keyboard.
-
-## Keyboard firmware
-
-The implementation is fairly straightforward for the firmware.
-In your `rules.mk` add:
-
-```make
-RAW_ENABLE = yes
-```
-
-In your `keymap.c` include `"raw_hid.h"` and implement the following:
-
-```C
-void raw_hid_receive(uint8_t *data, uint8_t length) {
-    // Your code goes here. data is the packet received from host.
-}
-```
-
-The `"raw_hid.h"` header also declares `void raw_hid_send(uint8_t *data, uint8_t length);` which allows sending packets from keyboard to host. As an example, it can also be used for debugging when building your host application by returning all data back to the host.
-
-```C
-void raw_hid_receive(uint8_t *data, uint8_t length) {
-    raw_hid_send(data, length);
-}
-```
-
-`raw_hid_receive` can receive variable size packets from host with maximum length `RAW_EPSIZE`. `raw_hid_send` on the other hand can send packets to host of exactly `RAW_EPSIZE` length, therefore it should be used with data of length `RAW_EPSIZE`.
-
-Make sure to flash raw enabled firmware before proceeding with working on the host side.
-
-## Host (Windows/macOS/Linux)
-
-This is the more complicated part as it will require some digging.
-
-To connect your host computer to your keyboard with raw HID you need four pieces of information about your keyboard:
-
-1. Vendor ID
-2. Product ID
-3. Usage Page
-4. Usage
-
-The first two can easily be found in your keyboard's `config.h` in the keyboard's main directory under `VENDOR_ID` and `PRODUCT_ID`.
-
-The final two can be overridden in your keyboard's `config.h` in the keyboard's main directory by redefining the values: `#define RAW_USAGE_PAGE 0xFF60` and `#define RAW_USAGE_ID 0x61`.
-
-By default, **Usage Page** is `0xFF60` and **Usage** is `0x61`.
-
-### Building your host
-
-You can build your host using any language that has an available HID implementation library if you don't wish to make your own. The ones we know of for popular languages are:
-
-* Node: [node-hid](https://github.com/node-hid/node-hid).
-* C: [hidapi](https://github.com/libusb/hidapi).
-* Java: [purejavahidapi](https://github.com/nyholku/purejavahidapi) and [hid4java](https://github.com/gary-rowe/hid4java).
-* Python: [pyhidapi](https://pypi.org/project/hid/).
-
-This is not an exhaustive cross-platform list but should get you started. There are no special requirements for using raw HID so any HID library should work.
-
-Now that you have all four pieces of information required to open HID interface to your keyboard. All you need to do is use your library's available functions to open the device with its ID parameters.
-
-Note that Vendor ID and Product ID are not actually required to open the device. They are used only to filter to a specific device out of the many HID devices you have plugged in. Many libraries will give you the option to open the device using Product Name or Manufacturer Name instead, `node-hid` being a prime example. This will create issues for devices with builtin USB Hub or any extra HID interfaces where you will have multiple interfaces with the same name or from the same manufacturer. The Vendor ID together with Product ID create a unique designation to a single interface and will not exhibit this problem. Therefore, even if your library doesn't require you to, it is best to use them to avoid issues.
-Unlike Vendor ID and Product ID though, Usage Page and Usage are necessary for successful communication.
-
-It should go without saying that regardless of the library you're using, you should always make sure to close the interface when finished. Depending on the operating system and your particular environment there may be issues connecting to it again afterwards with another client or another instance of the same client if it's not explicitly closed.

docs/feature_rgb_matrix.md

@@ -437,16 +437,12 @@ Where `28` is an unused index from `eeconfig.h`.
 |`rgb_matrix_sethsv_noeeprom(h, s, v)`       |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
 
 ### Query Current Status :id=query-current-status
-|Function                         |Description                |
-|---------------------------------|---------------------------|
-|`rgb_matrix_is_enabled()`        |Gets current on/off status |
-|`rgb_matrix_get_mode()`          |Gets current mode          |
-|`rgb_matrix_get_hue()`           |Gets current hue           |
-|`rgb_matrix_get_sat()`           |Gets current sat           |
-|`rgb_matrix_get_val()`           |Gets current val           |
-|`rgb_matrix_get_hsv()`           |Gets hue, sat, and val and returns a [`HSV` structure](https://github.com/qmk/qmk_firmware/blob/7ba6456c0b2e041bb9f97dbed265c5b8b4b12192/quantum/color.h#L56-L61)|
-|`rgb_matrix_get_speed()`         |Gets current speed         |
-|`rgb_matrix_get_suspend_state()` |Gets current suspend state |
+|Function               |Description      |
+|-----------------------|-----------------|
+|`rgb_matrix_get_mode()`  |Get current mode |
+|`rgb_matrix_get_hue()`   |Get current hue  |
+|`rgb_matrix_get_sat()`   |Get current sat  |
+|`rgb_matrix_get_val()`   |Get current val  |
 
 ## Callbacks :id=callbacks
 

docs/feature_rgblight.md

@@ -94,7 +94,6 @@ if `RGBLIGHT_EFFECT_xxxx` or `RGBLIGHT_ANIMATIONS` is defined, you also have a n
 |`RGBLIGHT_MODE_STATIC_GRADIENT`| 0,1,..,9        |Static gradient                        |
 |`RGBLIGHT_MODE_RGB_TEST`     | *None*            |RGB Test                               |
 |`RGBLIGHT_MODE_ALTERNATING`  | *None*            |Alternating                            |
-|`RGBLIGHT_MODE_TWINKLE`      | 0,1,2,3,4,5       |Twinkle                                |
 
 Check out [this video](https://youtube.com/watch?v=VKrpPAHlisY) for a demonstration.
 
@@ -104,8 +103,8 @@ Note: For versions older than 0.6.117, The mode numbers were written directly. I
 
 Use these defines to add or remove animations from the firmware. When you are running low on flash space, it can be helpful to disable animations you are not using.
 
-|Define                              |Default      |Description                                                              |
-|------------------------------------|-------------|-------------------------------------------------------------------------|
+|Define                              |Default      |Description                                                                          |
+|------------------------------------|-------------|-------------------------------------------------------------------------------------|
 |`RGBLIGHT_ANIMATIONS`               |*Not defined*|Enable all additional animation modes.                                   |
 |`RGBLIGHT_EFFECT_ALTERNATING`       |*Not defined*|Enable alternating animation mode.                                       |
 |`RGBLIGHT_EFFECT_BREATHING`         |*Not defined*|Enable breathing animation mode.                                         |
@@ -116,7 +115,6 @@ Use these defines to add or remove animations from the firmware. When you are ru
 |`RGBLIGHT_EFFECT_RGB_TEST`          |*Not defined*|Enable RGB test animation mode.                                          |
 |`RGBLIGHT_EFFECT_SNAKE`             |*Not defined*|Enable snake animation mode.                                             |
 |`RGBLIGHT_EFFECT_STATIC_GRADIENT`   |*Not defined*|Enable static gradient mode.                                             |
-|`RGBLIGHT_EFFECT_TWINKLE`           |*Not defined*|Enable twinkle animation mode.                                           |
 
 ### Effect and Animation Settings
 
@@ -133,8 +131,6 @@ The following options are used to tweak the various animations:
 |`RGBLIGHT_EFFECT_KNIGHT_OFFSET`     |`0`          |The number of LEDs to start the "Knight" animation from the start of the strip by    |
 |`RGBLIGHT_RAINBOW_SWIRL_RANGE`      |`255`        |Range adjustment for the rainbow swirl effect to get different swirls                |
 |`RGBLIGHT_EFFECT_SNAKE_LENGTH`      |`4`          |The number of LEDs to light up for the "Snake" animation                             |
-|`RGBLIGHT_EFFECT_TWINKLE_LIFE`      |`75`         |Adjusts how quickly each LED brightens and dims when twinkling (in animation steps)  |
-|`RGBLIGHT_EFFECT_TWINKLE_PROBABILITY`|`1/127`     |Adjusts how likely each LED is to twinkle (on each animation step)                   |
 
 ### Example Usage to Reduce Memory Footprint
   1. Remove `RGBLIGHT_ANIMATIONS` from `config.h`.
@@ -172,9 +168,6 @@ const uint8_t RGBLED_SNAKE_INTERVALS[] PROGMEM = {100, 50, 20};
 // How long (in milliseconds) to wait between animation steps for each of the "Knight" animations
 const uint8_t RGBLED_KNIGHT_INTERVALS[] PROGMEM = {127, 63, 31};
 
-// How long (in milliseconds) to wait between animation steps for each of the "Twinkle" animations
-const uint8_t RGBLED_TWINKLE_INTERVALS[] PROGMEM = {50, 25, 10};
-
 // These control which hues are selected for each of the "Static gradient" modes
 const uint8_t RGBLED_GRADIENT_RANGES[] PROGMEM = {255, 170, 127, 85, 64};
 ```
@@ -184,10 +177,6 @@ const uint8_t RGBLED_GRADIENT_RANGES[] PROGMEM = {255, 170, 127, 85, 64};
 By including `#define RGBLIGHT_LAYERS` in your `config.h` file you can enable lighting layers. These make
 it easy to use your underglow LEDs as status indicators to show which keyboard layer is currently active, or the state of caps lock, all without disrupting any animations. [Here's a video](https://youtu.be/uLGE1epbmdY) showing an example of what you can do.
 
-### Defining Lighting Layers :id=defining-lighting-layers
-
-By default, 8 layers are possible. This can be expanded to as many as 32 by overriding the definition of `RGBLIGHT_MAX_LAYERS` in `config.h` (e.g. `#define RGBLIGHT_MAX_LAYERS 32`). Please note, if you use a split keyboard, you will need to flash both sides of the split after changing this. Also, increasing the maximum will increase the firmware size, and will slow sync on split keyboards.
-
 To define a layer, we modify `keymap.c` to list out LED ranges and the colors we want to overlay on them using an array of `rgblight_segment_t` using the `RGBLIGHT_LAYER_SEGMENTS` macro. We can define multiple layers and enable/disable them independently:
 
 ```c
@@ -222,12 +211,8 @@ void keyboard_post_init_user(void) {
     rgblight_layers = my_rgb_layers;
 }
 ```
-Note: For split keyboards with two controllers, both sides need to be flashed when updating the contents of rgblight_layers.
 
-### Enabling and disabling lighting layers :id=enabling-lighting-layers
-
-Everything above just configured the definition of each lighting layer.
-We can now enable and disable the lighting layers whenever the state of the keyboard changes:
+Finally, we enable and disable the lighting layers whenever the state of the keyboard changes:
 
 ```c
 layer_state_t layer_state_set_user(layer_state_t state) {
@@ -243,40 +228,7 @@ bool led_update_user(led_t led_state) {
 }
 ```
 
-### Lighting layer blink :id=lighting-layer-blink
-
-By including `#define RGBLIGHT_LAYER_BLINK` in your `config.h` file you can turn a lighting
-layer on for a specified duration. Once the specified number of milliseconds has elapsed
-the layer will be turned off. This is useful, e.g., if you want to acknowledge some
-action (e.g. toggling some setting):
-
-```c
-const rgblight_segment_t PROGMEM _yes_layer[] = RGBLIGHT_LAYER_SEGMENTS( {9, 6, HSV_GREEN} );
-const rgblight_segment_t PROGMEM _no_layer[] = RGBLIGHT_LAYER_SEGMENTS( {9, 6, HSV_RED} );
-
-const rgblight_segment_t* const PROGMEM _rgb_layers[] =
-    RGBLIGHT_LAYERS_LIST( _yes_layer, _no_layer );
-
-void keyboard_post_init_user(void) {
-    rgblight_layers = _rgb_layers;
-}
-
-// Note we user post_process_record_user because we want the state
-// after the flag has been flipped...
-void post_process_record_user(uint16_t keycode, keyrecord_t *record) {
-    switch (keycode) {
-        case DEBUG:
-            rgblight_blink_layer(debug_enable ? 0 : 1, 500);
-            break;
-
-        case NK_TOGG:
-        case NK_ON:
-        case NK_OFF:
-            rgblight_blink_layer(keymap_config.nkro ? 0 : 1, 500);
-            break;
-    }
-}
-```
+Note: For split keyboards with two controllers, both sides need to be flashed when updating the contents of rgblight_layers.
 
 ## Functions
 
@@ -376,14 +328,12 @@ rgblight_sethsv(HSV_GREEN, 2); // led 2
 |`rgblight_set_layer_state(i, is_on)`        |Enable or disable lighting layer `i` based on value of `bool is_on` |
 
 #### query
-|Function               |Description                |
-|-----------------------|---------------------------|
-|`rgblight_is_enabled()`|Gets current on/off status |
-|`rgblight_get_mode()`  |Gets current mode          |
-|`rgblight_get_hue()`   |Gets current hue           |
-|`rgblight_get_sat()`   |Gets current sat           |
-|`rgblight_get_val()`   |Gets current val           |
-|`rgblight_get_speed()` |Gets current speed         |
+|Function               |Description      |
+|-----------------------|-----------------|
+|`rgblight_get_mode()`  |Get current mode |
+|`rgblight_get_hue()`   |Get current hue  |
+|`rgblight_get_sat()`   |Get current sat  |
+|`rgblight_get_val()`   |Get current val  |
 
 ## Colors
 

docs/feature_split_keyboard.md

@@ -8,20 +8,9 @@ QMK Firmware has a generic implementation that is usable by any board, as well a
 
 For this, we will mostly be talking about the generic implementation used by the Let's Split and other keyboards. 
 
-!> ARM is not yet fully supported for Split Keyboards and has many limitations. Progress is being made, but we have not yet reached 100% feature parity.
+!> ARM is not yet supported for Split Keyboards.  Progress is being made, but we are not quite there, yet. 
 
 
-## Compatibility Overview
-
-| Transport                    | AVR                | ARM                |
-|------------------------------|--------------------|--------------------|
-| ['serial'](serial_driver.md) | :heavy_check_mark: | :white_check_mark: <sup>1</sup> |
-| I2C                          | :heavy_check_mark: |                    |
-
-Notes:
-
-1. Both hardware and software limitations are detailed within the [driver documentation](serial_driver.md).
-
 ## Hardware Configuration
 
 This assumes that you're using two Pro Micro-compatible controllers, and are using TRRS jacks to connect to two halves. 

docs/feature_swap_hands.md

@@ -28,4 +28,3 @@ Note that the array indices are reversed same as the matrix and the values are o
 |`SH_MOFF`  |Momentarily turns off swap.                                              |
 |`SH_TG`    |Toggles swap on and off with every key press.                            |
 |`SH_TT`    |Toggles with a tap; momentary when held.                                 |
-|`SH_OS`    |One shot swap hands: toggles while pressed or until next key press.      |

docs/feature_userspace.md

@@ -1,6 +1,6 @@
 # Userspace: Sharing Code Between Keymaps
 
-If you use more than one keyboard with a similar keymap, you might see the benefit in being able to share code between them. Create your own folder in `users/` named the same as your keymap (ideally your GitHub username, `<name>`) with the following structure:
+If you use more than one keyboard with a similar keymap, you might see the benefit in being able to share code between them. Create your own folder in `users/` named the same as your keymap (ideally your github username, `<name>`) with the following structure:
 
 * `/users/<name>/` (added to the path automatically)
   * `readme.md` (optional, recommended)
@@ -73,7 +73,7 @@ The reason for this, is that `<name>.h` won't be added in time to add settings (
 
 ## Readme (`readme.md`)
 
-Please include authorship (your name, GitHub username, email), and optionally [a license that's GPL compatible](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).
+Please include authorship (your name, github username, email), and optionally [a license that's GPL compatible](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses).
 
 You can use this as a template: 
 ```
@@ -93,7 +93,7 @@ You should have received a copy of the GNU General Public License
 along with this program.  If not, see <http://www.gnu.org/licenses/>.
 ```
 
-You'd want to replace the year, name, email and GitHub username with your info. 
+You'd want to replace the year, name, email and github username with your info. 
 
 Additionally, this is a good place to document your code, if you wish to share it with others.