Published on • 14 min read • By The Peripheral Stack

Vial vs. VIA vs. QMK vs. ZMK: Which Firmware Do You Need?

#split-keyboards#dev-setup#ergonomics

If you’ve recently fallen down the custom mechanical keyboard rabbit hole—and especially if you’re exploring the world of ergonomic split keyboards—you’ve likely been hit with an alphabet soup of acronyms: QMK, ZMK, VIA, Vial, ZMK Studio.

You ask a question on a forum: “How do I change what this key does?” The responses pour in: “Just flash QMK!”, “Use VIA!”, “Vial is better!”, “Actually, you need ZMK for wireless.”

It is incredibly confusing. It took me months of tinkering to actually understand how these pieces fit together. The biggest source of this confusion is that beginners (and often even experienced builders) conflate firmware engines with graphical configuration tools.

In this comprehensive guide, we are going to untangle this web. We’ll explore exactly what each of these tools does, where their boundaries lie, and most importantly, how to choose the right stack for your specific keyboard and workflow.

1. The Confusion Problem: Firmware vs. GUI

The first step to understanding keyboard configuration is drawing a hard line between what runs on the keyboard and what runs on your computer.

  • Firmware Engine (QMK, ZMK): This is the operating system of your keyboard. It’s the underlying C or C++ code that tells the microcontroller (like an RP2040 or nRF52840) how to scan the matrix of switches, debounce the electrical signals, process layers, and send USB or Bluetooth hid reports to your computer.
  • Graphical Configurator (VIA, Vial, ZMK Studio): This is a piece of software (often running in a web browser) that talks to the firmware on your keyboard. It allows you to change your keymap visually without writing code, recompiling, and reflashing the firmware.

[!IMPORTANT] A GUI tool cannot exist without a firmware engine underneath it. VIA and Vial are not standalone firmwares; they are graphical interfaces that talk to a specific implementation of QMK firmware running on your board.

2. Architecture Overview: How the Pieces Fit Together

To visualize this, let’s look at a simplified architecture diagram of the two main ecosystems in the custom keyboard world today.

graph TD
    subgraph Hardware ["Hardware Layer"]
        HW["Your Custom Keyboard (MCU: RP2040 / nRF52840 / ATmega)"]
    end

    subgraph FirmwareEngine ["Firmware Engine Layer"]
        QMK["QMK Ecosystem<br/>(C-based / Best for Wired / Huge Feature Set)"]
        ZMK["ZMK Ecosystem<br/>(Zephyr RTOS / Best for Wireless BLE)"]
    end

    subgraph Configurator ["Graphical Configurator Layer"]
        VIA["VIA<br/>(Web GUI / Basic Remaps)"]
        Vial["Vial<br/>(On-board Memory / Combos / Tap Dance / Settings)"]
        ZMKS["ZMK Studio<br/>(Emerging Real-Time Wireless GUI)"]
        GHA["GitHub Actions + Keymap Editor<br/>(Cloud Compile Workflow)"]
    end

    HW --> QMK
    HW --> ZMK
    QMK --> VIA
    QMK --> Vial
    ZMK --> ZMKS
    ZMK --> GHA

As you can see:

  1. You first choose a Firmware Engine based primarily on your hardware (Wired vs. Wireless).
  2. Then, you choose a Graphical Configurator (if you want one) that is compatible with your firmware engine.

Let’s dive deep into each component.

3. QMK Deep Dive: The Undisputed King of Wired Boards

QMK (Quantum Mechanical Keyboard) is the granddaddy of modern custom keyboard firmware. It is an open-source framework written in C, originally forked from TMK.

The Good

If your keyboard plugs in with a USB cable, it probably runs QMK. It supports an absolutely staggering array of microcontrollers, though historically it dominated on the ATmega32U4 and has recently seen a massive shift toward the powerful, inexpensive Raspberry Pi RP2040.

