I did not need another mechnical keyboard. That’s what I kept telling myself while clicking the complete order button on Kono’s website. The Whitefox, with it’s open source design and firmware, was just too much for my curious heart to take. Think of the configurations, Justin…think of the bug fixes.

Before long, the keyboard was on my desk, configured with my custom layout and binds. It was such a smooth experience, not a single hiccup, that I honestly thought I had been dreaming.

As with all dreams, I longed for more control. The web configurator and firmware generation was cool, but I wanted to run it in my own little sandbox, in it’s own little world. I set out to understand the underpinnings and see about building a docker container.

Roads paved with good but lacking documentation

The first stumbling block I ran into was that the documentation for actually getting the web configurator and the firmware generation up and running was at best written, but lacking. The docs are largely out of date across the required repos, leading to a little more digging that might normally be required for this sort of container. Nonetheless, I like a challenge.

Issue number one was determining exactly what the web configurator required. The docs in the repo made some sense, but from digging into the partial dev docker image in that repo and the build commands, I could see I was going to have a few issues. I forked kiiconf, made some changes to the lighttpd config to handle the dist output and we had some UI.

Issue number two was sorting out the firmware build. The deps were fairly clear in what to install via apt, but firing it up I noticed a few things missing. For one, it required Python’s pipenv (which was failing in the container on spin up). Second, it needs some pythons deps to run the build scripts (which it wasn’t going to get within the pipenv since that was going to have to go).

The problem was how to go about it. I could hard fork a lot of the submodules that kiiconf needed, re-write some scripts, and sort of end up with a version all my own, but this didn’t feel like the way to go. I wanted configuration, I wanted to run my own firmware builds, but I wasn’t going to have the full time to devote to it. So, I turned to my old friend sed and decided to do some chop and replace.

When life gives you script errors, sed to the rescue

sed is one of those tools I don’t know by heart. It has deep usefulness and the manual leads to receipes for many occasions. In this case, it was all about the checks we didn’t want and the paths we really needed.

The first chop was to remove the pipenv checks within controller build’s cmake.bash. This would allow the script to no longer fail when attempting to setup the build. No need to replace, just a straight up chop:

Having resolved that issue, the firmware now half built. Turns out some of the paths were bad specific to the kll build script cases for kiiconf. Not a problem, sed replacement to the rescue again.

If you ask me “Justin, are these good fixes”, my answer is that they work but aren’t good fixes. My obvious inclination is to learn if these issues are upstream bugs and should be fixed. (Note, the above path problem was just fixed upstream, yipee!) That’s where I’ll head next but in the mean time, sometimes you just want something that works.

It’s alive!

Low and behold, patched build script lines and some creative installing later, our kiiconf docker image is up and running, complete with firmware builds and output. For the daring among you, you can grab the docker image from the repo and fire it up as such: