zmkfirmware
/
zmk
mirror of https://github.com/zmkfirmware/zmk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: Update docs/blog post to reference ZMK variants 

* Update Zephyr 4.1 blog post to mention ZMK variants
* Add note to hardware support page about variants
This commit is contained in:
Peter Johanson 2026-01-16 13:33:47 -07:00
parent 854a4616aa
commit f92b154038
2 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/blog/2025-12-09-zephyr-4-1.md
View File

@ -8,6 +8,14 @@ We're happy to announce that after a long wait, ZMK's `main` branch is now runni
<!-- truncate -->
:::note
The following changes have been made since this blog post was originally published:
- The [move to `zmk` variants by default](https://github.com/zmkfirmware/zmk/pull/3145) for ZMK boards was documented.
:::
Zephyr 4.1 is a large leap forward from our previous version of 3.5, featuring:
- Support for lots of new SoCs, boards, and shields, such as the WCH CH32V003, the Raspberry Pi Pico 2, and [many many more](https://docs.zephyrproject.org/4.1.0/boards/index.html#boards).
@ -61,6 +69,12 @@ The following steps will get you building ZMK locally against Zephyr 4.1:
From there, you should be ready to build as normal!
## ZMK Board Variant
The new Zephyr version includes a [standard mechanism for extending boards](https://docs.zephyrproject.org/4.1.0/hardware/porting/board_porting.html#board-extensions) found in Zephyr (like the Seeeduino XIAO, or Raspberry Pi Pico) with new variants that include additional configuration/defaults that are relevant to the application. This also means the original "stock" board can still be used as is, if consumers don't want to use those customizations for any reason.
As a result, all board definitions found in the ZMK tree now must be used with a `zmk` variant. For example, the previous board ID of `adv360pro_left` would now be `adv360pro_left/nrf52840/zmk`, which can be shortened to `adv360pro_left//zmk` since there's only one SoC on the board.
## Board Revisions
As part of this change, ZMK is now using board/shield revisions, rather than duplicate board/shield definitions. This means that instead of having e.g. `nice_nano`, and `nice_nano_v2`, we only have `nice_nano`, which by default points to the `2.0.0` revision. To point to the original Nice!Nano V1, you would need to use `nice_nano@1.0.0` where you would have previously used `nice_nano`. Of course, you could also put `nice_nano@2.0.0` if you wished to make that explicit, instead of merely replacing `nice_nano_v2` with `nice_nano`. Some boards, such as the `nrfmicro`, also have additional _board qualifiers_ such as the choice between multiple SoCs. Board qualifiers must always be specified, and do not have defaults. See [Zephyr's overview](https://docs.zephyrproject.org/4.1.0/hardware/porting/board_porting.html#board-terminology) for more information on board qualifiers. The below table provides an overview of some of the differences in in-tree boards we have in ZMK, and how they are selected in the new build system. The shorthand shows the minimum needed to build with a specific board, taking into account defaults.

6
docs/docs/hardware.mdx
View File

@ -44,6 +44,12 @@ With the solid technical foundation of Zephyr™ RTOS, ZMK can support a wide di
including but not limited to Nordic nRF52, Raspberry Pi RP2040/RP2350, most ST STM32 MCUs, and Microchip SAMD21.
That being said, there are specific [boards / shields](development/hardware-integration/index.mdx#boards--shields) that have been implemented and tested by the ZMK contributors, listed below.
:::note
With the [upgrade to Zephyr 4.1](/blog/2025/12/09/zephyr-4-1#zmk-board-variant), the ZMK project has moved all in-tree boards to use a `zmk` [board variant](https://docs.zephyrproject.org/4.1.0/glossary.html#term-variant), for consistency when distinguishing from stock boards that are actually in upstream Zephyr.
:::
<HardwareList items={Metadata} />
{/* prettier-ignore */}