[~] BACK

~~ KYB3R_KEYS ~~

** A DIY KEYBOARD LAYOUT **

[HOW] | [20231107] | [20231120] | [0x17]

VERSION: 0.4 | 2023-11-16 [CHANGELOG]

A few years ago I was looking for a new keyboard and then fell into a hole that hasn't let go of me to this day and still fascinates me with its ever-new topics and the variety that opens up. I've built and tried out a few keyboards and can say for myself that I like the CRKBD (Corne) the best so far. When you're in this hobby you eventually get to the point where the default QWERTY layout is no longer really useful and that's exactly where I am now. So I'm trying my hand at my custom layout, which is completely tailored to my use case. So I have a (hopefully) perfect layout and maybe one of you has a similar workflow or it will help you design your layout.
If you have the layout on your keyboard, a default US keyboard layout on the computer is enough so that all the keys do what they're supposed to. If you want the German umlauts Ä, Ö, Ü and ß, I recommend the EurKey Layout. Here the keymap remains the same, but you also have the option of generating umlauts using ALT-GR.

0x01 - REQUIREMENTS

Before we get down to business, the parameters according to which the layout is to be built must be defined. Let's start with the simplest - which keyboard should be used. I use the above-mentioned CRKBD / CORNE with 3x6 +3 keys as a daily driver. The CRKBD has 3x5 keys as the main cluster (i.e. the block on which the alpha keys are located), i.e. three rows and five columns. On each of the outer sides there is a column for modifier keys such as ESC, CTRL, ALT, etc. There are also three keys for the thumbs, but these only have a secondary connection to the KYB3R KEYS, but more on that later. The whole thing looks like this in the hardware version:



The next consideration should be the use case of the keyboard or the layout. I've recently taken a look at what I type on my keyboard. Basically, I can say that it's mainly about code and flowing text. Now I often say here on the $NB that I prefer to use terminal tools than GUI tools. Since I now use aliases for most tools, I would count the terminal commands as flowing text. Terminal options that are not yet built into an alias can still be found quite quickly. When looking at daily use, the use of code to flowing text is distributed in a ratio of 30% code to 70% flowing text. The code that I build is mostly Python, Nix, Vimscript, Bash and Markdown. The special characters used here behave relatively similarly. I will analyze the use of the special characters again at a later date, when the basic structure of the layout is in place. What I cannot (and do not want to) completely ignore is the use of XMonad as WM. It needs the GUI key in my config for control - but more on that later.




For the body text, I switch between German and English. The distribution here is 60% English and 40% German. The reason for this is that it is relatively convenient to have umlauts like Ü, A, Ö ready to hand, as they occur relatively frequently. Since the body text takes up the largest part here, I will primarily focus on this. This results in a priority list of 1. DE text, 2. EN text, 3. code. The next step I took was to compare the first two priorities.

0x02 - COMPARISON DE | EN

What is the best way to compare two languages? Let's break it down to what is identical in both languages. The characters used and their frequency. I saved myself the work of doing this research and analysis myself. Many people have done exactly that before me and I simply use their results. What I compared in order to get a reasonably valid result are the characters that are the same in both languages. So I ignored the umlauts in German and only compared the remaining keys. The general grapheme frequency, i.e. how often each letter is used, is distributed across both languages ​​as follows:



At first glance, it is clear that some keys are used with similar frequency. This could be because the origins of both languages ​​are very similar. If we put both languages ​​directly next to each other, we can see the differences and similarities. If we look at the structure of the keyboard, we have the 3x5 alpha key cluster per side mentioned above. The middle row of keys is called the home row. This is where your fingers rest when they are not typing. Since this row is the basis of the layout, I took the 10 (or 12) most common letters and reserved them for the home row.




