aboutsummaryrefslogtreecommitdiff
path: root/docs/ChangeLog/20211127.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/ChangeLog/20211127.md')
-rw-r--r--docs/ChangeLog/20211127.md40
1 files changed, 20 insertions, 20 deletions
diff --git a/docs/ChangeLog/20211127.md b/docs/ChangeLog/20211127.md
index 0780ab6a44..d810be505a 100644
--- a/docs/ChangeLog/20211127.md
+++ b/docs/ChangeLog/20211127.md
@@ -1,6 +1,6 @@
# QMK Breaking Changes - 2021 November 27 Changelog
-## 2000 keyboards! :id=qmk-2000th-keyboard
+## 2000 keyboards! {#qmk-2000th-keyboard}
QMK had it's 2000th keyboard submitted during this breaking changes cycle.... and it only _just_ made the cut-off!
@@ -11,9 +11,9 @@ QMK had it's 2000th keyboard submitted during this breaking changes cycle.... an
From the whole QMK team, a major thankyou to the community for embracing QMK as your preferred keyboard firmware!
-## Notable Features :id=notable-features
+## Notable Features {#notable-features}
-### Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) :id=expanded-pointing-device
+### Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) {#expanded-pointing-device}
Pointing device support has been reworked and reimplemented to allow for easier integration of new peripherals.
@@ -31,9 +31,9 @@ QMK now has core-supplied support for the following pointing device peripherals:
| `POINTING_DEVICE_DRIVER = pimoroni_trackball` | Pimoroni Trackball |
| `POINTING_DEVICE_DRIVER = pmw3360` | PMW 3360 |
-See the new documentation for the [Pointing Device](../feature_pointing_device.md) feature for more information on specific configuration for each driver.
+See the new documentation for the [Pointing Device](../feature_pointing_device) feature for more information on specific configuration for each driver.
-### Dynamic Tapping Term ([#11036](https://github.com/qmk/qmk_firmware/pull/11036)) :id=dynamic-tapping-term
+### Dynamic Tapping Term ([#11036](https://github.com/qmk/qmk_firmware/pull/11036)) {#dynamic-tapping-term}
For people who are starting out with tapping keys, or for people who think tapping keys don't "feel right", it's sometimes quite difficult to determine what duration of tapping term to use to make things seem natural.
@@ -47,9 +47,9 @@ If you're in this stage of discovery, you can now add `DYNAMIC_TAPPING_TERM_ENAB
Coupled with the use of `qmk console` or QMK Toolbox to show console output from your keyboard, you can tweak the tapping term dynamically in order to narrow down what "feels right" to you. Once you're happy, drop in the resulting number into your keymap's `config.h` and you're good to go!
-### Macros in JSON keymaps ([#14374](https://github.com/qmk/qmk_firmware/pull/14374)) :id=macros-in-keymap-json
+### Macros in JSON keymaps ([#14374](https://github.com/qmk/qmk_firmware/pull/14374)) {#macros-in-keymap-json}
-You can now define up to 32 macros in your `keymap.json` file, as used by [QMK Configurator](newbs_building_firmware_configurator.md), and `qmk compile`. You can define these macros in a list under the `macros` keyword, like this:
+You can now define up to 32 macros in your `keymap.json` file, as used by [QMK Configurator](../newbs_building_firmware_configurator), and `qmk compile`. You can define these macros in a list under the `macros` keyword, like this:
```json
{
@@ -83,9 +83,9 @@ You can now define up to 32 macros in your `keymap.json` file, as used by [QMK C
In due course, [QMK Configurator](https://config.qmk.fm/) will pick up support for defining these in its UI, but for now the json is the only way to define macros.
-## Changes Requiring User Action :id=changes-requiring-user-action
+## Changes Requiring User Action {#changes-requiring-user-action}
-### Updated Keyboard Codebases :id=updated-keyboard-codebases
+### Updated Keyboard Codebases {#updated-keyboard-codebases}
The following keyboards have had their source moved within QMK:
@@ -104,21 +104,21 @@ The following keyboards have had their source moved within QMK:
| signum/3_0/elitec | signum/3_0 |
| tgr/jane | tgr/jane/v2 |
-### Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) :id=squeezing-space-from-avr
+### Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) {#squeezing-space-from-avr}
The AVR platform has been problematic for some time, in the sense that it is severely resource-constrained -- this makes life difficult for anyone attempting to add new functionality such as display panels to their keymap code. The illustrious Drashna has contributed some newer documentation on how to attempt to free up some space on AVR-based keyboards that are in short supply.
Of course, there are much fewer constraints with ARM chips... ;)
-### Require explicit enabling of RGB Matrix modes ([#15018](https://github.com/qmk/qmk_firmware/pull/15018)) :id=explicit-rgb-modes
+### Require explicit enabling of RGB Matrix modes ([#15018](https://github.com/qmk/qmk_firmware/pull/15018)) {#explicit-rgb-modes}
Related to the previous section -- RGB Matrix modes have now been made to be opt-in, rather than opt-out. As these animations are now opt-in, you may find that your keyboard no longer has all the RGB modes you're expecting -- you may need to configure and recompile your firmware and enable your animations of choice... with any luck they'll still fit in the space available.
Most keyboards keep their original functionality, but over time the QMK maintainers have found that removal of animations ends up being the quickest way to free up space... and some keyboards have had animations such as reactive effects disabled by default in order to still fit within the flash space available.
-The full list of configurables to turn specific animations back on can be found at on the [RGB Matrix documentation](feature_rgb_matrix.md#rgb-matrix-effects) page.
+The full list of configurables to turn specific animations back on can be found at on the [RGB Matrix documentation](../feature_rgb_matrix#rgb-matrix-effects) page.
-### OLED task refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/14864)) :id=oled-task-refactor
+### OLED task refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/14864)) {#oled-task-refactor}
OLED display code was traditionally difficult to override in keymaps as they did not follow the standard pattern of `bool *_kb()` deferring to `bool *_user()` functions, allowing signalling to the higher level that processing had already been done.
@@ -152,7 +152,7 @@ bool oled_task_kb(void) {
}
```
-### Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) :id=bootmagic-full-removal
+### Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) {#bootmagic-full-removal}
As noted during previous breaking changes cycles, QMK decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
@@ -170,13 +170,13 @@ This is the historical timeline for the behavior of `BOOTMAGIC_ENABLE`:
- (done) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
- (now) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
-### Remove QWIIC_DRIVERS ([#14174](https://github.com/qmk/qmk_firmware/pull/14174)) :id=remove-qwiic
+### Remove QWIIC_DRIVERS ([#14174](https://github.com/qmk/qmk_firmware/pull/14174)) {#remove-qwiic}
Due to minimal QWIIC adoption and other options for similar functionality, the QWIIC drivers were removed from QMK. Existing OLED usages have been migrated across to the normal QMK OLED driver instead.
-## Notable core changes :id=notable-core
+## Notable core changes {#notable-core}
-### New MCU Support :id=new-mcu-support
+### New MCU Support {#new-mcu-support}
QMK firmware picked up support for a handful of new MCU families, potentially making it a bit easier to source components.
@@ -187,7 +187,7 @@ QMK firmware is now no longer limited to AVR and ARM - it also picked up support
* Westberrytech pr ([#14422](https://github.com/qmk/qmk_firmware/pull/14422))
* Initial pass of F405 support ([#14584](https://github.com/qmk/qmk_firmware/pull/14584))
-### EEPROM Changes :id=eeprom-changes
+### EEPROM Changes {#eeprom-changes}
There were a few EEPROM-related changes that landed during this breaking changes cycle, most prominently the long-awaited ability for the Drop boards to gain persistent storage. Any users of the Drop CTRL or Drop ALT should update QMK Toolbox as well -- coupled with a QMK firmware update settings should now be saved.
@@ -197,7 +197,7 @@ There were a few EEPROM-related changes that landed during this breaking changes
* Further tidy up of STM32 eeprom emulation ([#14591](https://github.com/qmk/qmk_firmware/pull/14591))
* Enable eeprom with F401xE ld ([#14752](https://github.com/qmk/qmk_firmware/pull/14752))
-### Compilation Database :id=compile-commands
+### Compilation Database {#compile-commands}
A clang-compatible compilation database generator has been added as an option in order to help development environments such as Visual Studio Code.
@@ -208,7 +208,7 @@ Do note that switching keyboards will require re-generation of this file.
* New CLI subcommand to create clang-compatible compilation database (`compile_commands.json`) ([#14370](https://github.com/qmk/qmk_firmware/pull/14370))
* compiledb: query include paths from gcc directly. ([#14462](https://github.com/qmk/qmk_firmware/pull/14462))
-### Codebase restructure and cleanup :id=codebase-restructure
+### Codebase restructure and cleanup {#codebase-restructure}
QMK continues on its restructuring journey, in order to make it easier to integrate newer features and add support for new hardware. This quarter's batch of changes include: