docs/ChangeLog/20211127.md
QMK had it's 2000th keyboard submitted during this breaking changes cycle.... and it only just made the cut-off!
% 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!
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:
rules.mk line | Supported device |
|---|---|
POINTING_DEVICE_DRIVER = analog_joystick | Analog joysticks, such as PSP joysticks |
POINTING_DEVICE_DRIVER = adns5050 | ADNS 5050 sensor |
POINTING_DEVICE_DRIVER = adns9800 | ADNS 9800 laser sensor |
POINTING_DEVICE_DRIVER = cirque_pinnacle_i2c | Cirque touchpad, I2C mode |
POINTING_DEVICE_DRIVER = cirque_pinnacle_spi | Cirque Touchpad, SPI mode |
POINTING_DEVICE_DRIVER = pimoroni_trackball | Pimoroni Trackball |
POINTING_DEVICE_DRIVER = pmw3360 | PMW 3360 |
See the new documentation for the Pointing Device feature for more information on specific configuration for each driver.
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:
| Key | Description |
|---|---|
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!
You can now define up to 32 macros in your keymap.json file, as used by QMK Configurator, and qmk compile. You can define these macros in a list under the macros keyword, like this:
{
"keyboard": "handwired/my_macropad",
"keymap": "my_keymap",
"macros": [
[ // first listed is QK_MACRO_0...
{"action":"down", "keycodes": ["LSFT"]},
"hello world1",
{"action": "up","keycodes": ["LSFT"]}
],
[ // ...then QK_MACRO_1...
{"action":"tap", "keycodes": ["LCTL", "LALT", "DEL"]}
],
[ // ...then QK_MACRO_2...
"ding!",
{"action":"beep"}
],
[ // ...and QK_MACRO_3.
{"action":"tap", "keycodes": ["F1"]},
{"action":"delay", "duration": "1000"},
{"action":"tap", "keycodes": ["PGDN"]}
]
],
"layout": "LAYOUT_all",
"layers": [
["QK_MACRO_0", "QK_MACRO_1", "QK_MACRO_2", "QK_MACRO_3"]
]
}
In due course, QMK Configurator will pick up support for defining these in its UI, but for now the json is the only way to define macros.
The following keyboards have had their source moved within QMK:
| Old Keyboard Name | New Keyboard Name |
|---|---|
| aozora/hotswap | aozora |
| gskt00 | kapcave/gskt00 |
| handwired/dtisaac01 | dtisaac/dtisaac01 |
| kprepublic/bm60poker | kprepublic/bm60hsrgb_poker/rev1 |
| kprepublic/bm60rgb | kprepublic/bm60hsrgb/rev1 |
| kprepublic/bm60rgb_iso | kprepublic/bm60hsrgb_iso/rev1 |
| kprepublic/bm65iso | kprepublic/bm65hsrgb_iso |
| kprepublic/bm68rgb | kprepublic/bm68hsrgb |
| paladin64 | kapcave/paladin64 |
| portal_66 | portal_66/soldered |
| signum/3_0/elitec | signum/3_0 |
| tgr/jane | tgr/jane/v2 |
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... ;)
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 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:
void oled_task_user(void) {
// keymap drawing code
}
...but the new keymap code looks like this:
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:
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;
}
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.
This is the historical timeline for the behavior of BOOTMAGIC_ENABLE:
BOOTMAGIC_ENABLE = yes will enable Bootmagic Lite instead of full Bootmagic.BOOTMAGIC_ENABLE must be either yes, lite, or no – setting BOOTMAGIC_ENABLE = full will cause compilation to fail.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.
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.
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.
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.
compile_commands.json) (#14370)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:
tmk_core/common/<plat> (#13918)analogRead() (#14348)MK66F18 -> MK66FX1M0 (#14659)post_rules.mk (#14216)Core:
DYNAMIC_TAPPING_TERM_ENABLE (#11036)tmk_core/common/<plat> (#13918)pragma once (#14248)analogRead() (#14348)MK66F18 -> MK66FX1M0 (#14659)BOOTMAGIC_ENABLE = lite option (#15002)CLI:
develop PRs to be merged into master (#13944)compile_commands.json) (#14370)Submodule updates:
Keyboards:
post_rules.mk (#14216)fn_actions macros (#14662)Keyboard fixes:
PRODUCT define to keyboard_name (#14372)Others:
Bugs: