Breaking changes for 2022q2. (#17221)
This commit is contained in:
parent
ebd4027883
commit
d0af56da33
3 changed files with 99 additions and 44 deletions
|
@ -2,48 +2,102 @@
|
|||
|
||||
## Notable Features :id=notable-features
|
||||
|
||||
### TODO
|
||||
### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) :id=caps-word
|
||||
|
||||
This is a new feature that allows for capslock-like functionality that turns itself off at the end of the word.
|
||||
|
||||
For instance, if you wish to type "QMK" without holding shift the entire time, you can either tap both left and right shift, or double-tap shift, to turn on _Caps Word_ -- then type `qmk` (lowercase) without holding shift. Once you hit any key other than `a`--`z`, `0`--`9`, `-`, `_`, delete, or backspace, this will go back to normal typing!
|
||||
|
||||
There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](feature_caps_word.md) for more information.
|
||||
|
||||
### Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) :id=quantum-painter
|
||||
|
||||
QMK has had support for small OLED displays for some time now, but hasn't really gained too much ability to draw to panels other than the SSD1306 or SH1106 panels.
|
||||
|
||||
Quantum Painter is a new drawing subsystem available to suitable ARM and RISC-V boards that is capable of drawing to large panel RGB LCDs and RGB OLEDs. It also allows for a lot more flexibility with a larger set of drawing APIs -- lines, rectangles, circles, ellipses, text, images, and even animations.
|
||||
|
||||
The QMK CLI has new commands added to be able to generate images and fonts for Quantum Painter to digest -- it's even capable of converting animated gifs for display on screen.
|
||||
|
||||
See the [Quantum Painter documentation](quantum_painter.md) for more information on how to set up the displays as well as how to convert images and fonts.
|
||||
|
||||
!> Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter.
|
||||
|
||||
### Encoder Mapping ([#13286](https://github.com/qmk/qmk_firmware/pull/13286)) :id=encoder-mapping
|
||||
|
||||
One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](feature_encoders.md#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap.
|
||||
|
||||
!> This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA.
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
|
||||
### `RESET` => `QK_BOOT` ([#17037](https://github.com/qmk/qmk_firmware/pull/17037)) :id=reset-2-qk_boot
|
||||
|
||||
QMK is always in the process of picking up support for new hardware platforms. One of the side-effects for future integrations has shown that QMK's usage of `RESET` as a keycode is causing naming collisions. As a result, [#17037](https://github.com/qmk/qmk_firmware/pull/17037) changed usages of `RESET` to the new keycode `QK_BOOT` in the majority of default-like keymaps. At this stage the old keycode is still usable but will likely be removed in the next breaking changes cycle. Users with keymaps containing `RESET` should also move to `QK_BOOT`.
|
||||
|
||||
### Sendstring keycode overhaul ([#16941](https://github.com/qmk/qmk_firmware/pull/16941)) :id=sendstring-keycodes
|
||||
|
||||
Some keycodes used with `SEND_STRING` and its relatives have been deprecated and may have their old keycode usages removed at a later date. The list of [deprecated keycodes](https://github.com/qmk/qmk_firmware/blob/ebd402788346aa6e88bde1486b2a835684d40d39/quantum/send_string_keycodes.h#L456-L505) should be consulted to determine if you're using one of the older names (the first identifier after `#define`) -- you should swap to the newer variant (the second identifier on the same line).
|
||||
|
||||
### Pillow Installation ([#17133](https://github.com/qmk/qmk_firmware/pull/17133)) :id=pillow-install
|
||||
|
||||
The merge of Quantum Painter added some new dependencies in the QMK CLI, most notably _Pillow_, which requires some installation in order for the CLI to function. If you've got an existing installation, you'll need to run some commands in order to get things working:
|
||||
|
||||
On Windows, if using _QMK MSYS_ or _msys2_, you'll need to run the following command:
|
||||
|
||||
```sh
|
||||
pacman --needed --noconfirm --disable-download-timeout -S mingw-w64-x86_64-python-pillow
|
||||
python3 -m pip install --upgrade qmk
|
||||
```
|
||||
|
||||
On macOS:
|
||||
|
||||
```sh
|
||||
brew update
|
||||
brew upgrade qmk/qmk/qmk
|
||||
```
|
||||
|
||||
On Linux or WSL:
|
||||
|
||||
```sh
|
||||
python3 -m pip install --user --upgrade qmk
|
||||
```
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|-----------------------|--------------------|
|
||||
| absinthe | keyhive/absinthe |
|
||||
| amj40 | amjkeyboard/amj40 |
|
||||
| amj60 | amjkeyboard/amj60 |
|
||||
| amj96 | amjkeyboard/amj96 |
|
||||
| amjpad | amjkeyboard/amjpad |
|
||||
| at101_bh | viktus/at101_bh |
|
||||
| ergosaurus | keyhive/ergosaurus |
|
||||
| gmmk/pro/ansi | gmmk/pro/rev1/ansi |
|
||||
| gmmk/pro/iso | gmmk/pro/rev1/iso |
|
||||
| honeycomb | keyhive/honeycomb |
|
||||
| lattice60 | keyhive/lattice60 |
|
||||
| melody96 | ymdk/melody96 |
|
||||
| mt40 | mt/mt40 |
|
||||
| mt64rgb | mt/mt64rgb |
|
||||
| mt84 | mt/mt84 |
|
||||
| mt980 | mt/mt980 |
|
||||
| navi10 | keyhive/navi10 |
|
||||
| omnikey_bh | viktus/omnikey_bh |
|
||||
| opus | keyhive/opus |
|
||||
| smallice | keyhive/smallice |
|
||||
| southpole | keyhive/southpole |
|
||||
| uno | keyhive/uno |
|
||||
| ut472 | keyhive/ut472 |
|
||||
| wheatfield/blocked65 | mt/blocked65 |
|
||||
| wheatfield/split75 | mt/split75 |
|
||||
| z150_bh | viktus/z150_bh |
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
|
||||
### TODO
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|----------------------|--------------------|
|
||||
| absinthe | keyhive/absinthe |
|
||||
| amj40 | amjkeyboard/amj40 |
|
||||
| amj60 | amjkeyboard/amj60 |
|
||||
| amj96 | amjkeyboard/amj96 |
|
||||
| amjpad | amjkeyboard/amjpad |
|
||||
| at101_bh | viktus/at101_bh |
|
||||
| ergosaurus | keyhive/ergosaurus |
|
||||
| gmmk/pro/ansi | gmmk/pro/rev1/ansi |
|
||||
| gmmk/pro/iso | gmmk/pro/rev1/iso |
|
||||
| honeycomb | keyhive/honeycomb |
|
||||
| lattice60 | keyhive/lattice60 |
|
||||
| melody96 | ymdk/melody96 |
|
||||
| mt40 | mt/mt40 |
|
||||
| mt64rgb | mt/mt64rgb |
|
||||
| mt84 | mt/mt84 |
|
||||
| mt980 | mt/mt980 |
|
||||
| navi10 | keyhive/navi10 |
|
||||
| omnikey_bh | viktus/omnikey_bh |
|
||||
| opus | keyhive/opus |
|
||||
| smallice | keyhive/smallice |
|
||||
| southpole | keyhive/southpole |
|
||||
| uno | keyhive/uno |
|
||||
| ut472 | keyhive/ut472 |
|
||||
| wheatfield/blocked65 | mt/blocked65 |
|
||||
| wheatfield/split75 | mt/split75 |
|
||||
| z150_bh | viktus/z150_bh |
|
||||
|
||||
---
|
||||
|
||||
## Full changelist
|
||||
## Full changelist :id=full-changelist
|
||||
|
||||
Core:
|
||||
* Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174))
|
||||
|
@ -120,6 +174,7 @@ Keyboards:
|
|||
* Helix/rev2 move to split common ([#16723](https://github.com/qmk/qmk_firmware/pull/16723))
|
||||
* Remove some layout exceptions ([#16957](https://github.com/qmk/qmk_firmware/pull/16957))
|
||||
* Refactor legacy quantum keycodes in default-ish keymaps ([#17037](https://github.com/qmk/qmk_firmware/pull/17037))
|
||||
* Refactor legacy quantum keycodes in default-ish keymaps ([#17150](https://github.com/qmk/qmk_firmware/pull/17150))
|
||||
|
||||
Keyboard fixes:
|
||||
* gboards/gergoplex: move `COMBO_ENABLE` to keymap level ([#16667](https://github.com/qmk/qmk_firmware/pull/16667))
|
||||
|
|
|
@ -22,17 +22,17 @@ The breaking change period is when we will merge PR's that change QMK in dangero
|
|||
|
||||
## When is the next Breaking Change?
|
||||
|
||||
The next Breaking Change is scheduled for May 28, 2022.
|
||||
The next Breaking Change is scheduled for August 27, 2022.
|
||||
|
||||
### Important Dates
|
||||
|
||||
* [x] 2022 Feb 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
|
||||
* [ ] 2022 Apr 31 - `develop` closed to new PR's.
|
||||
* [ ] 2022 Apr 31 - Call for testers.
|
||||
* [ ] 2022 May 14 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
|
||||
* [ ] 2022 May 26 - `master` is locked, no PR's merged.
|
||||
* [ ] 2022 May 28 - Merge `develop` to `master`.
|
||||
* [ ] 2022 May 28 - `master` is unlocked. PR's can be merged again.
|
||||
* [x] 2022 May 28 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
|
||||
* [ ] 2022 Jul 31 - `develop` closed to new PR's.
|
||||
* [ ] 2022 Jul 31 - Call for testers.
|
||||
* [ ] 2022 Aug 13 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
|
||||
* [ ] 2022 Aug 25 - `master` is locked, no PR's merged.
|
||||
* [ ] 2022 Aug 27 - Merge `develop` to `master`.
|
||||
* [ ] 2022 Aug 27 - `master` is unlocked. PR's can be merged again.
|
||||
|
||||
## What changes will be included?
|
||||
|
||||
|
@ -43,7 +43,7 @@ If you want your breaking change to be included in this round you need to create
|
|||
Criteria for acceptance:
|
||||
|
||||
* The PR is complete and ready to merge
|
||||
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220226`.
|
||||
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220827`.
|
||||
* This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PR's ID.
|
||||
* One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.
|
||||
|
||||
|
|
|
@ -67,7 +67,7 @@ Additionally, if one side does not have an encoder, you can specify `{}` for the
|
|||
#define ENCODER_RESOLUTIONS_RIGHT { 4 }
|
||||
```
|
||||
|
||||
## Encoder map
|
||||
## Encoder map :id=encoder-map
|
||||
|
||||
Encoder mapping may be added to your `keymap.c`, which replicates the normal keyswitch layer handling functionality, but with encoders. Add this to your `rules.mk`:
|
||||
|
||||
|
|
Loading…
Reference in a new issue