The home row, however, only has 10 keys. The diff in the comparison of the two languages ​​quickly turns the most common 10 keys into 12 keys. The two languages ​​differ in O/D and L/U. As I said, I am orienting myself on English and treating German as secondary. The distribution of the keys here is from the inside to the outside. Basically, I would assume that the index finger is simply the strongest and that we can place different loads on it than, for example, the little finger. I move the two keys that result from the diff one row further down, but also to the position of the index finger. This results in the following layout basis:



Now we don't just type pure letter sequences, there are also bigrams and trigrams that are typed frequently. I'm ignoring the trigrams for now. Maybe I'll look at them when I have an established, solid basic layout. So, on to the bigrams. Bigrams are character sequences that repeat regularly. In a comparison of English and German, the 10 most common bigrams are as follows:



Unfortunately, there are hardly any duplicates between EN and DE. What I did to condense it down a bit was to look at which bigrams use the same characters, but in a different order. For example, ER | RE or IE | EI. Then I sorted everything by frequency, with a focus on EN. This results in a final list of bigrams that is broken down as follows:



This of course influences how the keys are distributed in the alpha layout. Basically, it is easier on the hands and fingers if the characters of the bigrams are distributed between both hands. Here, of course, the general key frequency and the diff between home row and secondary keys are taken into account. After a bit of brain-bending and a lot of Club Mate, it worked.

We continue with the distribution of the remaining keys. These differ more clearly than the first ten keys. Instead of two diffs, we only have two matches here. But here too, I would distribute the keys used, the less used, the further outwards. This protects the weaker fingers and evens out the strain through the additional use of the modifier keys on the outside.


I was recommended another tool (LINK) by the wonderful community mentioned above, which highlights the keys used in color according to frequency and also analyzes the bigrams and trigrams. By default, the tool does this with an English text body. I'll take a look at it and maybe add a German one. The whole thing then looks like this for the KYB3R_KEYS layout:

0x03 - MODIFIER (THUMBCLUSTER)

Of course, it doesn't work without the modifiers. Let's start with the thumb cluster. The three keys per side that are intended for the thumb. Many people see it differently, but I think it's great: SPACE on the left side and ENTER on the right side, and that on the inner keys. In my case, that's particularly useful for terminal stuff. The middle keys are SHIFT on the left side and BACKSPACE on the right side. The two outer keys are ALT on the left and ALT GR on the right.




Then there are the modifiers on the left and right. The modifiers that are operated by the little fingers. Here I am basing myself on VIM and XMonad. So on the left side from top to bottom there is TAB, ESC and LGUI. Since ESC is used quite frequently in VIM, it moves to the middle here so that the upward movement of the little finger is reduced. LGUI below is the mod key for XMonad. This is used in XMonad to start new terminal instances, change workspaces, move tools between workspaces and so on. The downward movement of the little finger is a little gentler than the upward movement, hence the position. But not only the LGUI key is important here, but also combos of LGUI with LSHFT or ALT. The whole thing is recorded hierarchically in my xmonad.hs:




On the right side, the mods are from top to bottom DEL, CTRL and RSHIFT. DEL ended up in this position because the muscle memory does not need to be retrained here. CTRL is again in the middle to keep the little finger's path short, since CTRL is also used quite often. RSHIFT is on the left side as a redundancy to LSHIFT.

0x04 - LAYER

This gives us the actual base layout. However, a 3x5 alpha key cluster is too small to display characters such as numbers, special characters and brackets. This is where different layers come into play. Layers are levels that can be switched to at the touch of a button in order to assign the keys a different mapping during operation. I have three additional layers to the actual base layer. Firstly, the SYM-LAYER, a NAV-LAYER, a NUM-LAYER and an F-KEY LAYER.

Layer 1 is the SYM-LAYER. This takes care of brackets, commas, semicolons and similar code-relevant special characters. Up to ver. 0.3 I had a symmetrical distribution of the keys. All keys are located on the left side and are activated by pressing+holding the left key in the thumb cluster on the right side.

