DIY keyboards become confusing when names from different layers are treated as alternatives: Keyball, Charybdis, Dactyl Manuform, Kinesis Advantage 360, QMK, ZMK, Vial, RP2040, and 2.4G are all related to keyboards, but they solve different problems.
The useful approach is simple: separate the layers first, then choose the firmware, controller, and transport.
A map of the stack
textErgonomic design / product shape↓PCB, matrix, trackball, and other hardware↓MCU / controller board↓QMK or ZMK firmware↓USB, BLE, UART, or proprietary 2.4G transport↓Computer, phone, or USB receiver
- Keyball, Charybdis, and Dactyl Manuform are keyboard designs. Keyball and Charybdis add a trackball as a central interaction method; Dactyl Manuform focuses on a curved ergonomic shell. A design determines the shape, layout, and hardware arrangement. It does not dictate one firmware.
- Kinesis Advantage 360 is a commercial ergonomic keyboard product. Dactyl Manuform is closer to an open DIY design family.
- Aldexuan/MCK is a concrete keyboard project and product documentation set. Its Trackball line is a wired split trackball keyboard kit with 39, 44, 47, 59, and 61-key variants; the 59 layout adds dual rotary encoders. The project uses RP2040 with QMK/Vial and includes features such as OLEDs, RGB, and mouse modes. It is not a general firmware like QMK/ZMK or a configurator like Vial.
- QMK and ZMK are firmware. They scan keys, process layers and behaviors, and emit HID reports.
- Vial is a graphical configurator built around the Vial-QMK firmware fork. It is generally used with Vial-QMK keyboards and does not configure ZMK.
- RP2040, nRF52840, and STM32 are MCU or controller platforms.
- USB, BLE, and 2.4G are transports. BLE and proprietary 2.4G both use the 2.4GHz band, but their protocols, pairing, and firmware support are different.
In MCK's Trackball line, names such as Trackball39, Trackball47, and Trackball59 identify different layouts and key-count variants. They are design variants, not firmware names; the complete line also includes 44-key and 61-key layouts.
Choosing between QMK and ZMK
QMK: wired, broad, and deeply customizable
QMK is mature, widely documented, and feature-rich. It fits wired keyboards, complex layer logic, RGB, OLEDs, encoders, trackballs, and custom C code. Its pointing-device interfaces make CPI/DPI switching, mouse layers, and scrolling modes practical to implement.
The trade-off is equally clear: QMK is designed around USB wired keyboards. Bluetooth support relies on a small set of specific modules, and a general-purpose 2.4G receiver mode is not a standard mainline QMK capability. Wireless products often need vendor firmware, a custom fork, or an additional protocol layer.
This combination is a strong QMK case:
textRP2040 or STM32 + trackball + DPI control + Vial
ZMK: batteries, BLE, and split keyboards
ZMK is designed around low power and wireless splits. A typical setup is: the right half connects to the left half over BLE, and the left half acts as the central device that connects to the computer over BLE. Multi-device profiles, sleep states, and battery reporting make it a natural fit for battery-powered Corne, Lily58, and Keyball builds.
The trade-off is a narrower ecosystem and a different configuration model. ZMK uses Devicetree, Kconfig, and behaviors. Simple keymaps require little C code, but complex hardware requires understanding the Zephyr-based configuration system. ZMK has no general proprietary 2.4G dongle mode and does not offer the same universal configuration path as Vial; support depends on the selected board, shield, and driver.
The usual ZMK choice is an nRF52840 controller such as nice!nano, nRFMicro nRF52840, or XIAO nRF52840. nRF52833 can reduce cost, but its smaller memory budget needs to be considered before adding displays or complex features.
Controller selection
| Goal | Recommendation | Judgment |
|---|
RP2040 can run ZMK, but the chip itself has no BLE radio. Used alone, it is normally a USB or wired controller. For native BLE wireless splits, choosing nRF52840 directly is the cleaner design.
Four split-wireless architectures
The table below assumes that the left half is the central device. Some products move the central role into the USB dongle.
| Scheme | Links | Advantages | Costs | Best fit |
|---|
The key lesson is that 2.4G is not a firmware and it does not mean BLE. The shared frequency band says nothing about protocol compatibility. QMK or ZMK can use a wireless transport only when the firmware and receiver implement that transport.
Practical decisions
- For RP2040, a trackball, DPI control, and Vial, use QMK. Choose STM32F411/F401 when the design needs more GPIO, a display, or several peripherals.
- For a battery-powered wireless split, use nRF52840 with ZMK.
- For a simple, lower-cost wireless keyboard, nRF52833 is reasonable, but do not assume it has enough room for displays and complex behaviors.
- For a proprietary 2.4G USB receiver, verify the radio protocol and firmware source first. A product label that says QMK or ZMK is not enough.
- For a stable, easy-to-debug split, wired QMK remains the direct option.
The exploration reduces to five rules: decide the transport before the firmware; select the MCU around the hardest peripheral; keep design, firmware, configurator, and protocol as separate concepts; never treat “supports a firmware” as “supports every wireless mode”; and check pins, power, bootloader, and shield definitions before assuming two controller boards are interchangeable.
Comments