I mostly talk about software here, but I think I want to stray away a bit from the regular path and talk about keyboards. I’m a really passionate keyboard guy, having built three 60% bamboo ones, bought a ZSA Voyager last year, and lately made my own Corne by soldering everything. It was a wild experience — and I did broke some tracks; RIP LEDs 😥 — but overall I’m really satisfied with the end result.

I want to talk about it, because it’s not really the type of keyboard you see quite often, and I guess it comes with many questions.

# The Corne, a 42-key beauty

The first thing you might have noticed is that it’s a split keyboard. There are a lot of litterature lying around explaining why it’s actually a better setup than a single piece of hardware — better shoulds position, better wrists alignment, etc. Plus, because you have the choice to put both sides close to each other, or far apart, it can easily be adapted to your morphology.

Secondly, it’s easy to see that the Corne has only 42 keys. That comes with a massive advantage to me: when your fingers are resting on the home row, every key on the main grid (i.e. excluding thumb keys) are only one key away. That minimizes a lot the movements you will be doing. For instance, reaching the key on the top-left corner doesn’t require any kind of stretch of my hand, nor rotation. It’s already an improvement compared to the Voyager, which has an additional row above; reaching its top-left key does either make you extend your pinky in a non-natural way, or does make your wrist slightly rotate towards the keyboard, which is not comfortable on the long run.

So every key is reachable by just slightly moving the fingers. It’s a fantastic feeling, especially because of the column staggered keys, which follows the curve of the hands. I’ve been touch typing for a very long time now (> 10 years), so switching to that keyboard wasn’t that hard — especially because I had switched to the Voyager prior to this — but it would a lie to tell it’s natural. It takes some time and practice. If you have never learned to touch type properly, you might suffer a lot. I’ve been touch typing in bépo, so it took me a couple days to be fully comfortable with the Voyager and the Corne.

Finally, I want to talk about the thumb keys, because it’s going to be a central topic of this article. The Corne has three on each side, for a total of six, which is still two more than the Voyager, which has two on each side for a total of four. Thumb keys are a way to leverage the fact that on regular keyboards, we barely use them — on my 60%, I used the left thumb for the space bar, and the right thumb for alt-gr, but that’s pretty much it, besides some occasional modifiers.

So that’s it for the introduction. Let’s dig into my setup.

# Layers and mod-tap

Because of the few amount of keys, the whole idea is that you want to create layers, and dedicate some keys to activate modifiers and layers. Let me explain.

# The base layer

The base layer is usually full of letters, what you will be typing the most. In my case, this is my base layer — · means that nothing is bound there:

T b é p o è      ^ v d l j z
E a u i e ,      c t s r n m
% à y x . k      ' q g h f w
      1 Z ·      B R ·

Here, T stands for tab, E is escape, Z is space, S is left shift, B is a backspace, R is return. Some keys have a hold action, which is what we usually call mod-tap: holding the key down and pressing another key does something different. Even though some keys do not have any tap action (for instance, the left inner thumb key or the right outer thumb key), I can still hold them to have a specific action. Here’s the base layer again, but with the actions when keys are held:

M · · · · ·      A · · · · ·
· · · · · ·      · · · · · ·
A C · · · ·      · · · · · ·
      2 · S      S 1 G

M is meta, A is alt, C is control, S is shift, and G is alt-gr. That latter modifier is especially important in bépo, as it opens up many many characters that the bépo layout has to offer — for instance, … is alt-gr + ., ’ is alt-gr +, œ is alt-gr + o, etc.

The 1 and 2 are not typos, and I’ll talk about it pretty soon.

You might have noticed that I have mirrored the shifts on the inner thumb keys. This is important to me, because shift is actually a very important modifier: it’s by far the modifier I type the most, and I need to be able to interleave normal typing on the main grid with shifting modifiers. Think about the sentences you’re currently reading, and where I might have pressed shift. « I » in the middle of a sentence requires a shifted « i ». Every start of sentence requires a shifted letter.

Now let’s see how I type numbers and symbols.

# The symbols and numbers layer

I used to have this layer mirrored on the outer thumb keys, but such keys are not really practical to hit while fast typing — I usually type around 145 words per minute, so I’m pretty fast. Today, that layer is accessed via the 1 layer key on my base layer — middle right thumb key. If I just tap it — basically press and release without touching any other key — it acts as return. If I hold it, it activates the symbols and numbers layer.

Let’s see that layer:

0 1 2 3 4 5      6 7 8 9 ° ·
$ " < ( ) >      @ + - / * =
# | & [ ] ~      — { } « » ç
      · _ S      · □ ·

The □ is the held key there. So, if I want to type (), I can simply hold the right middle thumb key and press ie to yield (). How to do ->? Easy: press the layer key, and s,. The placement of the keys are easy to remember.

