As per last few breaking changes cycles, there have been a lot of behind-the-scenes changes, mainly around consolidation of config into info.json files, cleanup of info.json files, cleaning up driver naming, as well as addressing technical debt.
As a followup to last cycle's notable changes, as qmk/qmk_firmware is no longer accepting PRs for keymaps we're pleased to announce that storing and building keymaps externally from the normal QMK Firmware repository is now possible. This is done through the new External Userspace feature, more details below!
As mentioned above, the new External Userspace feature allows for keymaps to be stored and built externally from the main QMK Firmware repository. This allows for keymaps to be stored separately -- usually in their own repository -- and for users to be able to maintain and build their keymaps without needing to fork the main QMK Firmware repository.
A significant portion of user keymaps have already been removed from qmk/qmk_firmware and more will follow in coming weeks. You can still recover your keymap from the tag user-keymaps-still-present if required -- a perfect time to migrate to the new External Userspace!
WARNING
This feature is still in beta, and we're looking for feedback on it. Please try it out and let us know what you think -- a new #help-userspace channel has been set up on Discord.
Shutdown callbacks at the keyboard level were never present, preventing safe shutdown sequencing for peripherals such as OLEDs, RGB LEDs, and other devices. This PR adds a new shutdown_kb function, as well as amending shutdown_user, allowing for safe shutdown of peripherals at both keyboard and keymap level.
Along with the new shutdown_kb function, a new API oled_render_dirty(bool) function has been added. This allows OLED contents to be written deterministically when supplied with true -- that is, the OLED will be updated immediately, rather than waiting for the next OLED update cycle. This allows for OLEDs to show things such as "BOOTLOADER MODE" and the like if resetting to bootloader from QMK.
Switch statement helpers for keycode ranges (#20059)
Predefined ranges usable within switch statements have been added for groups of similar keycodes, where people who wish to handle entire blocks at once can do so. This allows keymaps to be immune to changes in keycode values, and also allows for more efficient code generation.
Quantum Painter has picked up support for SH1106 displays -- commonly seen as 128x64 OLEDs. Support for both I2C and SPI displays is available.
If you're already using OLED through OLED_DRIVER_ENABLE = yes or equivalent in info.json and wish to use Quantum Painter instead, you'll need to disable the old OLED system, instead enabling Quantum Painter as well as enabling the appropriate SH1106 driver. See the Quantum Painter driver documentation for more details. The old OLED driver is still available, and keymaps do not require migrating to Quantum Painter if you don't want to do so.
As you can probably tell by the list of PRs just above, there has been a lot of cleanup and consolidation this cycle when it comes to RGB/LED lighting drivers. The number of changes is too large to list here, but the general theme has been focusing on consistency of naming, both of drivers themselves and their respective implementation and configuration. Most changes only affect keyboard designers -- if you find that your in-development keyboard is no longer building due to naming of defines changing, your best bet is to refer to another board already in the repository which has had the changes applied.
When enabling peripherals such as I2C, SPI, or Analog/ADC, some required manual inclusion of source files in order to provide driver support, and in some cases, when multiple drivers were using the same underlying peripheral, files were being added to the build multiple times.
Most systems requiring other peripherals now mark their respective dependencies as "required", allowing the build system to check whether peripherals are necessary before including them in the build rather than having each location enable them manually.
For a concrete example, users or keyboard designers who previously added SRC += analog.c in order to allow for analog readings via an ADC now should specify ANALOG_DRIVER_REQUIRED = yes instead. The full list of added options is as follows:
New option
Old Equivalent
ANALOG_DRIVER_REQUIRED = yes
SRC += analog.c
APA102_DRIVER_REQUIRED = yes
SRC += apa102.c
I2C_DRIVER_REQUIRED = yes
SRC += i2c_master.c or QUANTUM_LIB_SRC += i2c_master.c
SPI_DRIVER_REQUIRED = yes
SRC += spi_master.c or QUANTUM_LIB_SRC += spi_master.c
NKRO is now available for ATmega32A and 328P-based keyboards (including PS2AVRGB/Bootmapper boards), thanks to some internal refactoring and cleanup. To enable it, the process is the same as always - add NKRO_ENABLE = yes to your rules.mk, then assign and press the NK_TOGG keycode to switch modes.