QMK’s biggest advantage is its feature set. Because it has been in development for so long, and because wired keyboards don’t have to worry about aggressive battery-saving sleep states, QMK can do almost anything you can imagine:

  • Tap Dance: Press a key once for ‘A’, twice rapidly for ‘B’, hold it for ‘Shift’.
  • Combos: Press ‘Q’ and ‘W’ simultaneously to output ‘Escape’.
  • Mouse Keys: Control your mouse cursor, scroll wheels, and clicks entirely from the keyboard.
  • Dynamic Macros: Record and playback macros on the fly.
  • Complex RGB: Insane reactive per-key RGB matrix animations.
  • OLED Displays: Draw custom graphics, bongo cats, or wpm counters on tiny screens.

[!TIP] To unlock the true, raw power of QMK, you write your keymap in C (keymap.c) and compile it yourself using the QMK CLI toolchain. This allows you to write custom functions, overrides, and logic that no GUI could ever support.

The Bad

QMK has one fatal flaw in the modern era: It has effectively zero support for Bluetooth/Wireless.

While there are some very old, very hacky implementations of Bluetooth in QMK, for all intents and purposes, if you want a wireless keyboard, you cannot use QMK.

Furthermore, setting up the QMK build environment on your local machine (installing MSYS2 on Windows, or configuring Homebrew on macOS) can be a massive headache for users who aren’t familiar with command-line tools.

Best For

QMK is the absolute best choice for wired split boards. My daily driver for heavy coding sessions is the Keebart Corne Choc Pro, a beautiful wired low-profile split running an RP2040. Because it’s wired, I use QMK to leverage aggressive Combos and Tap Dances without worrying about battery life.

4. ZMK Deep Dive: The Wireless Champion

As the community shifted toward wireless splits powered by nRF52840 chips (like the popular nice!nano microcontroller), a new hero emerged: ZMK.

The Good

ZMK is built on top of Zephyr RTOS (Real-Time Operating System). It was designed from day one with a focus on wireless connectivity and aggressive power management.

If you build a split keyboard with ZMK, it will act as a standard Bluetooth Low Energy (BLE) device. You can pair it to your laptop, phone, and tablet simultaneously, switching between them with a single keystroke.

Perhaps ZMK’s most brilliant innovation is its build system. Because setting up a Zephyr build environment locally is notoriously difficult, the ZMK ecosystem relies heavily on GitHub Actions. You fork a repository, edit a .keymap file (which uses a declarative syntax called Devicetree), commit the change, and GitHub’s servers compile the firmware for you in the cloud. A few minutes later, you download a .uf2 file and drag it onto your keyboard.

Here is a snippet of what a ZMK Devicetree keymap looks like:

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 FSLH
                  &mo 1  &kp SPACE         &kp RET &mo 2
>;

The Bad

Because it is newer and focused on power efficiency, ZMK lags behind QMK in raw features.

  • For a long time, ZMK didn’t have Mouse Keys (though this is finally rolling out in beta).
  • Advanced Tap Dance and custom macro logic is harder to implement than in QMK’s raw C.
  • RGB support is limited. Pushing continuous RGB animations over a wireless split keyboard will drain your battery in hours rather than months, so ZMK rightfully deprioritizes it.

Best For

ZMK is the undisputed king of wireless boards. I run ZMK on my Cornix LP, a beautifully engineered wireless split from OzoKeyboards. The ability to grab my keyboard, throw it in my bag, and type on my iPad at a coffee shop without messing with cables is incredible.

5. VIA: The Entry-Level Configurator

Now that we understand the underlying engines (QMK for wired, ZMK for wireless), let’s talk about the GUIs that sit on top of them, starting with VIA.

VIA is a graphical interface that talks to a QMK-powered keyboard.

How it Works

When a keyboard maker compiles the QMK firmware for a board, they can enable a flag (VIA_ENABLE = yes). This adds a special communication protocol to the firmware.

When you plug that keyboard in and go to usevia.app (which uses the WebHID API in Chrome/Edge), the web app detects your keyboard. You get a nice visual representation of your board. You click a key on the screen, select a new behavior, and instantly the keyboard updates. No compiling. No flashing.