One that is very important to me is _: that one is usually accessed via alt-gr + <space>, but because my alt-gr is on the right outer thumb key, it’s not super practical to type. However, I also realize I don’t type underscore that often, and that I might put backspace there instead. This is still something I’m figuring out.

This is a pretty fantastic layer, because everything is really easy to activate. The weirdest key is definitely —, since the right index and thumb fingers are super close to each other — but it’s a fair tradeoff as I very rarely type this key, but still require it.

The ç is an anomaly due to bépo v1.0, which doesn’t treat alt-gr + c as ç, but as ©, which I do not really care. I need to switch to bépo v1.1 / AFNOR, which comes with issues with ' vs. ’; yes, French is hard!

You can see that I moved 0 on the left side; this is to prevent having to press it on the right side with a weird crab hand; 9 is fine, but 0 would be too weird on the right side.

# The nav/multimedia layer

Next up is my navigation layer, accessible with the 2 key.

That layer is important for many different softwares, including shells, chat applications, etc. It’s the layer that holds arrow keys, page up / down, home / end, etc. Because it’s also a pretty empty layer, I hijack it to also hold useful multimedia keys, such as volume up, down, mute, and the print key:

3 · · · · VU      P H U E · ·
· · · · · VD      l d u r · ·
· · · · · VM      · · D · · ·
      · · ·       S · ·

3 is my gaming layer goto-key (more on that later), VU, VD and VM are volume up, volume down and volume mute; P is the print key, H and E are home and end keys, U and D are page up / down, and l, d, u and r are the left, down, up and right arrow keys.

Yes, the volume keys are not optimally placed, and I might move them on the right side eventually. The reason is that since the nav key is pressed on the left outer thumb key, and is not practical to type keys on the left side of the keyboard.

Alright, now let’s see the last layer I have defined:

# The gaming layer

The gaming layere is a bit weird and heavily optimized towards the games I play — mostly, Quake, or games with a need of special keys all around my movement keys:

T è b é p o      · · · · · 0
E , a u i e      · · · · · ·
%   à y x .      · · · · · ·
      k Z S      · · ·

0 here goes back to the base layer. As you can see, the layout is weird, but the idea is that it will make most games work out of the box with ASDF key, but I shift them by 1 column to have the direction keys right under the fingers without moving from the left home row. I don’t think there’s anything to debate here, it’s just a shifted base layer.

# Home-Row-Mods: a false good idea?

Something that I wondered a lot is whether I want to use HRMs. HRMs assigns hold-actions on the four keys of the resting home row position to control, alt, shift and meta, on each side of the keyboard. That allows to have access to modifiers without moving your fingers. This, basically:

· · · · · ·      · · · · · ·
· M A C S ·      · S C A M ·
· · · · · ·      · · · · · ·
      · · ·      · · ·

I is smart, but not practical, at least not to me. The idea is that it relies heavily on how it’s implemented. I use QMK to build my firmwares, and when you use HRMs, there is a setting you cannot really do without: permissive-hold. In short, permissive-hold changes the behiavor of mod-tap keys in order to active the hold action more often. By default, to get the hold action of a key, you have to press it for more than TAPPING_TERM — usually set to 200ms. With permissive-hold, the hold action can be triggered sooner by pressing the mod-tap key and pressing and releasing an other key, while still holding the mod-tap key. Imagine a mod-tap key that prints t if tapped, but right shift if held. With permissive-hold, you can trigger the hold action without having to wait for TAPPING_TERM:

  1. Press down the t key.
  2. Press down the a key for instance.
  3. Release the a key.
  4. You get A printed.
  5. Release the t key.

This is required if you want to use HRMs and still trigger hold actions without having to wait for TAPPING_TERM. The other mode — which I use, and I’ll explain why — is named hold-on-other-key-presses, which changes the behavior of mod-tap keys like so:

  1. Press down the t key.
  2. Press down the a key.
  3. A is printed.
  4. Release the t key.
  5. Release the a key.

This is usually how I type when typing fast, so that mode is really horrible as it generates tons of misfires with HRMs. However, it’s the mode to use for mod-taps set on keys you rarely use doing rollovers, such as my backspace key which is also my right shift: I usually tap it once or twice, without holding on any other key. Whenever I press it and hit another key, 100% of the time, I wanted a shifted key.

So having the shifts on the thumbs and hold-on-other-key-presses allows me to shift keys immediately, which is really important while shifting keys in the middle of sentence or words.

But there’s more. I really tried HRMs — switched to permissive-hold, and removed the shifts from the thumbs. I basically have two big issues with it.

# First issue: shifts are too important

Because shifts are really special and important keys, having them on the home row just gets in the way too much. You don’t realize it until you have to type complex sentences with tons of shifting, but I realized that I often start shifting a character, and my fingers are already moving to the next digram or trigram. Having two fingers forced to ping-pong between shifts, and because you cannot press them quickly (remember: permissive-hold requires you to press a key, and press and release another key before releasing that first key first to get she hold action! this is not how I fast touch type, so I really feel slowed down with this setup).

