Next batch.

qmk · May 28, 2023 · 1f30100 · 1f30100
1 parent 30ca295
commit 1f30100
Showing 1 changed file with 49 additions and 10 deletions.
diff --git a/docs/ChangeLog/20230528.md b/docs/ChangeLog/20230528.md
@@ -1,12 +1,59 @@
 # QMK Breaking Changes - 2023 May 28 Changelog
 
+## Notable Changes :id=notable-changes
+
+As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, adding support for general community layouts to keyboards, as well as addressing technical debt.
+
+Of note for keyboard designers:
+
+* Layout and matrix definitions in `info.json` are now _mandatory_ for merge into QMK.
+    * Layout macros in `<yourkeyboard>.h` are no longer accepted into QMK Firmware.
+    * Existing keyboards have been meticulously converted by the QMK collaborators
+    * Layouts missing from keyboard definitions have been added in the process
+    * Keys within layouts should not specify `"w":1` or `"h":1` if the key size is 1 -- `w`/`h` should only be present for sizes other than 1
+* `config_common.h` has been removed and should not be present anywhere in your keyboard code.
+* `RGB_DI_PIN` for will now cause an error during build
+    * For WS2812-like LEDs, this should be moved to `info.json`: `"ws2812": { "pin": "xxx" }`
+    * For APA102 LEDs, this should be moved to `info.json`: `"apa102": { "data_pin": "xxx" }`
+* Other mandatory data-driven changes should be automatically flagged during build
+* Keymaps with `encoder_map` should now have the following change made:
+    * `encoder_map[][NUM_ENCODERS][2]` => `encoder_map[][NUM_ENCODERS][NUM_DIRECTIONS]`
+    * Users would decide to change the `[2]`, stating "my board only has 1 encoder, so it should be `[1]`", necessitating support
+
+### Repeat last key ([#19700](https://github.com/qmk/qmk_firmware/pull/19700))
+
+A new pair of keys has been added to QMK -- namely `QK_REPEAT_KEY` and `QK_ALT_REPEAT_KEY` (shortened: `QK_REP`/`QK_AREP`). These allow you to repeat the last key pressed, or in the case of the alternate key, press the "opposite" of the last key. For example, if you press `KC_LEFT`, pressing `QK_REPEAT_KEY` afterwards repeats `KC_LEFT`, but pressing `QK_ALT_REPEAT_KEY` instead sends `KC_RIGHT`.
+
+The full list of default alternate keys is available on the [Repeat Key](feature_repeat_key.md) documentation.
+
+To enable these keys, in your keymap's `rules.mk`, add:
+
+```make
+REPEAT_KEY_ENABLE = yes
+```
+
+...and add them to your keymap.
+
+### User callback for pre process record ([#20584](https://github.com/qmk/qmk_firmware/pull/20584))
+
+Two new boolean callback functions, `pre_process_record_kb` and `pre_process_record_user`, have been added. They are called at the beginning of `process_record`, right before `process_combo`.
+
+Similar to existing `*_kb` and `*_user` callback functions, returning `false` will halt further processing of key events. The `pre_process_record_user` function will allow user space opportunity to handle or capture an input before it undergoes quantum processing. For example, while action tapping is still resolving the tap or hold output of a mod-tap key, `pre_process_record_user` can capture the next key record of an input event that follows. That key record can be used to influence the [decision of the mod-tap](https://docs.qmk.fm/#/tap_hold) key that is currently undergoing quantum processing.
+
 ## Changes Requiring User Action :id=changes-requiring-user-action
 
+### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#20211](https://github.com/qmk/qmk_firmware/pull/20211)) :id=i-m-t-i
+
+Following up from the last breaking changes cycle, `IGNORE_MOD_TAP_INTERRUPT` has been removed and if present in keymap code, will now fail to build. The previous functionality for `IGNORE_MOD_TAP_INTERRUPT` is now default, and should you wish to revert to the old behaviour, you can use `HOLD_ON_OTHER_KEY_PRESS` instead.
+
+For more information, you are invited to read the section on [HOLD_ON_OTHER_KEY_PRESS](tap_hold.md#hold-on-other-key-press) in the page on [Tap-Hold configuration options](tap_hold.md).
+
 ### Updated Keyboard Codebases :id=updated-keyboard-codebases
 
 | Old Keyboard Name               | New Keyboard Name                   |
 |---------------------------------|-------------------------------------|
 | ashpil/modelm_usbc              | ibm/model_m/ashpil_usbc             |
+| binepad/bn009r2                 | binepad/bn009/r2                    |
 | converter/modelm101             | ibm/model_m/teensypp                |
 | converter/modelm101_teensy2     | ibm/model_m/teensy2                 |
 | converter/modelm_ssk            | ibm/model_m_ssk/teensypp_ssk        |
@@ -15,6 +62,8 @@
 | jacky_studio/piggy60/hotswap    | jacky_studio/piggy60/rev1/hotswap   |
 | jacky_studio/piggy60/solder     | jacky_studio/piggy60/rev1/solder    |
 | kamigakushi                     | jaykeeb/kamigakushi                 |
+| massdrop/thekey                 | drop/thekey/v1                      |
+| massdrop/thekey_v2              | drop/thekey/v2                      |
 | mschwingen/modelm               | ibm/model_m/mschwingen              |
 | tronguylabs/m122_3270           | ibm/model_m_122/m122_3270           |
 | tronguylabs/m122_3270/blackpill | ibm/model_m_122/m122_3270/blackpill |
@@ -24,16 +73,6 @@
 
 ## Notable core changes :id=notable-core
 
-As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, as well as addressing general tech debt.
-
-One notable change for keyboard designers is that layout definitions in `info.json` is now _mandatory_ for merge into QMK. Layout macros in `<yourkeyboard>.h` are no longer accepted into QMK Firmware.
-
-### User callback for pre process record ([#20584](https://github.com/qmk/qmk_firmware/pull/20584))
-
-Two new boolean callback functions, `pre_process_record_kb` and `pre_process_record_user`, have been added. They are called at the beginning of `process_record`, right before `process_combo`.
-
-Similar to existing `*_kb` and `*_user` callback functions, returning `false` will halt further processing of key events. The `pre_process_record_user` function will allow user space opportunity to handle or capture an input before it undergoes quantum processing. For example, while action tapping is still resolving the tap or hold output of a mod-tap key, `pre_process_record_user` can capture the next key record of an input event that follows. That key record can be used to influence the [decision of the mod-tap](https://docs.qmk.fm/#/tap_hold) key that is currently undergoing quantum processing.
-
 ### Encoder functionality fallback ([#20320](https://github.com/qmk/qmk_firmware/pull/20320))
 
 For keyboards who have not yet been migrated to encoder map, a default set of encoder functionality is now enabled, gracefully degrading functionality depending on which flags are enabled by the keyboard: