_@getreuer_ in their infinite wisdom decided that autocorrect was a feature needed by QMK. As is customary, _@drashna_ adapted it to core and got it into a state that everyone else can use it. See [Feature: Autocorrect](feature_autocorrect.md) for more ifnormation (grin).
## Changes Requiring User Action :id=changes-requiring-user-action
## Changes Requiring User Action :id=changes-requiring-user-action
QMK's keycodes got a very significant overhaul this breaking changes cycle, with the bulk of the work done by _@zvecr_ and _@fauxpark_ -- renaming, reordering, removing has been their focus in this area. In an attempt to standardise interoperation with host applications, keycode values now have strong versioning so that any connected application has confidence that the keys it thinks exist on the board actually match up with what's compiled in. These strongly-versioned keycode definitions are now published online and will not change, so tools that remap keycodes have a reference to work with. In future versions of QMK, any new or changed keycodes will result in a new version specification. See [API docs](api_docs.md#qmk-constants) for more information on the published versions if you're writing a tool to manage keycodes.
In most cases user keymaps in the repository have already been updated to reflect the new naming scheme. In some cases user keymaps outside the repository may strike a missing keycode with the old name -- it's highly likely that the name had already been deprecated for some time, and should have been updated previously.
See below for the full list of changesets.
!> Keycode aliases have been put in place in most cases to cater for "old names" being mapped to "new names" -- the documentation already reflects all the new naming of keys.
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) :id=usb-ids-Refactoring
QMK has decided to deprecate the specification of USB IDs inside `config.h` in favour of `info.json`, leaving data-driven as the only method to specify USB information. As per the deprecation schedule put forward last breaking changes cycle, USB information must be specified in `info.json` instead.
Previously in `config.h`:
```c
#define VENDOR_ID 0x1234
#define PRODUCT_ID 0x5678
#define DEVICE_VER 0x0001
#define MANUFACTURER Me
#define PRODUCT MyKeyboard
```
Replaced by `info.json`:
```json
{
"keyboard_name": "MyKeyboard",
"manufacturer": "Me",
"usb": {
"vid": "0x1234",
"pid": "0x5678",
"device_version": "0.0.1"
}
}
```
### LED Indicator callback refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/18450)) :id=led-callback-refactor
_RGB Matrix_ and _LED Matrix_ Indicator 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 callback 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 RGB Matrix keymap code went something like this:
```c
void rgb_matrix_indicators_user(void) {
// keymap LED code
}
```
...but the new RGB Matrix keymap code looks like this:
```c
bool rgb_matrix_indicators_user(void) {
// keymap LED code
return false;
}
```
Keyboard designers should now structure their keyboard-level routines like the following, in order to allow for keymap overrides:
```c
bool rgb_matrix_indicators_kb(void) {
// Defer to the keymap if they want to override
if (!rgb_matrix_indicators_user()) { return false; }
// keyboard LED code
return true;
}
```
The equivalent transformations should be done for LED Matrix boards.
Unicode modes were renamed in order to prevent collision with equivalent keycodes. The available values for `UNICODE_SELECTED_MODES` changed -- see [Feature: Unicode](feature_unicode.md#setting-the-input-mode) for the new list of values and how to configure them.
## Notable core changes :id=notable-core
## Notable core changes :id=notable-core
This breaking changes cycle, a lot of the core changes are related to cleanup and refactoring -- commonly called "tech debt".
We aren't going to list each and every change -- they're far too numerous -- instead, we'll just list the related PRs in order to convey just how wide-reaching these changes were:
There was additional work in the space of board converters -- historically QMK allowed for "converting" a Pro Micro build to a QMK Proton-C build. The last few versions of QMK have added support for replacement boards much like the Proton-C, and this quarter was no exception:
* Add Bonsai C4 as a platform board file ([#18901](https://github.com/qmk/qmk_firmware/pull/18901))
* Add converter support to keymap.json ([#18776](https://github.com/qmk/qmk_firmware/pull/18776))
* Add Elite-C to converters ([#18309](https://github.com/qmk/qmk_firmware/pull/18309))
* Allow QK_MAKE to work with converters ([#18637](https://github.com/qmk/qmk_firmware/pull/18637))
See [Feature: Converters](feature_converters.md) for the full list of board conversions available.
### Pointing and Digitizer device updates :id=pointing-and-digitizer
Both pointing devices and digitizer got a host of updates this cycle. Inertia, automatic mouse layers, fixes for preventing sleep... you even get more buttons with digitizers!
* add "inertia" mode for mouse keys ([#18774](https://github.com/qmk/qmk_firmware/pull/18774))
* Fixup aurora/corne on develop ([#19144](https://github.com/qmk/qmk_firmware/pull/19144))
* Minor lint fixes for various info.json ([#19146](https://github.com/qmk/qmk_firmware/pull/19146))
Others:
* Add DD mapping for LED/RGB Matrix max brightness ([#18403](https://github.com/qmk/qmk_firmware/pull/18403))
* Add DD mapping for LED/RGB Matrix split count ([#18408](https://github.com/qmk/qmk_firmware/pull/18408))
* Add DD mapping for LED/RGB Matrix HSVS steps ([#18414](https://github.com/qmk/qmk_firmware/pull/18414))
* Remove RGBLIGHT_ANIMTION and clean up effect defines for 0-F ([#18725](https://github.com/qmk/qmk_firmware/pull/18725))
* Merge API update workflow ([#19121](https://github.com/qmk/qmk_firmware/pull/19121))
Bugs:
* Fix layer switching from tap dances by redoing the keymap lookup ([#17935](https://github.com/qmk/qmk_firmware/pull/17935))
* ws2812: replace RGBLED_NUM with driver-owned constant to decouple driver from RGBLEDs/RGBMATRIX defines ([#18036](https://github.com/qmk/qmk_firmware/pull/18036))
* Prevent USB peripheral fault when restarting USB on WB32 MCUs ([#18058](https://github.com/qmk/qmk_firmware/pull/18058))
* Fix mouse report comparison failing on shared EP (fixes KB preventing sleep) ([#18060](https://github.com/qmk/qmk_firmware/pull/18060))
@ -66,3 +66,41 @@ Once your compile job has finished you'll check the `result` key. The value of t
* `firmware_keymap_url`: A list of URLs for the `keymap.c`
* `firmware_keymap_url`: A list of URLs for the `keymap.c`
* `firmware_source_url`: A list of URLs for the full firmware source code
* `firmware_source_url`: A list of URLs for the full firmware source code
* `output`: The stdout and stderr for this compile job. Errors will be found here.
* `output`: The stdout and stderr for this compile job. Errors will be found here.
## Constants :id=qmk-constants
If you're writing a tool that leverages constants used within QMK, the API is used to publish "locked-in" versions of those constants in order to ensure that any third-party tooling has a canonical set of information to work with.
The list of available constants can be retrieved by accessing one of the following endpoints:
```
$ curl https://keyboards.qmk.fm/v1/constants_metadata.json # For `master`
!> Versions exported by the `master` endpoint are locked-in. Any extra versions that exist on the `develop` endpoint which don't exist in `master` are subject to change.
?> Only keycodes are currently published, but over time all other "externally visible" IDs are expected to appear on these endpoints.
To retrieve the constants associated with a subsystem, the endpoint format is as follows:
- submitters can have a personal (or bells-and-whistles) keymap showcasing capabilities in the same PR but it shouldn't be embedded in the 'default' keymap
- submitters can have a personal (or bells-and-whistles) keymap showcasing capabilities in the same PR but it shouldn't be embedded in the 'default' keymap
- submitters can also have a "manufacturer-matching" keymap that mirrors existing functionality of the commercial product, if porting an existing board
- submitters can also have a "manufacturer-matching" keymap that mirrors existing functionality of the commercial product, if porting an existing board
- Do not include VIA json files in the PR. These do not belong in the QMK repository as they are not used by QMK firmware -- they belong in the [VIA Keyboard Repo](https://github.com/the-via/keyboards)
- Do not include VIA json files in the PR. These do not belong in the QMK repository as they are not used by QMK firmware -- they belong in the [VIA Keyboard Repo](https://github.com/the-via/keyboards)
- Do not include KLE json files in the PR. These have no use within QMK.
- Do not include source files from another keyboard or vendors keyboard folder. Including core files is fine.
- Do not include source files from another keyboard or vendors keyboard folder. Including core files is fine.
- For instance, only `wilba_tech` boards shall include `keyboards/wilba_tech/wt_main.c` and `keyboards/wilba_tech/wt_rgb_backlight.c`. But including `drivers/sensors/pmw3360.c` is absolutely fine for any and all boards.
- For instance, only `wilba_tech` boards shall include `keyboards/wilba_tech/wt_main.c` and `keyboards/wilba_tech/wt_rgb_backlight.c`. But including `drivers/sensors/pmw3360.c` is absolutely fine for any and all boards.
- Code that needs to be used by multiple boards is a candidate for core code changes, and should be separated out.
- Code that needs to be used by multiple boards is a candidate for core code changes, and should be separated out.
@ -135,7 +136,7 @@ Also, specific to ChibiOS:
- for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified
- for new MCUs, a new "child" keyboard should be added that targets your newly-added MCU, so that builds can be verified
- for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided
- for new hardware support such as display panels, core-side matrix implementations, or other peripherals, an associated keymap should be provided
- if an existing keymap exists that can leverage this functionality this may not be required (e.g. a new RGB driver chip, supported by the `rgb` keymap) -- consult with the QMK Collaborators on Discord to determine if there is sufficient overlap already
- if an existing keymap exists that can leverage this functionality this may not be required (e.g. a new RGB driver chip, supported by the `rgb` keymap) -- consult with the QMK Collaborators on Discord to determine if there is sufficient overlap already
- any features adding `_kb`/`_user` callbacks must return a `bool`, to allow for user override of keyboard-level callbacks.
- any features adding `_kb`/`_user` callbacks must return a `bool`, to allow for user override of keyboard-level callbacks.
- other requirements are at the discretion of QMK collaborators
- other requirements are at the discretion of QMK collaborators
- core is a lot more subjective given the breadth of posted changes
- core is a lot more subjective given the breadth of posted changes
Warning- This is the `develop` branch of QMK Firmware. You may encounter broken code here. Please see [Breaking Changes](https://docs.qmk.fm/#/breaking_changes) for more information.
Nick Brassel
2 years ago
committed by
GitHub