diff --git a/docs/ChangeLog/20220528.md b/docs/ChangeLog/20220528.md index bac681df4b..1265c81206 100644 --- a/docs/ChangeLog/20220528.md +++ b/docs/ChangeLog/20220528.md @@ -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)) diff --git a/docs/breaking_changes.md b/docs/breaking_changes.md index 375defe87d..981512cd4c 100644 --- a/docs/breaking_changes.md +++ b/docs/breaking_changes.md @@ -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 `/docs/Changelog/20220226`. +* The PR has a ChangeLog file describing the changes under `/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. diff --git a/docs/feature_encoders.md b/docs/feature_encoders.md index a3d56fd5ef..ad6ed2bece 100644 --- a/docs/feature_encoders.md +++ b/docs/feature_encoders.md @@ -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`: