Sasa!
With great powers come great responsibility, said a wise man once. Last time I left you with a fully assembled (and working too!) split keyboard. In these weeks I had enough time to play with QMK and keymaps, and with the huge power of customizing its firmware, I had the responsibility to do something to type better, and with the adequate practice, faster. In short, I just decided to switch layout. After wandering for days in the web, reading specifics and opinions, I opted to migrate to the Colemak layout. But I went a step further, and I’ve chosen the DH mod for this layout.
Why such a huge change?
Basically the QWERTY layout is something old, that was created with the typewriter machines in mind, rather than the hands of the writer. Its main advantage was to avoid to have the keys stuck at every keystroke, due to the working principle of the typewriters. But am using a keyboard, not a typewriter! And moreover I built my own split keyboard to maximize on ergonomy and comfort, so why not going an extra mile? The Colemak layout, which may look intimidating at first (and is still, after a couple of weeks), offers a totally different typing experience. The whole idea behind is that the most used letters are placed in the home row, so who types doesn’t have to go too far with his fingers. The DH mod applies, with a couple of key swaps, some tweaks to make the experience even smoother.
Any trick for the migration?
Trust me, there is no magic: type, type, type. Is like learning a new music instrument, just give your hands enough time and practice to learn the new paths. Stop at every mistake, have a look at the new layout and restart. A good app to do that is Monkeytype, where you can even look at your metrics and watch them grow! During my first, embarassing attempt I scored a total of 9 words per minute. But in two weeks of daily typing, I reached 30 words per minute, looking at the keys as less as I can. My training routine is pretty simple: I code daily, 5 solid days a week. And on top of that, I add 15 minutes with Monkeytype, daily.
And for gaming?
Very few games are currently supporting a native Colemak layout. So, in order to avoid the hinderance of going through a whole remap work for every game I would play from now until I use this layout, I have added a layer that transforms the left side of the keyboard in a QWERTY pad, while the right side can act as a mouse, thanks to the power of the QMK firmware.
I’ve also added a layer with some media keys shortcuts, to play/pause whatever media is playing, raise, lower a or mute the volume and even moving between tracks. I have preserved the symbols layers and the Fn keys.
I’ve called this fork Redox Scenic. The leds for the layers are the game changers! And they also provide an impressive scenery.
Here some explanatory screenshots from the QMK Configurator:
Layer 0 (Default):
Layer 1:
Layer 2:
If you are okay with this exact layout, as I have not submitted my fork to QMK yet, you can just download this file, uncompress the folder in qmk_firmware/keyboards/ and burn it on both halves using:
qmk flash -kb redox_scenic -km colemakdh
If you would like to customize this layout, you can just import this JSON into the configurator. Once you’ve done, you can download the resultant JSON and parse it with
qmk json2c FILENAME.json
The output can be later pasted in the file keymap.c, as I will show you in a bit. To do that, I assume that you’ve already installed QMK. If not, just have a look at the official guide, is pretty straight forward.
Otherwise, if you just want to have your own take-away, there is just a bit oif copy and paste to do. Let’s gone and dirty with it!
I am considering qmk_firmware/keyboards/YOUR_KEYBOARD as root for simplicity. Check your local installation to know where the right files are!
In rules.mk set
RGBLIGHT_ENABLE = yes
In keymaps/your_keymap/config.h
#define USE_SERIAL
#define RGBLED_NUM 2
Be sure that #define USE_I2C is commented or deleted. RGBLED_NUM defines the total number of LEDs used. In my case is 2, as I have used 1 LED per half.
In keymaps/your_keymap/keymap.c
#define _CLMK 0
#define _SYMB 1
#define _PAD 2
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
[0] = LAYOUT(LT(2,KC_GRV), KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, LT(2,KC_MINS), KC_TAB, KC_Q, KC_W, KC_F, KC_P, KC_B, MO(1), MO(1), KC_J, KC_L, KC_U, KC_Y, KC_SCLN, KC_EQL, KC_ESC, KC_A, KC_R, KC_S, KC_T, KC_G, KC_LBRC, KC_RBRC, KC_M, KC_N, KC_E, KC_I, KC_O, KC_QUOT, KC_LSFT, KC_Z, KC_X, KC_C, KC_D, KC_V, LT(2,KC_PGUP), KC_PGDN, KC_HOME, LT(2,KC_END), KC_K, KC_H, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, KC_LGUI, KC_PPLS, KC_PMNS, LALT_T(KC_PAST), LCTL_T(KC_BSLS), KC_BSPC, KC_DEL, KC_ENT, KC_SPC, KC_RALT, KC_LEFT, KC_DOWN, KC_UP, KC_RGHT),
[1] = LAYOUT(KC_TRNS, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_TRNS, KC_TRNS, KC_EXLM, KC_AT, KC_LCBR, KC_RCBR, KC_PIPE, KC_TRNS, KC_TRNS, KC_PSLS, KC_P7, KC_P8, KC_P9, KC_PMNS, TG(0), KC_TRNS, KC_HASH, KC_DLR, KC_LBRC, KC_RBRC, KC_GRV, KC_TRNS, KC_TRNS, KC_PAST, KC_P4, KC_P5, KC_P6, KC_PPLS, TG(1), KC_TRNS, KC_PERC, KC_TRNS, KC_LPRN, KC_RPRN, KC_TILD, KC_MUTE, KC_VOLU, KC_MRWD, KC_MFFD, KC_TRNS, KC_P1, KC_P2, KC_P3, KC_PENT, TG(2), KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_VOLD, KC_MSTP, KC_MPLY, KC_TRNS, KC_TRNS, KC_P0, KC_P0, KC_PDOT, KC_PENT, KC_TRNS),
[2] = LAYOUT(KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_TRNS, KC_TRNS, KC_BTN1, KC_BTN2, KC_BTN3, KC_BTN4, KC_BTN5, KC_TRNS, KC_ESC, KC_A, KC_S, KC_D, KC_F, KC_G, KC_TRNS, KC_TRNS, KC_TRNS, KC_WH_U, KC_UP, KC_WH_D, KC_TRNS, KC_TRNS, KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_TRNS, KC_TRNS, KC_2, KC_3, KC_TRNS, KC_LEFT, KC_DOWN, KC_RGHT, KC_TRNS, KC_TRNS, KC_LCTL, KC_LALT, KC_TRNS, KC_TRNS, KC_TRNS, KC_SPC, KC_ENT, KC_1, KC_4, KC_5, KC_MS_L, KC_MS_D, KC_MS_U, KC_MS_R)
};
void keyboard_post_init_user(void) {
rgblight_setrgb(127, 0, 255);
}
layer_state_t layer_state_set_user(layer_state_t state) {
switch (get_highest_layer(state)) {
case _CLMK:
rgblight_setrgb(127, 0, 255);
break;
case _SYMB:
rgblight_setrgb(0, 150, 0);
break;
case _PAD:
rgblight_setrgb(150, 0, 0);
break;
default:
rgblight_setrgb(127, 0, 255);
break;
}
return state;
}
_CLMK, _SYMB, _PAD are defined here just for aesthetics, as they are only used to increase the code readibility. keymaps[] is the array containing the whole keymap. You can even skip the copy of this, if your have your own. keyboard_post_init_user(void) is a function called at the boot of the keyboard, is this case I use it to call rgblight_setrgb(), passing some RGB values to it, in order to have a coherent light color between the default layer and the initial layer. layer_state_t layer_state_set_user(layer_state_t state) is called every time the user switches layers. Intercepting the new layer value, I just call rgblight_setrgb() to set a different color on each and every layer.
And BOOM 💣!
After-build consideration and possible new tweaks. Surely building your hyper-customized keyboard is an experience that mixes different things and represents a stimulating yet relaxing moment. If you are a newbie with a soldering pen, this project could be a good benchmark: is not hard and it won’t cost a eye and a leg. Talking about tweaks… In a distant future I’d like to change switches from brown to blue, for 2 main reasons:
- the brown does not give me that tactile and clicky feedback I need;
- my colleagues in the office will surely miss me more 😈.
Also, there are a couple of elements I would like to integrate next: a trackball, a rotary encoder and a display. Playing a bit more with QMK made me understand how easy is to create your perfect peripheral, and how easy is to integrate extra elements. Now to do this I will need to dismantle the keyboard up to the switches… or build another one! Let’s see how it goes, as per now I also have a couple of other projects I wanna make.
For now this is it! Happy building âš’