# QMK Breaking Changes - 2021 November 27 Changelog
## 2000 keyboards! :id=qmk-2000th-keyboard
QMK had it's 2000th keyboard submitted during this breaking changes cycle.... and it only _just_ made the cut-off!
```shell
% qmk list-keyboards | wc -l
2003
```
From the whole QMK team, a major thankyou to the community for embracing QMK as your preferred keyboard firmware!
## Notable Features :id=notable-features
### Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) :id=expanded-pointing-device
Pointing device support has been reworked and reimplemented to allow for easier integration of new peripherals.
Usages of `POINTING_DEVICE_ENABLE = yes` in `rules.mk` files now need to be accompanied by a corresponding `POINTING_DEVICE_DRIVER = ???` line, specifying which driver to use during the build. Existing keyboards have already been migrated across to the new usage pattern, so most likely no change is required by users.
QMK now has core-supplied support for the following pointing device peripherals:
See the new documentation for the [Pointing Device](../feature_pointing_device.md) 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
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.
If you're in this stage of discovery, you can now add `DYNAMIC_TAPPING_TERM_ENABLE = yes` to your `rules.mk`, which enables the use of the following keycodes in your keymap:
| `DT_PRNT` | "Dynamic Tapping Term Print": Types the current tapping term, in milliseconds |
| `DT_UP` | "Dynamic Tapping Term Up": Increases the current tapping term by 5ms |
| `DT_DOWN` | "Dynamic Tapping Term Down": Decreases the current tapping term by 5ms |
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
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:
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
### Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) :id=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
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.
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.
This changes the standard OLED drawing function model to allow for a base implementation to be provided by a keyboard, but also still allow for keymap-level overrides without needing to modify the keyboard's code.
The old keymap code went something like this:
```c
void oled_task_user(void) {
// keymap drawing code
}
```
...but the new keymap code looks like this:
```c
bool oled_task_user(void) {
// keymap drawing code
return false;
}
```
Keyboard designers should now structure their keyboard-level drawing routines like the following, in order to allow for keymap overrides:
```c
bool oled_task_kb(void) {
// Defer to the keymap if they want to override
if(!oled_task_user()) { return false; }
// default keyboard drawing code
return false;
}
```
### Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) :id=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.
This removal is now complete!
This pull request changes the behavior of `BOOTMAGIC_ENABLE` such that specifying `lite` or `full` results in an error, allowing only `yes` or `no`, with `yes` mirroring historical `lite` functionality.
All use of the `lite` keyword within the repository has been migrated to `yes` -- any new submissions using `lite` will now fail to build and should be updated accordingly.
#### Bootmagic Full Deprecation Schedule: Complete!
This is the historical timeline for the behavior of `BOOTMAGIC_ENABLE`:
- (done) From 2021 May 29, setting `BOOTMAGIC_ENABLE = yes` will enable Bootmagic Lite instead of full Bootmagic.
- (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.
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
### New MCU Support :id=new-mcu-support
QMK firmware picked up support for a handful of new MCU families, potentially making it a bit easier to source components.
QMK firmware is now no longer limited to AVR and ARM - it also picked up support for our first RISC-V chip, the GD32VF103.
* Add support for RISC-V builds and GD32VF103 MCU ([#12508](https://github.com/qmk/qmk_firmware/pull/12508))
* Add HT32 support to core ([#14388](https://github.com/qmk/qmk_firmware/pull/14388))
* Initial pass of F405 support ([#14584](https://github.com/qmk/qmk_firmware/pull/14584))
### EEPROM Changes :id=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.
* massdrop alt/ctrl: support saving into nvm ([#6068](https://github.com/qmk/qmk_firmware/pull/6068))
* make the full 4096 bytes of EEPROM work on Teensy 3.6 ([#12947](https://github.com/qmk/qmk_firmware/pull/12947))
* 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
A clang-compatible compilation database generator has been added as an option in order to help development environments such as Visual Studio Code.
Running `qmk generate-compilation-database -kb <yourkb> -km <yourkeymap>` from within the QMK firmware directory will generate a `compile_commands.json` file -- using a compatible IDE will likely see this and correctly start detecting the correct locations for source files as well as type and function information that are relevant to your build.
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
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:
* add 'include keyboard_features.mk' into build_keyboard.mk ([#8422](https://github.com/qmk/qmk_firmware/pull/8422))
* Infer more when building features ([#13890](https://github.com/qmk/qmk_firmware/pull/13890))
* Add support for PaladinPad, Arya pcb and move keyboards by KapCave into their own directory ([#14194](https://github.com/qmk/qmk_firmware/pull/14194))
* Move non-assignment code to post_rules.mk ([#14207](https://github.com/qmk/qmk_firmware/pull/14207))
* Helix use `post_rules.mk` ([#14216](https://github.com/qmk/qmk_firmware/pull/14216))
* handwired/symmetric70_proto use post_rules.mk ([#14235](https://github.com/qmk/qmk_firmware/pull/14235))
