Check out the blogpost here: https://tarneo.fr/posts/split_keyboard/
this post was submitted on 21 Aug 2023
65 points (94.5% liked)
ErgoMechKeyboards
5872 readers
3 users here now
Ergonomic, split and other weird keyboards
Rules
Keep it ergo
Posts must be of/about keyboards that have a clear delineation between the left and right halves of the keyboard, column stagger, or both. This includes one-handed (one half doesn't exist, what clearer delineation is that!?)
i.e. no regular non-split¹ row-stagger and no non-split¹ ortholinear²
¹ split meaning a separation of the halves, whether fixed in place or entirely separate, both are fine.
² ortholinear meaning keys layed out in a grid
No Spam
No excessive posting/"shilling" for commercial purposes. Vendors are permitted to promote their products/services but keep it to a minimum and use the [vendor] flair. Posts that appear to be marketing without being transparent about it will be removed.
No Buy/Sell/Trade
This subreddit is not a marketplace, please post on r/mechmarket or other relevant marketplace.
Some useful links
- EMK wiki
- Split keyboard compare tool
- Compare keycap profiles Looking for another set of keycaps - check this site to compare the different keycap profiles https://www.keycaps.info/
- Keymap database A database with all kinds of keymap layouts - some of them fits ergo keyboards - get inspired https://keymapdb.com/
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Very nice keyboard!
For French, I like having a 4th alphabetical key under the middle finger (for instance, move the innermost thumb key a little upward so that is contiguous with the middle finger column). This allows having all the most common characters in the main layer (also using most of the outer pinky columns for this purpose).
Otherwise does this 2 row cluster work well for you? (In particular the upper row)
Concerning the technical trick with xmodmap, I have the feeling you are adding much complexity just for the sake of using qmk's graphical configurator. Since you are already using xkb (obviously, since there isn't any serious alternative under X11 or Wayland!), why not configure everything in xkb layout? This way you can configure any existing character without any strange workaround or third party tool! Then your use qmk just for fancy stuff (layers, combos, hold-tap, ... ).
The usual argument against xkb is that you cannot bring your keyboard around and have it ready to use on any machine. But since you are using xmodmap, I assume it is not a concern for you, is it?
I could cut it off. The 5 innermost keys aren't even used, and the one left over is just for (rarely) pressing alt, and that's only on the left half. As for the top matrix row, it's the same situation: I only use it for function keys which I only use for switching tty's, and I know I would always ask myself "wait, how do I press f1/f2?" The outer keys are used for the enter key and print screen, which leaves 4 unused keys. That's:
= 27 keys that could be removed. Yikes.
Now onto the xmodmap stuff: when I need to use the keyboard on a new computer, it will almost always be on an X11 Linux one, as that's what my high school computers for IT use (the one specific to the classes I'm taking), and also what I managed to get my family to use. This means I'll always be able to add the xmodmap stuff, plus it poses no problem to other users of the same account (if applicable) as it uses f13+ keys which nobody else would use (most people don't even know these keys exist). I also like not having to change my keymap from us especially when doing work on server hardware (I sometimes physically access a think centre used for backups at renn.es, shameless plug). The configurator is not even really my thing anymore, I only ever change the config through the file nowadays.
My first ergo split was a Kimiko (roughly the same as a Sofle v2) which also had this num row I quickly stopped using (I ended up affecting it to F keys, still useless anyway; even for switching VTs I tended to use F keys from one of the layers).
My current daily driver is a 3x6 dactyl with a 4th key under middle and ring finger columns and... a 6 keys (2 rows) thumb clusters. All 6 keys can easily be reached because of the 3D shape. I would say only a couple of keys among the 50 are not really useful, hence it is the sweet spot for me now (for a sculpted keyboard anyway; for a flat one, I have to make it work with smaller thumb clusters).
Anyway the similar layout of the thumb clusters and similar goals (Linux user; typing in French) made me want to comment :).
Ha, kinda the same story for me.
For my first ergo split, I wanted to build a Corne, but ended up building a Lily due to not being able to order the Corne and being somewhat uncertain of "just 3 rows". Now my mapping has gravitated to something that'd fit on a Corne, I don't use the outermost thumbs and am weaning myself off of the num row. Still considering whether I should try and work with 5 columns instead of 6, but there's some useful keys there — for now.
I can see myself building another split in the future (something that's slightly more travel-friendly than the Lily), and it's probably going to be a Corne. The Lily's thumb cluster is slightly to far to the outer edge for my comfort.
Yeah, a dactyl kinda defeats the point of having a small keyboard. Soon I'll try to make a 36-key split with some way to link the two parts to make it usable on laptops for example (rn it's comically large when using a laptop: I need to put the two halves on the side plus a mouse if I don't want to use the touchpad). I'll also use sockets for everything (switches & XIAO controllers) so that the next one I make doesn't cost as much.
You say there is no serious alternative: did you check out keyd?
Unless I am mistaken, keyd is a kernel level input remapper (like kmonad and kanata). So it is a lower level component: even if you use keyd, xkb will still be there, downstream. The situation would be roughly the same as with xmodmap... except it won't even be enough!
Indeed, this method consists in mapping scan codes to other scan codes. At this level, there is not the notion that a key produces a character yet. Hence concretely, kernel level input remapping (like QMK, btw) cannot be used to map a key to a character that is not already declared in a higher level component (usually in xkb or xcompose, but it can also be a another component using X11 API, such as xmodmap, for instance).
Edit: to make it more clear, in the end, it is the application who decides what character should be displayed. Typically, for doing so, the application relies on libraries from its toolkit, which implement either X11 or Wayland text input protocols; using standard keycode-to-character translation libraries (i.e., most notably, libxkb). To add new characters in a keymap, these characters need, in the end, to be produceable as the output of these libraries.