wat?

The Infinity Ergodox is a split, open hardware, open source keyboard. I purchased mine through the Massdrop group buy. The Infinity Ergodox comes as a partially assembled kit. The PCBs have most of the components soldering on already, but you have to solder on the key switches you chose. Personally, I'd rather more of the parts come unattached, like the previous Ergodox group buy.

:D

After many production delays............. The package arrives.

The packaging on this was really excellent. It may be the best packed package I've ever received.

Let's move over to the workspace and finish unpacking all the parts.

PCBs look excellent. The design is rather interesting, too.

Looks like there are debug headers on each of the keyboards' thumb sections. Might be fun to play with at some point.

We can build it, we have the technology

First, we want to place the switches into the mounting plate. The switches snap into place when properly seated. One thing to keep in mind is that you should do the two large thumb keys first and install the stabilizers before doing the other keys in the thumb area to make it easier to pop the stabilizer bar into place. You'll note I did not do this, causing some frustration.

Since I skipped the stabilizer part before, let's do that now.

These small connectors which the stabilizer bar attaches to fit into the keycap connector. They only fit into the stabilizer stands in one direction, so make sure you orient them correctly based on which direction you want your key to face.

Here you can see how the stabilizer bar connector fits into the stabilizer stands.

Apply pressure to the stabilizer bar to insert it into the small holes in the stabilizer stands. It should pop in without too much effort. Once they are in correctly the key should travel easily.

You can see here how, because I did this in the wrong order, the switch and keycap are in the way of installing the other stabilizer. It worked out, with the help of some small tools to press in the stabilizer bar.

After the stabilizers are placed and you verify that the two thumb keys travel smoothly, it's time to solder! First we place the PCB onto the bottom of the mounting plate, making sure that the switches are fully seated into the PCB. The solder points on the switches should extend slightly from the PCB (by 1-2mm, I believe).

You can see here about how close together the mounting plate and the PCB should be. Should you leave too much room between them, the case will not properly fit together at the end.

Then we solder!

Note that I've used significantly more solder than is actually necessary to adequately connect the switches to the PCB. I just did this because I think that it looks prettier, and I am using a transparent case.

Now that the electronics are completed, you should plug the keyboard in and test it to make sure all your soldered connections are good. The firmware that the keyboards are shipped with does not appear to have a key to toggle the firmware flashing mode, so, at this stage you should also flash a firmware that has such a key while access to the dedicated flash button is available. The flash button is labeled S39 and is located on the back of the PCB one key above the microprocessors.

Now we can start assembling the case. First, a test fitting.

Then, we peel off all the protective materials and put the case together.

Keycap placement

The keys can be a little difficult to figure out how to place. I purchased the DCS clear keycaps, which are contoured based on which keyboard row they are meant to be placed. The first row is the tallest and least angled key type. The second row is slightly angled and slightly shorter. The third row is shorter again and slightly angled. The fourth row is much more angled and of a medium height.

The first step is to separate all of the keys by type. You should have 16 top row keys, 14 second row, 10 third row, and 20 fourth row. You should have two 1.5u keys for each of the first, second, and fourth rows, then 6 for the third row keys. Finally, you should have 4 2u keys for the thumb area.

Below I show the placement by row in the order of the 2u thumb keys (already placed from earlier), then the first row to the fourth row.

完璧... maybe?

The final product, powered on with the shipped firmware.

I do need to buy the LEDs and solder them in, still.

Firmware

The simplest way to get started with programming the keyboards is to use the online configurator and to read the flashing documentation. The first time you flash you should flash both halves. I intend to always flash both halves, however, just to keep things as consistent as possible.

The online configurator is somewhat limited in it's options, but as far as getting the basic layout you want for basic daily driver usage it should be adequate. I have had issues messing with the international options the page presents. Specifically, the compiler seems to fail when building the firmware when they are included in the layout.

These instructions are designed for Gentoo and may or may not be useful elsewhere. You'll want to grab the Portage config munging script which splits up your portage configs by target architecture. Should you rather do this by hand, the idea is that we want to change all of the package.* files in /etc/portage to be directories. That means you need to do something along the lines of the following for package.{accept_keywords,env,keywords,mask,unmask,use}. It's easier to just use the script, though...

# cd /etc/portage
# mv package.keywords package.keywords.bak
# mkdir package.keywords
# mv package.keywords.bak package.keywords/monolithic
			

First, we need to emerge crossdev, which lets us maintain multiple toolchains simultaneously via Portage. Then, we instruct crossdev to build the requisite toolchain. Unfortunately, it seems like the g++ gcc frontend is disabled by default. I haven't been able to find a one liner to build the toolchain with it enabled, so sed is used. Feel free to open /etc/portage/package.use/cross-arm-none-eabi and modify 'nocxx -cxx' to '-nocxx cxx' if you're more comfortable with that. Then we rebuild the toolchain with the new USE flags and the g++ frontend appears as arm-none-eabi-g++.

# emerge crossdev
# ./convert-profile-to-files.sh
# crossdev -S -v -t arm-none-eabi
# sed -i 's/nocxx/-nocxx/' etc/portage/package.use/cross-arm-none-eabi
# sed -i 's/-cxx/cxx/' etc/portage/package.use/cross-arm-none-eabi
# emerge -avt cross-arm-none-eabi/gcc # Rebuild with g++ frontend
			

Now, ./buildall.bash in your local controller checkout should build successfully.

Currently this is as far as I have gotten with firmware customization. I've been reading the documentation for the controller as well as documentation about USB keyboards, international keyboards, etc. The next things I plan on doing are:

  1. Port my current firmware configuration over to the custom build approach
  2. Add complex macros (e.g. /buffer ## for changing weechat windows)
  3. Customize the displays on each keyboard