The Limitations

VIA is fantastic for mass-market prebuilt customs (like Keychron or Wooting boards), but for advanced split keyboard users, it falls short.

  • Stateless Configuration: VIA does not save your layout to the keyboard’s permanent memory in a structured way. The keymap is there, but if you plug the board into a new computer and open VIA, it often has to redownload the layout definition.
  • Limited Features: VIA only supports basic QMK features. It struggles to configure advanced Combos, complex Tap Dances, or key overrides graphically. If you want those, you have to write them in raw C, which defeats the purpose of the GUI.

[!CAUTION] If you are building a highly customized 36-key split board where every key has 3 different functions via combos and tap-dances, standard VIA will likely frustrate you with its limitations.

6. Vial: The Power User’s Configurator

Enter Vial. Vial is an open-source fork of VIA that attempts to solve all of its shortcomings.

The Superior GUI

Like VIA, Vial requires specific support compiled into your QMK firmware (VIAL_ENABLE = yes). However, Vial fundamentally changes how the keyboard stores data.

Vial stores the entire configuration map, UI layout, and settings directly on the keyboard’s EEPROM/flash memory. This means you can configure your complex Tap Dances, Combos, Key Overrides, and even adjust the exact millisecond timings of your mod-taps entirely within the Vial GUI (desktop app or web app at vial.rocks).

When you unplug your keyboard, walk over to your friend’s house, plug it into their Linux machine, and open Vial, your entire complex configuration, layout, and settings load instantly from the board itself.

My Personal Verdict

For wired boards, Vial is the absolute gold standard. When I am dialing in a new layout on my Keebart Corne, I want to change a combo, test it for 5 minutes, realize it feels awkward, and change it back. Doing this via QMK source code requires compiling and flashing every single time. Doing it in Vial takes 3 seconds. It drastically reduces the friction of iterating on your ergonomic layout.

7. ZMK Studio: The Future of Wireless Configuration

So, Vial is amazing for QMK (wired). What about ZMK (wireless)? For a long time, if you used ZMK, you had no GUI. You had to edit text files in GitHub and wait 5 minutes for the cloud compiler to give you a new firmware file to flash.

ZMK Studio is the answer to this. It is an emerging, actively developed graphical configurator explicitly built for ZMK.

Current Status

ZMK Studio aims to bring the “Vial experience” to wireless keyboards. It allows for real-time keymap adjustments over WebUSB or Web Bluetooth without recompiling.

As of late 2026, ZMK Studio is still maturing. It handles basic keymap changes brilliantly, but configuring complex behaviors is still sometimes easier via the raw Devicetree files. However, its trajectory is clear: it will soon be the definitive way to configure wireless splits.

8. Decision Matrix: Feature Comparison

Let’s break this down into a hard comparison table so you can see exactly what supports what.

Feature / CapabilityQMK (Raw C)ZMK (Raw Code)VIA (GUI for QMK)Vial (GUI for QMK)ZMK Studio (GUI for ZMK)
Primary Use CaseWiredWireless (BLE)Wired Basic GUIWired Power GUIWireless GUI
Requires Compiling?Yes (Local)Yes (Cloud)NoNoNo
Wireless Support❌ No✅ Excellent❌ No❌ No✅ Yes
Advanced Combos✅ Yes✅ Yes⚠️ Limited✅ GUI Support⚠️ Maturing
Tap Dance Config✅ Yes✅ Yes❌ No✅ GUI Support⚠️ Maturing
Mouse Keys✅ Excellent✅ Yes (Beta)✅ Basic✅ Full✅ Basic
RGB Matrix✅ Advanced⚠️ Limited (Battery)✅ Basic✅ Advanced⚠️ Limited
Config Stored On-BoardN/A (Hardcoded)N/A (Hardcoded)⚠️ Layout only✅ Full UI & Config✅ Full UI & Config
Learning CurveHigh (C Code)Medium (Devicetree)LowLowLow

9. The Flowchart: Which Should You Choose?

