Pros of QMK Firmware

• Extensive feature set and customization options
• Large community and ecosystem of supported keyboards
• Well-documented and mature project with a long history

Cons of QMK Firmware

• Requires flashing the entire firmware for changes
• Limited wireless support, primarily focused on wired keyboards
• Higher power consumption, not optimized for battery-powered devices

Code Comparison

ZMK (Zephyr-based keyboard firmware):

/ {
    behaviors {
        td0: tap_dance_0 {
            compatible = "zmk,behavior-tap-dance";
            label = "TAP_DANCE_0";
            #binding-cells = <0>;
            tapping-term-ms = <200>;
            bindings = <&kp A>, <&kp B>, <&kp C>;
        };
    };
};

QMK Firmware:

enum {
    TD_ABC = 0
};

qk_tap_dance_action_t tap_dance_actions[] = {
    [TD_ABC] = ACTION_TAP_DANCE_DOUBLE(KC_A, KC_B)
};

Both firmware projects offer powerful customization for mechanical keyboards, but ZMK focuses on wireless, battery-efficient designs using a modern RTOS, while QMK provides a more extensive feature set for traditional wired keyboards.

Pros of KMK Firmware

• Written in CircuitPython, making it more accessible for beginners
• Supports a wider range of microcontrollers, including non-wireless boards
• Easier to customize and extend due to Python's simplicity

Cons of KMK Firmware

• Limited wireless functionality compared to ZMK
• Potentially slower performance due to interpreted language
• Less power-efficient for battery-powered keyboards

Code Comparison

KMK Firmware (Python):

from kmk.kmk_keyboard import KMKKeyboard
from kmk.keys import KC

keyboard = KMKKeyboard()
keyboard.keymap = [
    [KC.A, KC.B, KC.C]
]

ZMK (C):

#include <behaviors.dtsi>
#include <dt-bindings/zmk/keys.h>

/ {
    keymap {
        compatible = "zmk,keymap";
        default_layer {
            bindings = <
                &kp A &kp B &kp C
            >;
        };
    };
};

ZMK uses a device tree syntax for configuration, while KMK uses Python. ZMK's approach is more optimized for embedded systems but may be less intuitive for beginners. KMK's Python-based configuration is more readable and easier to modify for those familiar with the language.

Pros of Miryoku

• Highly optimized and ergonomic keyboard layout system
• Extensive customization options for various keyboard types
• Well-documented and beginner-friendly configuration process

Cons of Miryoku

• Limited to specific layout philosophy, less flexible for non-standard layouts
• Smaller community and fewer resources compared to ZMK
• May require more initial setup time for users unfamiliar with the layout concept

Code Comparison

Miryoku (layout definition):

#define MIRYOKU_LAYERS BASE, NAV, MOUSE, MEDIA, NUM, SYM, FUN
#define MIRYOKU_MAPPING( \
    K00, K01, K02, K03, K04,      K05, K06, K07, K08, K09, \
    K10, K11, K12, K13, K14,      K15, K16, K17, K18, K19, \
    K20, K21, K22, K23, K24,      K25, K26, K27, K28, K29, \
         K31, K32, K33, K34,      K35, K36, K37, K38 \
)

ZMK (keymap definition):

/ {
    keymap {
        compatible = "zmk,keymap";
        default_layer {
            bindings = <
                &kp Q &kp W &kp E &kp R &kp T    &kp Y &kp U &kp I &kp O &kp P
                &kp A &kp S &kp D &kp F &kp G    &kp H &kp J &kp K &kp L &kp SEMI
                &kp Z &kp X &kp C &kp V &kp B    &kp N &kp M &kp COMMA &kp DOT &kp SLASH
                            &mo 1 &kp SPACE      &kp ENTER &mo 2
            >;
        };
    };
};

Pros of nrfmicro

• Specifically designed for nRF52 microcontrollers, offering optimized support for these chips
• Includes hardware designs and PCB layouts for custom keyboard builds
• Provides a more focused and specialized firmware solution for nRF52-based keyboards

Cons of nrfmicro

• Limited to nRF52 microcontrollers, reducing flexibility for other chip types
• Smaller community and potentially less frequent updates compared to ZMK
• May have fewer features and less extensive documentation than ZMK

Code Comparison

nrfmicro:

#define PIN_SDA 17
#define PIN_SCL 20
#define PIN_BLE_LED 19
#define PIN_USB_LED 18

ZMK:

#define DT_DRV_COMPAT zmk_kscan_gpio_direct
#include <device.h>
#include <drivers/gpio.h>
#include <sys/util.h>

The nrfmicro code snippet shows pin definitions specific to nRF52 microcontrollers, while the ZMK code demonstrates a more generic approach using Zephyr RTOS conventions, allowing for broader hardware support.

Pros of crkbd

• Specifically designed for the Corne keyboard, offering tailored support and optimizations
• Includes PCB designs and case files for physical keyboard construction
• Provides a straightforward QMK-based firmware setup for Corne keyboards

Cons of crkbd

• Limited to Corne keyboard layouts and configurations
• Lacks advanced wireless features and power management capabilities
• Requires more manual configuration and setup compared to ZMK's user-friendly approach

Code Comparison

crkbd (QMK-based):

#include QMK_KEYBOARD_H

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
  [0] = LAYOUT_split_3x6_3(
    KC_TAB,  KC_Q,    KC_W,    KC_E,    KC_R,    KC_T,                      KC_Y,    KC_U,    KC_I,    KC_O,    KC_P,    KC_BSPC,
    KC_LCTL, KC_A,    KC_S,    KC_D,    KC_F,    KC_G,                      KC_H,    KC_J,    KC_K,    KC_L,    KC_SCLN, KC_QUOT,
    KC_LSFT, KC_Z,    KC_X,    KC_C,    KC_V,    KC_B,                      KC_N,    KC_M,    KC_COMM, KC_DOT,  KC_SLSH, KC_ESC,
                                        KC_LGUI, KC_LT,   KC_SPC,  KC_ENT,  KC_BSPC, KC_RALT
  )
};

ZMK:

/ {
    keymap {
        compatible = "zmk,keymap";
        default_layer {
            bindings = <
                &kp TAB   &kp Q &kp W &kp E &kp R &kp T   &kp Y &kp U  &kp I     &kp O   &kp P    &kp BSPC
                &kp LCTRL &kp A &kp S &kp D &kp F &kp G   &kp H &kp J  &kp K     &kp L   &kp SEMI &kp SQT
                &kp LSHFT &kp Z &kp X &kp C &kp V &kp B   &kp N &kp M  &kp COMMA &kp DOT &kp FSLH &kp ESC
                                &kp LGUI &mo 1 &kp SPACE  &kp RET &kp BSPC &kp RALT
            >;
        };
    };
};