Another day in Paradise – QMK
QMK is a TMK fork which is an open source firmware for Atmel AVR and Cortex-M controllers. This is how QMK started and it has evolved well beyond covering only a few keyboards produced by OLKB, ZSA and Clueboard.
Avoiding in-depth explanations which would only cover an introduction in the matter, QMK is an extremely customisable firmware for keyboards using supported controllers. Along with this customisation it has introduced the concept of layers. In practical terms a keyboard running QMK can have up to 32 layers (16 if you need more complex macros).
What is a layer exactly? A layer is a keyboard. An underlying layer is another keyboard with a potentially different layout and switching between layers is done through a remappable key – this can be a temporary access – available only as the key is depressed – or a permanent access which requires another keypress to return to the home layer.
An example of using layers is as follows:
- layer 0 = your home layer, the keyboard as it is;
- the key to access layer 1 is assigned to the Caps Lock key (which disables access to Caps Lock);
- on layer 0 you have WASD;
- on layer 1 on the same keys you have the arrow keys mapped;
- you press Caps Lock with the pinky and WASD turn into the arrow keys;
- neat, huh?
Thus you can have countless custom keybindings which can optimise the way you are using the keyboard, even one with much less keys than a full size, such as the 60% or even 40% keyboards.
QMK and its layers are the backbone of custom keyboards and QMK started spreading throughout the prebuilt world as well (Glorious GMMK Pro, some Keychrons). It offers fantastic flexibility and a level of customisation light years beyond any software written by prebuilt keyboard companies. And it is open source. And it does not have to constantly run an application on your computer, once you flashed the custom firmware this will remain the same for the keyboard regardless of the computer it is connected to.
Obviously everything is limited by the capabilities and local memory of the controller used which in turn needs to be supported by QMK. There are also QMK-alike firmwares out there such as ZMK which is oriented towards wireless keyboard builds. ZMK is not a fork of QMK despite the similarity in names.
At a certain point somebody got bored rewriting the keyboard firmware and thus VIA was born. VIA is a QMK front end and can handle a similarly generous number of layers with the added advantage of on-the-fly remapping and does not require reflashing the firmware for rebinding one key. VIA does not have to run in the background and writes directly in the keyboard flash. Unfortunately VIA is closed sourced but its developers are open to suggestions and really friendly. My personal project keyboard that I converted from membrane to mechanical runs QMK and is VIA compatible and it was 100% rebuilt at home with easy to source parts found online.
There is also a QMK fork called VIAL which is similar to VIA but is Open Source and is oriented towards keyboards using encoders in their build. Yes, we have fully programmable encoders, which can be configured to do so much more than just audio volume control.
And the communities surrounding these firmware forks are full of beautiful people who are more than happy to help new users by following the principle “there are no stupid questions”. We shall see how long that lasts.
Therefore we can conclude that the mystery of the mini-keyboards – the “remote control keyboards” – has been thoroughly explained. People using these are very happy with them and Callum Oakley – a software developer – uses a Planck keyboard with a 40% COLEMAK layout. I invite you to read his article – 48 keys are plenty – which is a crash course on the potential that QMK brings to the table. What we need to learn from this story is that the size and number of keys of a keyboard are just a preference, nothing more and nothing less.