graph TD
    Start([Choose Your Firmware Stack]) --> Conn{Connectivity Priority?}
    Conn -- Wired Desk Setup --> GUIWant{Want Real-Time GUI without Flashing?}
    GUIWant -- "Yes (Instant Combos & Settings)" --> VialOpt["Vial (Recommended on RP2040 / QMK)"]
    GUIWant -- "No (Hand-Crafted C Code)" --> QMKRaw["Pure QMK Firmware"]
    
    Conn -- "Wireless / BLE Multi-Device" --> ZMKOpt["ZMK Firmware (nRF52840 / Zephyr RTOS)"]
    ZMKOpt --> ZMKWorkflow{Configuration Workflow}
    ZMKWorkflow -- "Real-Time / Bluetooth" --> ZMKSGui["ZMK Studio (Where Supported)"]
    ZMKWorkflow -- "Repository-Based" --> NickC["GitHub Actions + Nick Coutsos Keymap Editor"]

Still not sure what you need? Follow this simple decision tree:

  1. Does your keyboard use Bluetooth/Wireless (battery powered)?

    • YES: You are using ZMK.
      • Want a GUI? Try to enable ZMK Studio.
      • Don’t mind text files? Use the GitHub Actions / Devicetree workflow.
    • NO (It’s wired only): You are using QMK. Proceed to step 2.

  2. Do you want to change keys instantly without compiling/flashing?

    • NO: Just use raw QMK in C. You have maximum control.
    • YES: You want a GUI. Proceed to step 3.

  3. Do you use advanced features like complex Combos, Tap Dances, or want your exact UI to load on any PC?

    • YES: You absolutely need Vial.
    • NO (Just basic key mapping): VIA is fine, though Vial is still strictly better.

10. Personal Experience: My Dual Setup

I write thousands of words and lines of code a week for The Peripheral Stack. I have settled on a dual-setup approach that perfectly illustrates the strengths of these platforms.

The Desktop Workhorse: Keebart Corne Choc Pro At my desk, where my PC never moves, I use the wired Keebart Corne Choc Pro. It runs Vial. Because it has 36 keys (a 3x5+3 layout), I rely heavily on Home Row Mods (Shift/Ctrl/Alt/GUI on my home row keys when held) and intricate Combos for symbols. Vial allows me to tweak the “tapping term” (how long a key must be held to register as a modifier instead of a letter) down to the exact millisecond in real-time. If I notice I’m accidentally firing ‘Shift’ when rolling my fingers over ‘A’ and ‘S’, I just open the Vial app, bump the tapping term up by 10ms, and keep typing. It’s magical.

The Mobile Warrior: Cornix LP When I travel or work from the living room, I use the Cornix LP. It’s fully wireless via nice!nano MCUs and runs ZMK. I have my ZMK GitHub repository set up perfectly. Yes, it takes 3 minutes to compile a new firmware when I want to change a key, but because my layout is already 95% finalized from my Vial tinkering on the wired board, I rarely need to make changes on the fly. The benefit of zero cables and 3-month battery life far outweighs the lack of a real-time GUI.

(Note: The Cornix actually supports a wired Vial build if you buy it with RP2040 microcontrollers instead of wireless ones, giving you the best of both worlds depending on your build choice!)

11. The Final Verdict

There is no single “best” firmware stack. The right choice depends entirely on your hardware and your tolerance for friction.

  • If you want wireless, you are in the ZMK ecosystem. It is robust, battery-efficient, and cloud-compiled.
  • If you have a wired board and want the ultimate tinkering experience, flash a Vial-compatible firmware immediately. It offers 99% of the power of raw QMK with 0% of the friction.
  • Only drop down to raw QMK in C if you are writing highly specific, custom logic (like drawing your own animations on an OLED screen or writing custom state machines).

Stop letting the acronyms intimidate you. Pick your hardware, pick the engine that supports it, and get to tweaking your perfect layout!

What firmware are you running on your daily driver? Have you braved raw QMK C code, or are you a dedicated Vial user? Let me know on Twitter @PeripheralStack.