I would have been crazy had I thought the layout would gain significant adoption, people are already far to invested in QWERTY and local customization dating back to typewriters. The world is full of local minimas and getting the people to crawl out of this one is about as hard as changing to decimal time, global GMT, the US adopting the metric system, standardizing voltage/freq of electrical supply and a host of other things.
That may be a pro, rather than a con. It means you only need to make five or six extra keycaps. Other languages may have more need for a localized layout, but also require more keycaps (not only for the extra letters, but the AltGr keycaps for the displaced symbols), which raise manufacturing costs.
Most manufacturers make the key caps as one mold for the whole keyboard (or in this case at least one half), I think Signature Plastics is the exception but typically this would be the difference between a $30 set or a $130 set (assuming doubleshot PBT). I think the Model 01 does the whole half at a time but @jesse can probably answer that better.
@antevens is correct - our keycaps are being manufactured as a single injection mold per 64 key keyset.
We’re still hopeful that we’ll be able to find a vendor to help us do small-batch customization, but it’s not something we’ll offer for first shipment.
our keycaps are being manufactured as a single injection mold
In that case my cunning plan is not as cunning as I thought. Feel free to ignore.
on a pragmatic note, for those of us set in our ways with qwerty/uk layout I came up with a (hopefully) minimum-mental-overhead layout to switch to keyboardio from standard UK without going totally crazy.
So here is the layout diagram showing my changes from stock (without my own idiosyncratic thumb remapping):
Getting that working in Keyboardio firmware is a bit fiddly. To get orphaned symbols into the function layer when using a UK software mapping these are the code snippets for Model01-Firmware.ino:
- # -----> Key_Backslash
- ~ -----> LSHIFT(Key_Backslash)
- \ ------> Key_NonUsBackslashAndPipe
- | ------> LSHIFT(Key_NonUsBackslashAndPipe)
Just received my Model 01, trying to work out what I’m going to do with the insufficient number of keys. Thanks for putting this layout together.
A couple of questions:
- How does one get to a base Model01 keyboard layout in keyboard-layout-editor.com to mess with?
- What’s the easiest way to take the overlay you’ve created and apply it to the stock QWERTY layout that the Model01 ships with?
I’m coming from an Ergodox with a modified QWERTY layout:
My primary machines are Chromebooks which are set to UK Dvorak in software. Using a Model01 with stock firmware in that configuration, I have a bunch of keys not accessible. Most notably:
- / and ?
- \ and |
I’m trying to work out if that will give me full access to all the keys that I need to use on a day to day basis.
Would you mind giving the firmware fork in https://github.com/andrewgdotcom/Model01-Firmware/ a try? The option
merlin2 should work well with UK Dvorak (or any Dvorak for that matter).
This might be a reasonable starting point:
I seem to recall seeing a blank layout too, but I don’t have the link handy at the moment. The Share your layout topic has a few other layouts of various kinds, and some links to KLE too.
Hope this helps!
Here’s a blank one I made.
Apologies for the delayed response, I’ve been busy for the past month.
Having a look at the source code, it seems like the merlin2 layer is compiled into the firmware, but it’s not obvious to me how to select the merlin2 layer as the base/default layer used by my keyboard.
To enable mixing and matching of different layers, I split out the layout logic from the main
.ino file into the
keymaps.h file, which I then heavily modified.
If you look at
keymaps.h you will see a series of
#include directives. Commenting these in and out changes what layout options get compiled into the firmware. The default branch has
aliases-abg-orphans-merlin2.h enabled, so this is used by the parameterised base layer.
The base layer is defined in
layer-std-qwerty-parameterized.h - you can see this
#included into the
const Key keymaps definition at the bottom of
keymaps.h. This is a special layout file that relies on macros defined in the
aliases-* files. The other two default layers are
#included in a similar way, but they don’t use the macros.
So in short, merlin2 is enabled out of the box. If you want to try one of the other options, edit
keymaps.h and rebuild.
Hmm. Managed to flash merlin firmware, have UK Dvorak in software on my Chromebook. Still can’t get access to NON_US_\ or whatever it’s called (\ unshifted, | shifted, on an ISO 105 key keyboard). Is there a PDF/SVG of the merlin layout which I can look at?
In merlin2, non_us_backslash_and_pipe is to the left of A (i.e. PgUp). So a US-dvorak should look like:
Hm. AFAICT it’s stil mapped to PgUp. Is merlin2 a non-default layer? How do I rotate to it?
Something funny going on. What’s in your
I built from whatever’s on master, so https://github.com/andrewgdotcom/Model01-Firmware/blob/master/keymaps.h
master has merlin2 set as the default geometry, so it should work.
Have you successfully compiled and flashed any other changes? Is your keyboard still using factory defaults by any chance?
Possibly. The flash appeared to work (I got the prompt to press the Program button etc, and there were many blinkenlights on the Model01).
I’ll have a crack at flashing this again tomorrow.
master also has changes on the default Fn and Numpad layers, so if you see anything at all that differs from factory then something at least has worked. Check in particular the behaviour of Fn-Tab and Numpad Tab - they should both produce PageUp.