This issue also outlines a misconception — or a paradox, pick the word that pleases you the most there — about symmetrical shifts. Whenever I need to shift a single character, I will pick the shift key on the opposite hand. For instance, « I » is an i, which I type on the left side on the keyboard, and thus I shift it mith the right middle thumb key held: « I ». However, some words sometimes require to shift a couple keys one after the other. For instance, there’s a city in France called Anet. Let’s yell at that city, for whatever reason: ANET!

The way I type ANET is by following the opposite-hand rule I mentioned above for the first letter, but then I just keep the shift key held and finish the rest of the word. It looks like this:

  1. Press the right middle thumb key.
  2. Press a.
  3. Press n.
  4. Press e.
  5. Press t.

Now, with HRMs, you cannot do that, because every letter of anet alternates between sides, this is what it would look like:

  1. Press t.
  2. Press a.
  3. Release a.
  4. Release t.
  5. Press e.
  6. Press n.
  7. Release n.
  8. Release e.
  9. Press t.
  10. Press e.
  11. Release e.
  12. Release t.
  13. Press e.
  14. Press t.
  15. Release t.
  16. Release e.

Yeah. It’s crazy. And here, I really took the worst example, but in practice, that kind of alternating pattern happens more often than you’d think. For this special reason, I think shifts should be treated as a special key, and that HRMs should not include shifts.

# Second issue: latency

So this one is probably the most infamous one coming with HRMs, and either you just don’t care, or you’re like me and can’t stand it. I’ve heard and read people stating they do not feel it, but on my side, it’s very similar as playing at 30 FPS vs. playing at 244 FPS: I just do not comprehend how someone cannot feel the difference.

What happens with HRMs introducing latency is easy to understand, and it’s about the taps, not the hold action. With permissive-hold, as seen above, if you press and release another key while holding down a mod-tap key, you will get the hold action. If you fast type, and have the interleaving of press / release, you will get taps, which is fine, but. Because they mod-tap key might be a shift key if hold, the firmware must wait until the end of the tapping period, or that the key is released to actually consider it a tap. What it means if that, if you press a key and release it, the associated character will not immediately appear on screen: it will take the time between the moment you press the key and the moment you release it. The character will be printed on screen when you release the key.

You can state that the difference in time between a press and the associated release is negligeable for taps, right? Right? Well, not really. Even when I type really fast, I cannot easily go under 60ms on single taps, and rarely under 40ms for super fast burts.

A simple and KISS way to check this out: open your web browser console, and add this JavaScript to any page:

document.onkeypress = () => { down = window.performance.now(); }
document.onkeyup = () => { console.log(window.performance.now() - down); }

Yeah it’s terrible code but who cares for such a test. Just simply tap a single key the way you normally type. This is just there to show you that with HRMs, you will get most of the time around 60ms of latency if you are a fast typer, probably much more for most of the people.

Just for comparison, for a game to run at 30 FPS, it must compute every frame with a maximum render time boundary of 1/30 ~= 33ms. If a game were taking 70ms to render each frame, it would run at 14 FPS. So this is akin to playing a game at full FPS, like 240 FPS, but having your mouse and keyboard input at 14 Hz. I don’t think you’d like that. So yes, HRMs introduce a very noticeable lag, and I cannot bear it. It feels terrible. Something that people also seem to ignore is that the human brain is pretty good at making correlation between a sensation and what they eyes see. For instance, if you have ever watched a movie with out-of-sync video and audio, you might have realized how quickly you can notice that something is wrong: just having a couple milliseconds of delay between what you see and what you hear already feels bad.

Fun fact: because the speed of light is the top-speed, and the speed of sound is pretty slow compared to light, desynchronizing audio and video will not feed as bad if the audio arrives after the video; think thunderstrucks for instance. But your brain will freak out if audio arrives before.

Contrary to what many people will say, this is an unsolvable problem. There are some options to try to mitigate the problem — for instance, Flow Tap — but those still introduce tradeoffs that are not good ones to me. Flow Tap introduces a timeout after which tapping a key will disable HRMs, so you can speed through without having the latency. However, it doesn’t solve the problem in all situations, and I still think that permissive-hold is not as good as hold-on-other-key-presses on keys you don’t often use.

# What’s next

I’m considering changing a bit my layers, especially regarding backspace, return, etc. All in all, I think that having so few keys does require some tradeoffs, and I think I’ve found the perfect setup for my personal use. Who knows, maybe some day I will find a revolutionary way to implement HRM and will switch to them, but for now, I don’t think it’s actually that good.

It was a lighter topic, but still pretty fun to talk about it. In the end, I just love keyboards.

Keep the vibes!

↑ My Corne keyboard
corne, crkbd, mechanical-keyboards, hrm, qmk
Tue Jun 17 15:50:00 2025 UTC