Custom qmk firmware for keyboard.io model Atreus

Document online location: https://github.com/mrvdb/qmk_atreus

I build the qmk firmware in two ways:

1. Using a github action workflow which takes atreus.json and builds binary firmware on each commit.
2. A script (build) which uses a GUIX container to build it locally using qmk

The rationale for having two ways of building the firmware is to provide a backup and reference for the local setup as it is quite fragile still on my POWER9 powerpc64le machine. Another reason is verification, is the firmware built locally the same as the one built remotely.

Ad 1. Github action workflow

doc: https://docs.qmk.fm/#/newbs_building_firmware_workflow

Roughly how it works:

• use https://config.qmk.fm/ to load atreus.json
• adjust what is needed, possibly compile firmware and flash until done
• download the updated json file in this repo
• commit and push to github, github workflow will build the firmware and produce it as artifact

Ad 2. GUIX container based local build

The build shell script spawns a GUIX shell and builds firmware locally using manifest.scm

Obviously, you’ll need a working GUIX installation for this to be useful.

Implemented features

Layers defined in the layout:

Layer 0

Base layer

Layer 1

Number keys, navigation and bracketing

Layer 2

Function layer, macros

Layer 3

Specials and dangerous key combinations

Here’s an attempt to jam everything in one picture.

Image produced with: https://www.keyboard-layout-editor.com/

Legends:

• lower left is normal key behavior
• top left is the shifted normal
• green is the Fn layer, holding down the green Fn key (Mx is Macro X)
• blue is Layer 1, holding down the L1 key
• blue right center labels are normal L1 keys
• blue right top is shifted L1 keys
• labels displayed on “front” mean to hold the key.

Features implemented:

• numeric keys are auto-shifted; saves awkward key combinations.
• leader configuration for KC_APP is defined, but not used. Not entirely sure how I want to use it yet.
• Shift-( and Shift-) are overridden to give ‘<’ and ‘>’ so I can have a logical bracketing group of 4 keys in Layer 1.
• there are 5 macro keys, 3 are fixed and defined in the firmware, 2 (M3 and M4) are dynamic and can be recorded using the R3 and R4 keys. steps: R4, …record…, R4 M4 -> plays recorded keys back.

-

TODO-list

Make C-M-a easier to type

I use this a lot in lisp programming, but not sure if this should be an Emacs solution or a firmware/layout solution

The right alt key is actually alt-gr so that maps to C-ä instead of C-M-a

Possible solutions:

• map C-ä to the same function as C-M-a
• remap keys in layout somehow

Move reset-keyboard into code instead of keymap

Feels more in place in firmware code than in the keymapping, although factually it is exactly the same. If however put in code, it’s harder to discover (if using the json keymap)