It’s not katana, it’s kanata. I know… When I first heard about this, I also spelled it as katana, and even searched github that way for checking the source. Same happened when I mentioned it to my friend. Human brain works in weird ways I guess.

Regardless of the weird naming, kanata is really cool. Basically it’s kmonad re-written in Rust 🦀. Of course, that’s not the only difference from kmonad, but let’s first explain what we are talking about for the people that have not yet reached the same autism level as custom keyboard owners like me.

This is a cross-platform software keyboard remapper for Linux, macOS and Windows. A short summary of the features:

  • multiple layers of key functionality
  • advanced key behaviour customization (e.g. tap-hold, macros, unicode)
  • cross-platform human readable configuration file

Directly, from the github repository of kanata. This tool, like kmonad allows you to configure your keyboard to be able to do all sorts of crazy things, but usually for making it easier and more ergonomic to use them. Examples include:

  • Moving modifier keys - namely ctrl, shift, alt, cmd/gui/win - to a easier to reach locations or setting up home-row mods so that you can save your little pinkies from all those pain and suffering…
  • Moving symbols and number to additional layer(s) so that you can input them by holding a layer key (i.e. space) and pressing a easy to reach key (i.e. ’e’ and ‘r’ for ‘{’ and ‘}’) instead of extending your hands to the number row in normal keyboards.
  • Having macros or combo keys for triggering some sort of action with a single key press (or multiple if you wish) that would usually take much more effort.
  • Having a layer or a combo for non-english letter inputs on English keyboards, i.e. ‘ü’ for German and Turkish speakers.

In short, it allows you to program your keyboard to do whatever you want. Normally, if you know about those custom, split, ortholinear, blabla… keyboards, you might also know that those are usually programmed with QMK or with ZMK. These allow you to program your custom keyboard’s micro controller, making the customizations at the hardware level. This, however, have two disadvantages:

  • Your keyboard needs to be programmable, which is not the case for most of the keyboards out there, especially not for your laptop keyboard.
  • Even though there are some GUI tools for configuring with them, any complex use case will require you to write some C based DSL configuration.

As you can guess, programmable keyboards are usually more expensive than the regular ones. Let’s say you paid for one like me, you will quickly realize the C based DSL they use is not really that fun to work with.

Now, there is also the software level keyboard programming side of things. Usually, for many years, the go to tool for that was kmonad. It’s a Haskell based tool that allows you to configure your keyboard with a Haskell based DSL. It’s really powerful, but when I tried to set it up, it was a bit of a pain, and also felt a bit slow. Therefore, I didn’t really use it much.

Then, recently, I found kanata. It’s essentially rust based kmonad, with it’s configuration DSL a bit different compared to kmonad. I was kind of tired of trying to configure my Corne, then saw this tool, and decided to give it a try. I use NixOS BTW \j, and thankfully, there already exists a service module for kanata, which makes setting it up and configuring it really easy.

I first tried some simple layer configurations, and felt no latency at all! Afterwards I even setup home-row mods easily, which is a bit tricky to setup on QMK or ZMK, and it worked flawlessly. I was really happy with the results. Only tricky part was to make it work with my Corne, since it is a bluetooth keyboard and doesn’t create a device in /dev/input/ like regular keyboards. I had to create a udev rule for it, which filters connected devices based on their attributes, and creates /dev/input/cornekbd device file automatically. Had to use combination of the following commands to get the information for the Corne:

bash
1$ cat /proc/bus/input/devices  # to get the information about the keyboard
2$ udevadm info -a -n /dev/input/event29  # found event number from the previous command
3$ udevadm monitor  # to see the events when I connect the keyboard

The udev rule is setup like the following on NixOS:

nix
1{
2  ...
3    services.udev.extraRules = ''
4      KERNEL=="event*", SUBSYSTEM=="input", ATTRS{name}=="Corne Keyboard", SYMLINK+="input/cornekbd"
5    '';
6  ...
7}

With all these setup, you can go ahead and configure your keyboard to your heart’s content (can even have different configuration for each keyboard!). I’m really happy with the results. Now, I don’t really need to mess with QMK or ZMK, and can even customize my laptop keyboard. Here is the full configuration I currently use, feel free to steal things from there 😄.

Anyway, that’s all for today. I hope you enjoyed the post. If you have any questions, feel free to ping me from somewhere (possibly email). Until next time, take care! 👋