I posted the KYB3R_KEYS in the CCH! Discord. The idea of ​​arranging the symbols symmetrically on the left side was met with - let's say - mixed feelings. In the process, I took another look at the sym layer. The analysis of the symbols is just as feasible as the analysis of the alpha keys. Since a very small proportion of special characters are used in continuous text, I don't think continuous text is representative of symbols. The symbols here mainly refer to code, so let's also use code for the analysis. A wonderful overview of the most commonly used code languages ​​can be found on STATISTA.COM. The most commonly used languages ​​here are C / C++, PYTHON, HTML / CSS, BASH, RUST, HASKELL and GO. If you go to STATISTA yourself, you will see that the selection there differs slightly from what I am using here. The reason for this is that I have nothing to do with JAVA myself and would rather throw HASKELL and BASH into the mix. So it does not 100% represent the most commonly used code languages, but varies. I have set the following two parameters:

[-] Code from different projects to represent different coding styles
[-] At least 6000 lines of code

So I searched through Github, Gitlab and Codeberg and was able to generate the following measurement data for the individual languages:



These parameters are the result of pure code copy-paste and a simple grep -c "." testat (in this case, the frequency of the dot is determined). I simply threw the grep commands for the individual symbols into a small Bash script so that I don't have to do it by hand. This way I can generate the result directly so that it is compatible with LibreOffice. However, there are a few special features with grep that must be observed. Anomalies occur in the character analysis. This is clearly noticeable if we look at the frequency of $ and ^. These occur with a noticeable frequency. At this point, a big thank you to PUROX. PUROX not only gave me the tip about grep, but also pointed out to me that the characters in question can also be EOL symbols and therefore probably appear more often than average. You can see this quite clearly in the results:



Listed here you can see the symbol distribution for the individual languages, sorted in ascending order of frequency. Now there are two ways to integrate the whole thing into KYB3R_KEYS. Either I build a version that is optimized for the sum of all languages ​​or I build language-specific versions. The simplest is of course the variant from the sum of all languages. The overall distribution across all 7 languages, also sorted in ascending order of frequency, looks as follows:



Visually a little spruced up, the overall distribution looks like this. As already mentioned, we can safely ignore the characters $ and ^ here, since on the one hand they mark EOL and on the other hand they are not on the actual SYM-LAYER.



When distributing the symbols to the keys on the left side, I follow the procedure for the alpha keys. I again start with the index finger as the strongest finger and the strength of the fingers decreases towards the outside. Here, too, the home row in the middle of the keys serves as the basis. The distribution is as follows:



As with the other layers, this distribution is also a mixture of statistics and gut feeling.
I thought for a long time about whether or not I should build language-specific sym layers. In the end, I decided against it. In most cases, it is not just that people only code C/C++ or only Haskell and so on. Most of the time, for example, Bash scripts are part of the daily routine and that would be a hindrance to using a layout tailored to another language. That's why I take the average and make it the default in the keymap.c. However, I'm still leaving the symmetrical distribution in the design as a commented-out version. That way you can test it yourself and decide which one you like better.

The second layer is the NAV-LAYER. This takes care of navigation. In my case, that means Vimkeys. Switching to the NAV-LAYER is done with the right key in the left thumb cluster and also with press+hold. This prevents unnatural finger movements. The thumb on the left side triggers the layer key and the right hand can operate the NAV-LAYER.




Layer number three is the NUM-LAYER. This takes care of the numbers and also the special characters that are on the number keys in a default QWERTY layout. You switch using the middle thumb key on the right-hand side. The remaining keys remain empty. Here, too, you switch to the layer using press+hold.



