komokana VS ErgoDox

kanata[1] and komokana[2].

kanata is basically like QMK for any keyboard without the firmware requirement. I use kanata with my trusty old iMac keyboard which is to this day my favourite keyboard of all time. But now I have all the cool QMK-style layers with it.

So that is awesome on its own, but where it gets even better for me, and this is where the seconds have really added up to hours, is that I wrote another piece of software which programmatically changes layers on kanata whenever a different window is focused in my tiling window manager.

This has honestly changed -everything- for me. I no longer have to waste keys on my keyboard to switch layers, I no longer have to -think- about switching layers, I just focus another window with alt+hjkl and whatever keyboard layer I expect for any given application is automatically applied. Definitely one of those "you can never go back" experiences for me.

[1]: https://github.com/jtroo/kanata

[2]: https://github.com/LGUG2Z/komokana

I have an Ergodox EZ sitting collecting dust these days. I got a great deal of use out of it and before long I was compiling my own firmware and making use of various advanced QMK features that were not available through the online visual layer configuration tool.

The keyboard has great build quality, the customer service is great (I got a free replacement for the right half after an issue with one of the keys), the ortholinear layout isn't that difficult to get used to, but ultimately the issue for me was that my hands aren't big enough to use the keyboard comfortably or to type as accurately as I'd like / as I'm used to typing.

I'm now back on my Apple Magic Keyboard and happier than ever, though with a few tweaks and improvements taken from my time using the Ergodox EZ.

I am now using kanata[1] which allows me to have multiple QMK-style layers on my regular old keyboard. This is already a huge step up from my pre-Ergodox days! I also like that I can have my layer configurations version controlled in a plain old git/dotfiles repo.

Since the layers are handled at the software level, I wrote my own integration with kanata, called komokana[2] to switch keyboard layers programmatically based on different state events emitted from my tiling window manager[3].

What that means in practice is that my keyboard can automatically switch to an app-specific layer when that app's window is focused, or to a workspace specific layer, or to a browser tab-specific layer, or really just switch on any event emitted by the window manager or any specific window manager state.

For me, this is really the killer feature of my setup now, and one that I don't think would be anywhere near as easy to implement with QMK which sits at the hardware level.

[1]: https://github.com/jtroo/kanata

[2]: https://github.com/LGUG2Z/komokana

[3]: https://github.com/LGUG2Z/komorebi

Hello friends! You may know me from my previous posts about my tiling window manager and my automatic keyboard layer switcher (or maybe even my harebrained attempts to get Helix to behave more like Vim!)

With all of these pieces now in place, I am very happy to introduce komokana. an automatic application-aware keyboard layer switcher for Windows.

https://www.ergodox.io/, been around forever now.

Closest split PCB based design with a Kinesis Advantage thumb cluster, I know of, is the Ergodox Would need tenting to emulate the keywells. Lovingly design and print a case with tenting legs for it? 🤔

Should be in here somewhere: https://github.com/Ergodox-io/ErgoDox

> Is ZSA's build known to have latency issues compared to QMK?

ZSA is using a patched QMK - they even let you download the exact source for each firmware build they make for you. At the time when I switched to vanilla QMK (that was already some years ago), ZSA were veeery far behind master; running the latest QMK release fixed a couple of issues for me (like hotplugging the halves), so I guess there could be other improvements? No idea really.

> Would a faster microprocessor help

In the MCU world, latency and clock speed can have a very linear relationship - until they suddenly don't. The microcontroller's job is very simple really: scan the key matrix at a certain frequency, perform key debouncing, compare the current state with the previous, and craft a USB HID packet with key press/release events.

So having twice the clock speed could theoretically let you scan twice as often, so it might let you cut the latency in half. Except we have those pesky physics getting in our way! For simplicity let's assume we don't have split halves (where there's an extra serial connection slowing things down); I'm no EE so I only grasp these concepts at the surface level, but signals take time to propagate, and long traces on the PCB (and cables too) have a tiny bit of their own capacitance. (Capacitors are like really fast, really tiny batteries - but they still take a tiny amount of time to charge and discharge, which does all sorts of interesting things to high-frequency signals.)

On top of that, the electrical connection that the pieces of metal are making inside the switch, are never perfect at the exact instant the switch is supposed to (de)register: a couple electrons might start jumping over the air even before contact is made, and the physical connection is subject to normal wear, amplifying the "edge case" effect over its lifetime - which all together means we have to actually spend a certain amount of time "looking" at the state of the switch, to let it settle and make sure we got it right.

We end up spending so much time letting physics do its job that in a trivial firmware, the MCU is actually spending a significant amount of time... just sleeping. Which means we were later able to cram all sorts of madness like individual RGB lightning or status displays, and never decreased the poll rate.

Where would these 40ms come from then? Well I wouldn't get near the problem without an oscilloscope, and unfortunately I don't have one.

> I'm just starting to get into custom keyboards.

Then I recommend studying the original ErgoDox firmware & build instructions! It's extremely straightforward compared to a beast like QMK, which actually uses a whole RTOS.

https://www.ergodox.io/; https://github.com/benblazak/ergodox-firmware

Hi! Does anyone here have some experience playing age on an ergodox? I usually move the right part out of the way so that I can have more space for the mouse (it is actually great for things like FPS because the mouse hand is in a very natural position), but the default hotkeys force me to move my left hand across both sides, making it hard to actually hit the key without looking. I've been only using control groups 1-5 due to this, which is less than optimal.

The closest open source keyboard you'll get next to the Moonlander is probably the ErgoDox that it's heavily inspired from.