A keyboard design (by alaric)
Ok, so a friend of mine is making himself a custom keyboard - there's a whole hobbyist community of people who design their own, often based on a published design like the Ergodox.
This is related to something I've long wanted to do, which is to obtain myself a chorded keyboard. So I thought I'd write up my current thoughts on the matter, given that they've been brought to the forefront of my mind again!
In summary, I'd like a keyboard that has a left-handed chord keyset (so my right hand is free to operate a trackball, stroke my cat, eat, punch my enemies, etc). Then, to the right of that so it sits in front of me and can be operated by either hand, an 8x8 grid of keys and four rotary encoders (the kind that also have a click switch so you can press them).
That lot is wired up to a suitable microcontroller which presents a USB interface (which also powers the device); it presents as a USB HID keyboard and mouse, and a USB serial port for configuration. The microcontroller uses a small EEPROM to store the configuration so it doesn't need reflashing from scratch to make minor changes.
The chord keyset
I like the concept of the SpiffChorder: a button under each of the four fingers and three buttons under the thumb, allowing the thumb to press nothing, any of the three buttons, or any adjacent pair of two of the three buttons. Sadly, the SpiffChorder wiki appears to have bitrotted, so I can't recall exactly how their keymap was laid out; I'll have to design my own.
I want the chorder to be able to do anything; the other controls on the keyboard are just shortcuts, because in future I'd like to make a smaller device that's just the chorder for pocket use.
The available chords are defined by what you do with each of your five fingers. Four fingers can either press or not press their button, and the thumb can do six things: nothing, button A, button B, button C, buttons A+B or buttons B+C. All fingers doing nothing is the "idle" state that inputs nothing, so the total number of combinations is 2*2*2*2*6-1, or 95. "But normal keyboards have 104 keys", I hear you cry; "a chorder like that can't represent them all!". But we get around that with two-chord sequences for certain lesser-used things and all is well.
The mapping I propose, based on he thumb normally sitting on the middle of its three buttons (B), is that 31 chords created without moving the thumb to buttons A or C are assigned to:
- The 26 letters of the alphabet, arranged so the most common ones are just single finger presses.
- Just pressing the thumb button B on its own sends a "left shift is pressed" code; after the next chord, a "left shift is released" code is sent. So tapping the thumb then doing a chord is like pressing the corresponding key on a normal keyboard with shift held down.
- That's 27 out of 31 used; the remaining four are space,
(,)and enter.
As I use emacs and other Unixy things, I do a lot of pressing ctrl and alt, so the chords consisting of thumb buttons A and C on their own, just as B acts as a "left shift next character" prefix, act as a "left ctrl next character" and "left alt next character" prefix, respectively. The chord consisting of the thumb pressing B and C together encodes a "left hyper key next character" prefix (as my window manager reacts to Hyper+key sequences to control windows and virtual desktops and stuff), and the chord consisting of the thumb pressing A and B together is a prefix that invokes the secondary function of the next chord entered, which is how we manage to fit all of a 104-key keyboard (and lots more) into 95 possibilities. Indeed, it gives us 94+95 possibilities, or 189, without needing to double up any prefixes.
Speaking of which, you can stack prefixes - tap thumb button A then thumb button C then chord "X" to send Ctrl+Alt+X. And doubling a prefix (tap thumb button A twice) "locks" that prefix in place, effectively holding down Ctrl in this case; sending that prefix-chord a third time then unlocks the prefix.
Anyway, that leaves a lot of chords still undefined. Chords using the A or C thumb buttons and the AB or BC thumb button combinations are all ripe for grabbing (except the ones just using the thumb buttons and no others, which are the prefixes I've just explained). Those cover the digits, the function keys (which will be the digits plus a thumb modifier, for ease of learning), all the symbols on the keyboard (focussing on ones used in programming; I'm a Lisper, which is why ( and ) gained places alongside the alphabet), cursor keys, escape, backspace, insert/del/home/end/page up/page down, tab, caps lock, the right hand shift/hyper keys, "Alt Gr", the menu key, the separate numeric keypad keys, Num Lock, Scroll Lock, Caps Lock, Print Screen, Pause, and any volume/brightness/sleep/mute buttons I feel like adding for completeness. I'm quite fond of the Cut, Copy, Paste, Stop, Help, Undo and Again buttons on my Sun keyboard, so I'd probably include those too. Ones I don't use much (bizarre historical stuff like Print Screen, numeric keypad keys, etc) will all get shoved into the Secondary Function Prefix space, and probably never be learnt; I imagine I'll have to look those chords up if I ever need them!
It might be cool to have a chord that acts as a prefix; enter any number using the digit chords followed by the enter chord, and it sends that number as a raw scan code so I can emulate any key on any keyboard.
And I'd like LEDs for Num Lock, Caps Lock, Scroll Lock, and whichever prefixes are active (Shift, Ctrl, Alt, Hyper, Secondary Function).
The Rotary Encoders
So, I also want four rotary encoders with nice largish knobs, probably in a 2x2 grid. They should be just big enough to be able to put a single finger on the edge and rotate it, so I don't need to do a repetitive two-finger twisting action for long scrolls.
As each also has a pushbutton inside it, they can function as four buttons in their own right - and they can be used as modifiers to the rotary encoders themselves, so "rotating while pushed" does something different to normal rotation.
One pair of encoders will generate cursor left/right and up/down presses when turned. When pressed and turned, one will generate volume up/down keypresses (just pressing it without turning can be the mute button); the other will generate page up and page down presses, and if just pressed, will be a middle mouse click.
The other pair will generate mouse scroll left/right and up/down events when turned. If pressed and turned, they will generate single-pixel mouse motion events for precision cursor nudging, and if just pressed will generate left and right mouse clicks.
Perhaps pressing the mouse-click buttons with the "secondary function" prefix enabled should act as a mouse button lock for dragging stuff.
The 8x8 key grid
This is the least important part of the keyboard, but will probably be the most visually impactful part...
It provides 64 keys, which just mirror things that can be done with the chorder or rotaries, but which can sometimes be nice to have as normal keys:
- Cursor keys, Insert, Del, Home, End, Page Up, Page Down
- Escape
- F1-F12
- Tab, backwards tab (the same as pressing Shift and Tab)
- Shift, Control, Alt, Hyper, Menu, Backspace, Return
- Switch to virtual desktop 1-9 (Hyper+digits 1-9)
- Open a new shell window (Hyper+Enter), Split vertical (Hyper+O), Split horizontal (Hyper+U), Merge (Hyper+R) - three window manager control sequences I use a lot!
- 20 other things I've not thought of yet.
Combined with the "secondary function" shift from the keyer we can also put secondary functions on all the keys if needed, so there's no shortage of space. The secondary functions of shift, control, hyper, and alt should probably generate right-shift, right-control, right-hyper and alt gr, respectively.
Physical construction
As it's mainly a one-handed device, with the right hand straying from my pointing device or cat to press key grid buttons or twiddle with the rotary encoders when required, I don't need a complicated ergonomic split/tented shape and can just make the whole thing on a flat PCB with a laser-cut acrylic layer on top. The keyer finger positions and front-to-back tilt of the board should be such that my left hand sits on it in a comfy manner (some palm padding may be desirable, in the form of a little cushion).
Use off-the-shelf keyswitches. I don't know if I'll be able to get keycaps with the legends I want on them - is it better to 3D-print keycaps with legends on them (as negative space that I can fill with paint), or to find some moulded keycaps made of laser-safe material and laser-engrave them? The chorder keys don't need labels, and the rotary encoders are easy enough to memorise, but the 8x8 key grid really needs labels. Colour coding for different groups of keys would be nice, too.
The USB serial port programming interface should be a command line that can just be driven through a terminal emulator, rather than needing special software, and should have a "dump" command that dumps the current keymap so it can be saved and dumped back into the keyboard to fully reset the state. Any spare GPIO lines on the controller can be wired up to backlighting LEDs (I see little point in per-key addressable RGB LEDs, but backlighting for the whole thing for working in dim light might be nice).
Alaric, Computing, Electronics | alaric | 
Wed 29th Jul 2020 9:43 am
Subscribe
By andyjpb, Wed 29th Jul 2020 @ 12:33 pm
Hi,
I am interested in your approach to trying to get the chorder to replace an existing 104 key keyboard. In my head the purpose of the chorder was for alphanumeric input rather than control. Perhaps that's because of my history with the Microwriter and it's chordset which is text-buffer focused and has very few commands. Modern smartphone on-screen keyboards seem to have set a precedent that one doesn't need all the keyboard keys, especially the control ones. There again, it requires a whole custom UI model and trying to use vim under Android with an on-screen keyboard is... frustrating.
In more recent times, perhaps inspired by the SpiffChorder, I think I'd added a third thumb button for more command modes.
As for chord layout, I still like the mnemonic-inspired Microwriter chordset. However, it's designed for the right hand. i.e. with the thumb on the left. Like yours, my design called for left-handed operation. However, I was focused more on pocket-based usage so the idea was to have the left hand wrapped around the back of a smart-phone like slab with the buttons on the top and sides and a screen taking up the whole front area. This gives a "thumb on the left" finger pattern and allows reuse of the Microwriter mnemonic chordset.
My design is so old that I was also proposing to borrow from the Palm pilot button layout and had 4 buttons below the front screen with one of those miniature 5-way joysticks in the middle. I was never sure if they should be operated with the left thumb or right hand tho'.
I'm interested to see your design for the three thumb buttons that makes it ergonomic to press two at once. Perhaps something where the buttons are all squashed together and have thumb sides dips between the pairs that can be pressed together?
How about using one of the buttons in the 8x8 array as a "repeat" button that resends the last sequence? It might be useful for things that require the longer chord sequences and are only useful occasionally but generally used several times consecutively. Stuff like backspace, pgup/dn, Ctrl-C or Alt-Tab, etc. A pair or triplet of repeaters might also be cool so that you could have a stack of commands for basic keyboard macros. Having pgup/dn in there might be good for navigating a buffer. Having Backspace and Enter in there might be good for turning a long paragraph into separate paragraphs in browser based editors such as WordPress or Google Docs.
Does it make sense to lay the 64 keys out as not-a-grid to make it easier to navigate without looking at it and also to accommodate things such as F1->12 and digits 1->9 on single lines? Some kind of triangle based arrangement would allow you to use your little finger to find the right row and then your index finger to push the button.