import { _ as _export_sfc, c as createElementBlock, o as openBlock, a8 as createStaticVNode } from "./chunks/framework.B9AX-CPi.js"; const __pageData = JSON.parse('{"title":"QMK Breaking Changes - 2021 November 27 Changelog","description":"","frontmatter":{},"headers":[],"relativePath":"ChangeLog/20211127.md","filePath":"ChangeLog/20211127.md","lastUpdated":null}'); const _sfc_main = { name: "ChangeLog/20211127.md" }; const _hoisted_1 = /* @__PURE__ */ createStaticVNode('

QMK Breaking Changes - 2021 November 27 Changelog ​

2000 keyboards! ​

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\n2003

From the whole QMK team, a major thankyou to the community for embracing QMK as your preferred keyboard firmware!

Notable Features ​

Expanded Pointing Device support (#14343) ​

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 lineSupported device
POINTING_DEVICE_DRIVER = analog_joystickAnalog joysticks, such as PSP joysticks
POINTING_DEVICE_DRIVER = adns5050ADNS 5050 sensor
POINTING_DEVICE_DRIVER = adns9800ADNS 9800 laser sensor
POINTING_DEVICE_DRIVER = cirque_pinnacle_i2cCirque touchpad, I2C mode
POINTING_DEVICE_DRIVER = cirque_pinnacle_spiCirque Touchpad, SPI mode
POINTING_DEVICE_DRIVER = pimoroni_trackballPimoroni Trackball
POINTING_DEVICE_DRIVER = pmw3360PMW 3360

See the new documentation for the Pointing Device feature for more information on specific configuration for each driver.

Dynamic Tapping Term (#11036) ​

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:

KeyDescription
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) ​

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:

json
{\n    "keyboard": "handwired/my_macropad",\n    "keymap": "my_keymap",\n    "macros": [\n        [ // first listed is QK_MACRO_0...\n            {"action":"down", "keycodes": ["LSFT"]},\n            "hello world1",\n            {"action": "up","keycodes": ["LSFT"]}\n        ],\n        [ // ...then QK_MACRO_1...\n            {"action":"tap", "keycodes": ["LCTL", "LALT", "DEL"]}\n        ],\n        [ // ...then QK_MACRO_2...\n            "ding!",\n            {"action":"beep"}\n        ],\n        [ // ...and QK_MACRO_3.\n            {"action":"tap", "keycodes": ["F1"]},\n            {"action":"delay", "duration": "1000"},\n            {"action":"tap", "keycodes": ["PGDN"]}\n        ]\n    ],\n    "layout": "LAYOUT_all",\n    "layers": [\n        ["QK_MACRO_0", "QK_MACRO_1", "QK_MACRO_2", "QK_MACRO_3"]\n    ]\n}

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.

Changes Requiring User Action ​

Updated Keyboard Codebases ​

The following keyboards have had their source moved within QMK:

Old Keyboard NameNew Keyboard Name
aozora/hotswapaozora
gskt00kapcave/gskt00
handwired/dtisaac01dtisaac/dtisaac01
kprepublic/bm60pokerkprepublic/bm60hsrgb_poker/rev1
kprepublic/bm60rgbkprepublic/bm60hsrgb/rev1
kprepublic/bm60rgb_isokprepublic/bm60hsrgb_iso/rev1
kprepublic/bm65isokprepublic/bm65hsrgb_iso
kprepublic/bm68rgbkprepublic/bm68hsrgb
paladin64kapcave/paladin64
portal_66portal_66/soldered
signum/3_0/elitecsignum/3_0
tgr/janetgr/jane/v2

Squeezing space out of AVR (#15243) ​

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) ​

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 task refactoring (#14864) ​

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) {\n    // keymap drawing code\n}

...but the new keymap code looks like this:

c
bool oled_task_user(void) {\n    // keymap drawing code\n    return false;\n}

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) {\n    // Defer to the keymap if they want to override\n    if(!oled_task_user()) { return false; }\n\n    // default keyboard drawing code\n    return false;\n}

Bootmagic Full Removal (#15002) ​

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:

Remove QWIIC_DRIVERS (#14174) ​

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 ​

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.

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.

Compilation Database ​

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.

Codebase restructure and cleanup ​

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:

Full changelist ​

Core:

CLI:

Submodule updates:

Keyboards:

Keyboard fixes:

Others:

Bugs:

', 83); const _hoisted_84 = [ _hoisted_1 ]; function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) { return openBlock(), createElementBlock("div", null, _hoisted_84); } const _20211127 = /* @__PURE__ */ _export_sfc(_sfc_main, [["render", _sfc_render]]); export { __pageData, _20211127 as default };