When I showed my layout (still in a totally alpha version) to people, Frank (Telebrot)) noticed that there are no F-keys at all. So the keys are F1 to F12. We talked briefly about what he uses the keys for. I only use F3 myself and I mapped it to this key and it opens NERDtree in VIM. Frank's use case for the F-keys: renaming files, website reloading and biosentry. Since KYB3R_KEYS is optimized for the terminal (and terminal tools), I don't have to rename files or reload. I use a tool called VIMV for bulk renaming - I'll have to write something about that here too. I do the reload in the browser (qutebrownser) using :reload. This would make most of the F-key assignments obsolete. If it weren't for the 1% BIOS entry. That is indeed a valid point. That is why KYB3R_KEYS gets an F-key layer. It is of course optional and if you don't need it, throw it out. The F-keys are distributed across the top row from left to right. Of course, we only have 10 keys available here, so F11 and F12 are moved to the home row. The layer is activated by pressing + holding the TAB key in the left mod column. I spent a long time trying out where to put the layer switch. Originally I wanted to put it on the middle key of the left thumb cluster. Unfortunately, LSHFT is already there. As Shift is known to be used via long press + letter, changing the layer via press + hold is not possible here. I also asked in the CCH! Discord what the others were using and got lots of options with which it could also be done. Unfortunately, the options didn't work so well for me, so I decided to put the layer switch on TAB. Nevertheless, a huge thank you to the wonderfully fluffy community.




When all keys, layers and modifiers are distributed, the whole thing results in a wonderful layout that (hopefully) saves a lot of work, time and pain. Whether that is really the case remains to be seen. I am currently testing the whole thing extensively. If there are any changes, I will add them to this post. But for now, this is my entire layout:

0x05 - TESTING

The theory and software are in place. Now it's all about testing the whole thing in Meatspcae and, above all, checking whether the whole thing performs as it should. There are various ways to test the whole thing. There are tools that do most of the work for you. But before I get to the tools, let's take a look at the most important thing - your own feeling. Someone once wrote in the CCH! Discord that it doesn't matter how many WPM you achieve on a keyboard, even with 10 WPM you quickly notice whether a layout is running smoothly or whether there is a problem somewhere. In this first step of testing, KYB3R_KEYS feels completely smooth (later changes are not excluded). Then it's time for the tools that provide you with valuable metrics. First of all, there is of course MONKEYTYPE. There are various options here for determining your typing speed and your words per minute (WPM). Don't despair if your WPM is low at first, that's normal for new layouts.

0x06 - FIRMWARE

Of course, the whole thing still has to be put into software. As on all my boards, we implement the whole thing in QMK, because QMK is good! Yes, there is also VIAL - I know - but somehow I like the old-school hand-compiled QMK. The QMK offers a nice command:

TERMINAL

This creates a completely empty keymap (in this case for the CRKBD). All you have to do is enter the keycodes for the KYB3R_KEYS layout. The keycodes can be found in the QMK documentation (HERE). I'll spare you the finished keymap file at this point. You can look at it yourself in keymap.c. I've also linked the finished keymap (including the fully compiled files ready for flashing) here, so you don't have to build everything yourself by hand. When everything is ready, the firmware still has to be installed on the CRKBD. To do this, connect the board to the computer and press the reset button. The CRKBD should now be recognized by the QMK and is ready to flash KYB3R_KEYS.

TERMINAL

Once everything has gone through, KYB3R_KEYS should be on your CRKBD and you can get started. I'll also include a cheat sheet with all the layers. It helps me a lot when learning and getting used to it.

0x07 - FAZIT

It takes some effort to think about your own layout and it is not a project that can be completed. Something always changes. BUT! It is worth it and is fun to deal with your own typing behavior. Now KYB3R_KEYS is geared towards a very specific use case: A mixture of CODE/TEXT and EN/DE, plus a lot of terminal use and VIM/VIM-like centered. There will certainly be other people who have the same use case, but it will not be the majority. I am aware of that.

0x08 - FILES

Of course you now want the files that I have made palatable to you. Here you go:

[KYB3R_KEYS CHEATSHEET]: LINK
[KYB3R_KEYS keymap.c]: LINK
[KYB3R_KEYS kyb3r_keys.hex]: LINK


Have fun with it!

I get quite a lot of input. That's why I'd like to say an explicit thank you to everyone who provides input:

THX

LINKS

EDIT

CHANGE LOG