ZMK - The Future of Wireless at CK
Why ZMK?
As we prepare for the launch of our first in-house designed wireless keyboard - the BakenekoGo - one question that keeps coming up is, “Why did you choose ZMK?” or “Why didn’t you choose QMK?”. There are some notable pros to ZMK - such as the long battery life with a smaller, lighter battery, and BLE compatibility. The BakenekoGO will offer 800+ hours of battery life with a 200 mAh battery, whereas a Keychron keyboard only offers 180 hours with a 4000 mAh battery. But the whole story goes a bit deeper than just that.
Why not QMK?
A great place to start is to answer the question “Why not QMK?”. For the majority of our keyboards, we’ve used QMK. It has a rich feature set, supports VIA, and has become the community standard for most mechanical keyboards. But the BakenekoGO is wireless - and when it comes to wireless – QMK makes things a bit tricky.
First, QMK doesn’t support any natively-wireless chipsets. QMK first supported just Atmega chips, then was expanded to support STM32 and RP2040 chips. And while STM does offer wireless chips - those aren’t supported by QMK. This is not a surprise, since QMK’s open source licensing terms makes it difficult for it to offer support for these chips.
Most wireless chips that support BT wireless also use proprietary drivers. These drivers are incompatible with QMK’s licensing - so they cannot be included in QMK’s open-source code. And while forks of QMK exist that do include BT - these forks are technically not compliant with the license.
But we also know that there are boards on the market that run QMK and also offer wireless support. How are they accomplishing this legally? Some of them may be using illegally licensed forks of QMK, but the vast majority of them actually take a 2 microcontroller approach. One microcontroller (Atmega, STM32, or RP2040) runs the QMK code, and it communicates with a second microcontroller that handles all wireless communication.
This approach has some downsides. Running two microcontrollers typically consumes more power than running just one - especially when one of the microcontrollers isn’t that power-optimized. This is why many of the boards that offer QMK and wireless have poor battery life, given the size of their batteries. And with the extra microcontroller step, additional wireless latency is also introduced (extra delays in communicating with the computer). Furthermore, because QMK is a wired-first keyboard firmware that runs on the non-wireless MCU, any keymap changes with VIA typically have to happen with the keyboard plugged in.
QMK’s license requires that all products using QMK must open source their code as well. This means that the first microcontroller that runs QMK and communicates with the other microcontroller must have its code open-sourced. However, the chip that runs the actual wireless communication can be closed-source. While this might not matter to all customers - as a hobbyist-focused company, we’d rather focus on solutions that can be entirely open-sourced, and that the community can build upon.
Based on these downsides, we’ve chosen to avoid QMK for our wireless keyboards. We love QMK and will continue to use it for wired keyboards and PCBs, but for wireless, we think there are better solutions.
If not QMK, then what?
Having ruled out QMK - we had to decide on which firmware to use for wireless keyboards. There are many different keyboard firmwares that exist - some of which already support wireless. Some wireless keyboards on the market that support tri-mode 2.4/USB/BT use custom firmware that supports VIA/VIAL, but that firmware isn’t open source. And while we could have taken that approach, using open-source firmware was a requirement for us. Open-source alternatives that we considered included BlueMicro and KMK - but ultimately ended up choosing ZMK.
ZMK is built on top of the Zephyr Project Real Time Operating System (RTOS) and benefits from all the development and bug fixing on the wireless stack done by the RTOS itself. And with the decision to use Zephyr, the ZMK team was also able to build ZMK as an extremely power-efficient wireless keyboard firmware. The ZMK team is actively working on new features, and over the past few years, we’ve seen a great pace of development.
At this point - ZMK supports most of the key features we were looking for, including layered keymaps, hold-tap functionality, tap-dance functionality, key combos, macros, RGB underglow, encoders, and one-shot keys. And they continue to add new features to increase power efficiency including deep sleep states and power cutoffs for PCB components that consume power even when they are not in use.
On top of that - it’s very easy to reach the ZMK development team. They have an open Discord with lots of activity and a community of enthusiasts who have already found and love ZMK.
The Major Downside, and Our Solution
The one major downside of ZMK is the lack of a real-time key configurator similar to VIA. We know that this is a huge quality of life benefit, and if we were to choose ZMK as the platform for our future wireless keyboards, we knew we had to find a solution.
Today’s ZMK remapping experience isn’t bad. We’ve created a guide to help walk through the process - so anyone buying a BakenekoGO will already be able to remap their keyboard. The process is more analogous to QMK Configurator - which was the most common way of building QMK firmware prior to VIA’s existence. But it’s still not as easy as opening an app and clicking a few buttons to change a key. So we decided to see if we could do more.
We reached out to the ZMK dev team, or rather, more specifically, Pete Johanson, the founder and lead developer of the ZMK project. A real-time keymap editor was already something that he wanted to do, but Pete didn’t have time to work on it. So we reached out to many of our vendor friends to help financially sponsor the work. If Pete didn’t have to work on other jobs, and we could pay him for his work on ZMK, then he could finish the real-time keymap editor quickly.
The result is that ZMK Studio is nearly done - with a target of releasing a first version by the end of August. It’ll be able to remap keys and change layers, and it’ll be able to do this all over a USB cable AND wirelessly as well. More functionality is planned for quick addition after the initial launch as well. We’re extremely excited to see ZMK Studio come to fruition - but also want to advise caution in that the end of August is a target date, and things could still change.
With that being said - ZMK Studio is well along the development process and is already in a state where you can remap keys and adjust layers. If some of you are more technically minded - it’s possible to compile firmware and get ZMK Studio working - albeit in an incomplete state.
CannonKeys will definitely let you know when ZMK Studio is ready for prime time! And when it’s ready, we’ll provide guides so that anyone with a BakenekoGO can update their keyboard to support ZMK Studio.
A comparison of QMK and ZMK features.
Our Hope for the Future
ZMK doesn’t really need any help when it comes to visibility – it's well-known and often recommended in hobbyist circles for wireless keyboards. But we still hope that by sponsoring ZMK Studio and through bringing the BakenekoGO to life, ZMK will get more visibility. Visibility can bring a lot of good things to open-source projects, but also poses a lot of challenges as well. But one of the main positives of visibility is there may be developers who hear about ZMK through one of our projects and decide to contribute.
By choosing to use ZMK for our wireless keyboards, we hope we can help the project grow, and we’ll see even more functionality added into ZMK - in a similar fashion to how QMK grew organically and now supports a ton of features.
