Alternatives for long time Maltron user?

[yorten]

Hi,

First time posting here. I'm a long time Maltron user, L89 type dual hand 3D with Cherry Black MX
switches, PS/2 connector but a couple of things have me considering alternatives now, namely:

1. My pinkies get sore. Too much Shift work with programming symbols over the years, I think. I've had a
   limited go at software remapping the Shift key to the thumb clusters (Home and End keys) on Linux
   using xkb but without success so far: it tends to change other keys as well. eg. My model has '(' on
   the 5 key but after my mods, it reverted to '%' like a standard keyboard. There was also some other
   weird behavior with the underscore key, which seemed to want to become 'home + _'. I'm thinking it
   can probably be done, I just need to learn how to do it, but I'm also not sure if the unusual
   placement of the symbols results in Shift remapping limitations or anything. Has anyone had success
   at software remapping Shift keys in Linux, Windows and Mac? Having to figure out remapping for each
   OS sounds painful vs native hardware support.

2. I ordered a new Maltron last year but I didn't realize they now ship with Cherry MX Brown switches by
   default. Their website seems outdated, still listing the Black switch as the default:
   https://www.maltron.com/cherry-mx-switches.html. I probably haven't used it enough to fully adapt but
   I'm not sure they appeal to me vs the Black switches. I appreciate they require less force, the Black
   switches feel heavy now, but the Browns aren't smooth at all and accuracy seems harder. I tend to end
   up with inadvertently repeated letters too often. I'm wondering if the popularity of the Brown
   switches is more due to people transitioning from traditional keyboards but generally aren't
   advisable for those who have used linear switches? Or is it really just an arbitrary personal
   preference thing?

Both of the above led me to discover:

1. ErgoDox EZ:
    - pros:
        - programmability: layers and the ability to distinguish between taps and holds sounds
          very powerful. It would also allow me to continue using the Malt layout. I'm assuming the
          adaptation period in doing so would be greatly reduced. The thought of having a dedicated
          symbols layer seems very enticing.

        - arbitrary shoulder separation: the Maltron does require moving my arms closer to my body vs
          true neutrality so it might be a positive. Not as big a difference as the jump from standard
          keyboards to the Maltron but it might still be noticeable.

        - explicit choice of key switches when ordering. I'm wondering if I might like the Cherry MX Reds
          given my experience above.

        - easily replaceable key switches: I have no hardware skills and this reduces the stress of
          choosing the 'best' switch type from the start

        - flexible height, tenting and tilting.

        - opensource. Nice community driven lineage behind it.

        - shine model might be useful for easily distinguishing toggled layers. I might have some use
          for application specific layers. The Glow model isn't an option since it doesn't support the blank sculpted keys.

    - cons:
        - not contoured. The Maltron key wells fit my hands really nicely, although on the list of
          positive Maltron features, it's probably the lowest vs ortholinear, mechanical switches, thumb
          clusters, shoulder separation. Still, I'm not sure if there are ergonomic negatives to a
          flatter keyboard. I've been using the Maltron for so long, I can't tell.

        - not sure about the wrist rests coupled with tenting and tilting. The Maltrons have a built-in
          wrist rest.

        - arbitrary shoulder separation might be a double edged sword? It would mean having my mouse
          further away than it currently is. Is it feasible to place the mouse between the halves?
          Doesn't seem like it would be very natural.

        - only 6 keys per thumb cluster vs 8 on Maltron. Although I think with the tap vs hold key
          programmability, this might not be an issue.

2. Kinesis Advantage 360
    - pros:
        - contoured but I've read in some postings that the contouring of the Advantage 2 isn't
          necessarily as nice as the Maltron due to the constraints of mass production vs the hand
          assembled Maltrons so it might disappoint me anyway.

        - programmable

        - arbitrary shoulder separation

        - adjustable tenting

        - long history in the market

    - cons
        - can only select key switches and blank key caps with the signature series but they don't seem
          to offer Cherry Reds and the current build times are listed as 60-75 days

        - open source ZMK programming engine only available if you choose the Bluetooth model. I
          generally prefer wires for keyboards. It can still operate off a cable but I'd be paying for
          something I don't need. I haven't yet looked at how ZMK compares to QMK.

        - easily replaceable key switches isn't a feature.

3. Glove80
    - pros
        - contoured
        - programmable, uses opensource ZMK
        - arbitrary shoulder separation
        - adjustable tenting

    - cons
        - no choice of switches (UPDATE: actually, you do have a limited choice between linear, tactile, and clicky)
        - easily replaceable key switches isn't a feature.
        - low profile switches, which may or may not be a con
        - less established

4. Keyboardio Model 100
    - pros
        - layout looks interesting, although I can't tell whether it's 'better' or not
        - easily replaceable key switches
        - adjustable tenting and tilting
        - programmable
        - opensource firmware

    - cons
        - less established and is only in the pre-order stage
        - doesn't offer cherry switches. I have the impression Cherry switches are supposed to be the
          best

I'm particularly interested in hearing from any other Maltron users out there who have tried or even
switched to alternatives and what they've found to be the pros and cons but all feedback is welcome.

Thanks!

[Findecanor]

Welcome to Geekhack!

Kinesis:
- Advantage2 and the wired Advantage360 do support remapping and macros on the keyboard itself. The wireless with ZMK is programmable in the way that you could modify its source code.

ErgoDox:
- The outer and "north" keys in the thumb clusters on the ErgoDOXen can be hard to reach because the cluster is not angled.
- The ErgoDox EZ is a commercialised variant of the original ErgoDOX, which is Open source. The original but not the EZ supports the option of splitting the 2u keys to get 8-key clusters, but as I wrote above, only four of them would be much usable. For the DIY:er, components have been available from many vendors, but many have gone away.

You could also check out the Dygma Defy, which has 8-key low-profile thumb clusters. It is only on pre-order with shipping expected in January, so there are no reviews yet.

There is also a large DIY scene... with people having designed their own keyboards and released as Open Hardware but most of the have had much fewer keys than an ErgoDox.
I think the most active forum for that is on Reddit: https://www.reddit.com/r/ErgoMechKeyboards/

[yorten]

Welcome to Geekhack!

Thanks! Wish I'd discovered this sooner!

Kinesis:
- Advantage2 and the wired Advantage360 do support remapping and macros on the keyboard itself. The wireless with ZMK is programmable in the way that you could modify its source code.

The on-the-fly remapping does sound pretty cool. It would make it easy to fine tune mappings before settling on the final one. I can see myself going thorough many iterations. I suppose in theory, such a feature could be added by customizing QMK or ZMK on other keyboards, unless Kinesis happens to hold a patent.

ErgoDox:
- The outer and "north" keys in the thumb clusters on the ErgoDOXen can be hard to reach because the cluster is not angled.
- The ErgoDox EZ is a commercialised variant of the original ErgoDOX, which is Open source. The original but not the EZ supports the option of splitting the 2u keys to get 8-key clusters, but as I wrote above, only four of them would be much usable. For the DIY:er, components have been available from many vendors, but many have gone away.

Is reachability in terms of not moving ones home row fingers? On the Maltron, for the outer keys, except maybe the arrow keys, I do actually move my whole hand by up to 1 column and/or row, albeit possibly the curvature is what makes it so easy to get back to the home row after this. It's very obvious when you aren't on the right keys. My hands are maybe pretty average in size.

"Hugging" the home row only seems important when in the flow of typing text. If I'm using the outer keys on the thumb clusters, it means my mental flow of text has already been interrupted so having a small physical interruption as well isn't an issue.

When using Ctrl and Alt modifiers (located on the thumb clusters),  I also often use two hands: one hand for the modifier, the other hand for the modified key in the other key well. The only exceptions are Ctrl-b, f and v which are close enough for index finger comfort. For Ctrl-Alt, I leave the key well completely and use my index and middle finger.

On the ErgoDox EZ, I would also plan to use the outer keys for modifiers: Ctrl, Alt, Shift, Layer shift. Although if they're a bit hard to reach, I'd probably move the Shift to the big middle keys and the enter to one of the outer keys. I'd have to have a closer go at the configurator to see if that would work out. I would ideally also overload the modifier keys with tap for punctuation but if they're hard to reach, I can probably leave them on the main keys. It's a bit arguable as to whether punctuation is better via thumbs or main keys. Never tried it before.

You've prompted me to take a closer look at the geometry of the keyboards. I'm inclined to discount the Kinesis now. It's thumb clusters seem oddly placed. They're higher than the key wells and look uncomfortable, whereas they're lower than the keywells on the Maltron. The latter means ones  fingers and thumb are curled and positioned  relative to each other in about the same way they do when they hang loosely by ones side.

Versus the Ergodox EZ, I'm not sure the difference in distance to the thumb keys is actually that great. It seems like the biggest difference is the relative vertical placement rather than the horizontal distance within the plane ones hand sits in when typing. Obviously, it's hard to tell for sure without having both keyboards but I've taken some photos to try and convey what I mean.

Side, level to desk:


Same photo but rotated to be level to the thumb cluster:



Top down, level to desk:


Top down, very roughly level to the plane one's hand sits in when typing:

You could also check out the Dygma Defy, which has 8-key low-profile thumb clusters. It is only on pre-order with shipping expected in January, so there are no reviews yet.

Thanks, I hadn't seen that one. I think the "8-key" thumb clusters are a bit misleading, though, comparatively speaking. Four in each are below the alphabet keys. On the Maltron and Ergo-EZ, there are already keys there that are distinct from the thumb cluster and, at least on the Maltron, are easily accessible using index and middle fingers . Furthermore, the Dygma has another two keys per cluster below those. To reach them by thumb, would mean either moving ones thumb below ones palm, which seems awkward, or moving ones whole hand, or using ones index and middle finger instead but again, that looks uncomfortable without moving ones whole hand.

I do like the 'up to 60 degree tenting' and the hot swappable switches, though. From the screenshots, their layout editor also looks pretty slick.

There is also a large DIY scene... with people having designed their own keyboards and released as Open Hardware but most of the have had much fewer keys than an ErgoDox.
I think the most active forum for that is on Reddit: https://www.reddit.com/r/ErgoMechKeyboards/

Ahhh ... if only I had such skills! Must be really empowering to be a DIYer. Maybe one day but right now it seems like an insurmountable mountain vs the time I'd need to put in.

[yorten]

   I've had a
   limited go at software remapping the Shift key to the thumb clusters (Home and End keys) on Linux
   using xkb but without success so far: it tends to change other keys as well. eg. My model has '(' on
   the 5 key but after my mods, it reverted to '%' like a standard keyboard. There was also some other
   weird behavior with the underscore key, which seemed to want to become 'home + _'. I'm thinking it
   can probably be done, I just need to learn how to do it, but I'm also not sure if the unusual
   placement of the symbols results in Shift remapping limitations or anything. Has anyone had success
   at software remapping Shift keys in Linux, Windows and Mac? Having to figure out remapping for each
   OS sounds painful vs native hardware support.!

Just an update in case it's useful for anyone. I don't think this can be done on an old Maltron L89 layout, which is different to the newer L89s, due to the shenanigans the firmware does (and has to do, I think) in order to have the symbols in non-standard locations. Couple of examples:

- ex1: the 1 key's shifted state is +. This is how the Maltron seems to achieve that:
    - pressing 1 without shift sends keycode 10, as expected

    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16300651, (573,559), root:(573,614),
        state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
        XLookupString gives 1 bytes: (31) "1"
        XmbLookupString gives 1 bytes: (31) "1"
        XFilterEvent returns: False

    - however, shift-1 sends shifted keycode 21. ie. it's pretending to be the =/+ key on a standard US keyboard.

    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16302293, (573,559), root:(573,614),
        state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
        XLookupString gives 0 bytes:
        XmbLookupString gives 0 bytes:
        XFilterEvent returns: False
       
    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16302424, (573,559), root:(573,614),
        state 0x1, keycode 21 (keysym 0x2b, plus), same_screen YES,
        XLookupString gives 1 bytes: (2b) "+"
        XmbLookupString gives 1 bytes: (2b) "+"
        XFilterEvent returns: False

- ex2: there's a ! key with a shifted state of ] achieved via:
    - pressing ! _without_ shift, sends shift and keycode 10 all on its own. ie. pretending to be the 1/! key on a standard keyboard

    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16401878, (307,879), root:(307,934),
        state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
        XLookupString gives 0 bytes:
        XmbLookupString gives 0 bytes:
        XFilterEvent returns: False

    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16401893, (307,879), root:(307,934),
        state 0x1, keycode 10 (keysym 0x21, exclam), same_screen YES,
        XLookupString gives 1 bytes: (21) "!"
        XmbLookupString gives 1 bytes: (21) "!"
        XFilterEvent returns: False

    - pressing shift-! sends a bunch of shift events (weird) and keycode 35, again, pretending to be another key on a standard keyboard

    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16519469, (301,227), root:(301,282),
        state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
        XLookupString gives 0 bytes:
        XmbLookupString gives 0 bytes:
        XFilterEvent returns: False

    KeyRelease event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16519920, (301,227), root:(301,282),
        state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
        XLookupString gives 0 bytes:
        XFilterEvent returns: False

    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16519940, (301,227), root:(301,282),
        state 0x0, keycode 35 (keysym 0x5d, bracketright), same_screen YES,
        XLookupString gives 1 bytes: (5d) "]"
        XmbLookupString gives 1 bytes: (5d) "]"
        XFilterEvent returns: False

    KeyPress event, serial 40, synthetic NO, window 0x3400001,
        root 0x1e1, subw 0x0, time 16519955, (301,227), root:(301,282),
        state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
        XLookupString gives 0 bytes:
        XmbLookupString gives 0 bytes:
        XFilterEvent returns: False

I think the above has to be done to be handled correctly as a US keyboard, due to the way the OS interprets (shift, keycode) pairs, which I only have a vague understanding of from https://wiki.archlinux.org/title/X_keyboard_extension#Basic_information_on_XKB. I think it also explains something I wasn't clear about with the Ergodox EZ, that it didn't seem like you can customise the shifted state of keys; they just behave 'as normal'. Not needed with the layers feature but it seemed curious.

The newer L89 Maltron's leave the shifted states on the same keys as a standard keyboard. I wonder if it was done in response to user feedback about remapping difficulties.

[vvp]

I used Kinesis Advantage from around 2002 to 2014 when I switched to my custom version of Kinesis Advantage (Katy). Just after few years of using Kinesis Advantage I swaped enter<->leftShift, delete<->rightSfhit and escape<->capsLock. That is the minimum one must do to make Kinesis Advantage really usable. All the modifiers must be on thumbs! This was done using the built-in remap feature.

Kinesis Advantage has a thumb cluster somewhat higher than Maltron. That may be a problem for you.
The excelent feature of Kinesis Advantage is on-the-fly key remap and macros. This does not need any OS support or additional programs.

Otherwise the meaning of the keys is defined in the keyboard layout in the OS. The keybaord sends only "scan codes" to the OS. What the "scan code" means is decided by the layout selected in the OS. It also defines what is the meaning of the shift layer (i.e. .how shift keys changes the meaning). You can define your own custom keyboard layouts for both Linux and Windows. E.g. I did it for windows (there was a tool for it (Microsoft Keyboard Layout Editor)). I think it can be done for Linux just by editing some xkb layout file. This was not really a priority for me since all my Keyboards from 2002 support on-the-fly remap in the firmware.

[PlayBox]

cherry switches arent the best they are mid

[Findecanor]

I forgot to link this list in my previous post: https://deskthority.net/wiki/ErgoDox#Availability
Some of these might not be around any more, but they are still listed for completeness' sake. (for e.g. if someone gets hold of one and asks about it)

[yorten]

I used Kinesis Advantage from around 2002 to 2014 when I switched to my custom version of Kinesis Advantage (Katy).

Katy looks cool!

Kinesis Advantage has a thumb cluster somewhat higher than Maltron. That may be a problem for you.

I'm inclined to agree. Taking a closer look, it actually looks quite uncomfortable.

Otherwise the meaning of the keys is defined in the keyboard layout in the OS. The keybaord sends only "scan codes" to the OS. What the "scan code" means is decided by the layout selected in the OS. It also defines what is the meaning of the shift layer (i.e. .how shift keys changes the meaning). You can define your own custom keyboard layouts for both Linux and Windows. E.g. I did it for windows (there was a tool for it (Microsoft Keyboard Layout Editor)). I think it can be done for Linux just by editing some xkb layout file. This was not really a priority for me since all my Keyboards from 2002 support on-the-fly remap in the firmware.

Thanks. I've done more research to understand the distinction between scan codes and key codes. However,
the Maltron model I have is still problematic. I'll try and explain better.

I used showkey --scancodes in a virtual console, so there is no X Windows interference, to see the actual scan codes from the kb. An example problematic physical key is the one labelled '*'/'['. When pressed on it's own, the scan codes are:

    0x2a 0x09 0xaa 0x89

These are actually the scan codes for shift and 8 on the same keyboard:

    0x09 0x89               # 8 press and release on its own
    0x2a 0xaa               # left shift press and release on its own

However, the '8' key has a label of '8'/'@'. When you physically press shift-8, the scan codes are:

    0x2a 0x03 0x83 0xaa
   
which are actually the scan codes for shift and 2 on the same keyboard!

    0x03 0x83               # 2 press and release on its own
   
The above means the physical shift key is special. The firmware is coded so that it will actually change the
scan code for the other keys, which is not how a standard US keyboard works.

When I try and configure xkb to swap the home/end keys with the shift keys, the home/end keys don't have the same
firmware trickery as the above and pressing the '*' key on it's own still sends '0x2a 0x09 0xaa 0x89'
which ends up being mapped to key codes 'home' and '8', because I've swapped home with left shift like so:

    xkb_symbols {
        key <LFSH> {         [         Home ] };          # Map left shift scan code to Home key code
        key <RTSH> {         [         End ] };             # Map right shift scan code to End key code
        key <HOME> {         [         Shift_L ] };       # Map home scan code to left shift key code
        key <END> {          [         Shift_R ] };         # Map end scan code to right shift key code
        modifier_map Shift { <HOME> };               # Make home key code act as a Shift modifier
        modifier_map Shift { <END> };                  # Make end key code act as a Shift modifier
    };

I found a post by MarkWilliamson which seems to confirm my difficulties: https://deskthority.net/viewtopic.php?p=24627#p24627

    "The main problem, layout-wise, is that AFAICT there's no way to completely remap it in PC-side
    software. This is because the controller actually handles layouts in order to produce different
    shifted/unshifted pairings to a standard keyboard (and in some cases, to ensure a key only has an
    unshifted scancode). I've not been able to find out a way of stopping it from doing this, which
    leaves me reliant on the built-in layouts
    ...
    I'd also quite like to fashion a more modern controller board that would solve my remapping problems
    and give native USB - doesn't seem like it should be so hard"
   
I found a work around by utilising xkb groups, basically the same as layers but xkb only supports 4,
with the first two taken by "no modifier" and "shift", and the latter 2 typically taken by the AltGr and
AltGr+Shift modifier combinations. Since I don't need the AltGr key, only US symbols, I mapped the shift
scancode to AltGr instead of mapping it to Home. So I can use group/layer 3 (AltGr) to map '0x2a 0x03
0x83 0xaa' to '*' and group/layer 4 to map '0xe0 0x47 0xe0 0xc7 0x2a 0x03 0x83 0xaa' (which is a 'home-*')
to '['. This won't work for anyone who needs the AltGr key for international symbols. Config looks like this:

xkb_keycodes {
    # Assign physical left shift key scan code to custom RLT2 symbolic key code
    <RLT2> = 50;    # left shift

    # Assign physical left shift key scan code to custom RLT3 symbolic key code
    <RLT3> = 62;    # right shift

    alias <ALGR> = <ALGR>;  # override existing alias that was mapping to RALT
}; 

xkb_symbols "maltron" {

    name[group1]="English (US) - Maltron L89 PS/2 modernization";

    # Make home and end act as left and right shift
    key <HOME> {         [         Shift_L ] };
    key <END> {          [          Shift_R ] };

    # Make Menu key (above PgUp) act as home.
    key <COMP> {         [         Home ] };

    # Make AltGR key (above PgDn) act as End.
    # TODO: something funny here. In Firefox, pressing AltGr followed by Menu will replace the page with
    # an empty one but I can't understand why AltGr is behaving like that.
    key <RALT> {
        type= "ONE_LEVEL",
        symbols[Group1]= [ End ]
    };

    # Make Home and End keys act as shift modifier
    modifier_map Shift { <HOME> };
    modifier_map Shift { <END> };

    # Make left shift key act as Level3 modifier. This is because some keys like */[ send a shift
    # modifier along, even when you aren't pressing shift. So changing this to be interpreted as a
    # Level3 modifier means we can effectively override level 3 in the group mapping and nullify the
    # modifier.
    key <RLT2> {
        type= "ONE_LEVEL",
        symbols[Group1]= [ ISO_Level3_Shift ]
    };

    # Same as above but for right shift key.
    key <RLT3> {
        type= "ONE_LEVEL",
        symbols[Group1]= [ ISO_Level3_Shift ]
    };

    # 2nd level:                   home+8 == @
    # 3rd level (RAlt):          * key == * since the shift scan code is mapped to the AltGr keycode
    # 4th level (RAlt+Shift): home+* == [
    key <AE08> {
        type= "FOUR_LEVEL",
        symbols[Group1]= [               8,        at,   asterisk,           bracketleft ]
    };

   ...


However, I've concluded software remapping is too problematic because it breaks down in so many scenarios:
1. Virtual consoles: xkb only configures X Windows, not the underlying linux kernel. I would need
   another solution for that.
2. Virtual machines: xkb settings don't automatically propagate to them. I have not investigated whether
   there's a workaround.
3. Windows machines
4. Possibly/probably remote shells: haven't tested given the above already broken use cases

Probably the better option would be to replace the micro-controller like MarkWilliamson says in their post.

[vvp]

Yes, xkb helps only for xwindow applications. That sucks. I'm sure keyboard layouts are handled also in a terminal (it is likely done by loadkeys).

I would say it is evil that Maltron is remapping shift layer of keys in firmware (sending a "macro" (i.e. a sequence of keys) even when only one keys is pressed). That will limit what you can actually do with xkb/loadkeys.
Btw. Kinesis Advantage supports macros as well in firmware. An user can define them and assign to a key combination but by default they are not used.

If you have an USB keyboard then you can follow the codes sent down the wire with usbdump. The codes are defined in USB usage tables Keybaord/Keypad Page (0x07). Almost all USB keywords are standard compliant USB HID keyboards. They behave according to the posted link.

The "scan codes" you looked at with showkey --scancodes are not the same as the codes sent from a standard USB keyboard. E.g. your scan code for "key 8" was 0x09 but USB HID code for "key 8" is 0x25.

Edit: Just some spelling fixes.

[yorten]

If you have an USB keyboard then you can follow the codes sent down the wire with usbdump. The codes are defined in USB usage tables Keybaord/Keypad Page (0x07). Almost all USB keywords are standard compliant USB HID keyboards. They behave according to the posted link.

Nice!

[granola bar enthusiast]

i got my kinesis advantage 360 pro today and am typing on it right now, if you like keywells and bendy curve curve with some minor tenting this has that but other then that kind of overpriced for a plastic dactyl manuform with tenting







zmk is fine, you can program it with zmk or use kinesis's visible zmk programer that does the annoying stuff for you, with the kinesis software its kind of like white mode qmk. you have to flash everytime you aer done. idk does what you want

[OddField]

Since you mentioned Glove80, this could be of interest to you https://kbd.news/Glove80-Rethinking-split-contoured-ergonomic-keyboard-1796.html

[anawilliam850]

Welcome to Geekhack!

Kinesis:
- Advantage2 and the wired Advantage360 do support remapping and macros on the keyboard itself. The wireless with ZMK is programmable in the way that you could modify its source code.

ErgoDox:
- The outer and "north" keys in the thumb clusters on the ErgoDOXen can be hard to reach because the cluster is not angled.
- The ErgoDox EZ is a commercialised variant of the original ErgoDOX, which is Open source. The original but not the EZ supports the option of splitting the 2u keys to get 8-key clusters, but as I wrote above, only four of them would be much usable. For the DIY:er, components have been available from many vendors, but many have gone away.

You could also check out the Dygma Defy, which has 8-key low-profile thumb clusters. It is only on pre-order with shipping expected in January, so there are no reviews yet.

There is also a large DIY scene... with people having designed their own keyboards and released as Open Hardware but most of the have had much fewer keys than an ErgoDox.
I think the most active forum for that is on Reddit: https://www.reddit.com/r/ErgoMechKeyboards/

Thanks!

[yorten]

Thanks everyone for the additional feedback. The Glove80 does indeed look interesting but I ended up getting a Keyboardio Model 100. The Glove80 wasn't available to order and I've had reliability issues with bluetooth before.

Pros:
1. totally solves my pinkie issues, with the shift key mapped to the thumb cluster

2. the reduced number of thumb keys versus the Maltron isn't a huge issue once I changed ctrl and shift to only act as modifiers on hold.

3. the thumb keys really do seem to follow a natural arc, at least for me

4. programmability via the chrysalis UI is pretty easy.

5. programmability and layers means I can make some often used punctuation characters and sequences much more comfortable.

6. linear keys are very smooth, albeit they are rather light so I find it a bit hard to avoid bottoming out. Still, it doesn't so far seem to give me joint pain like a non-mechanical keyboard would so it might be a non-issue.

7. individual led lit keys is very handy for layers, especially when tuning the layout and accessing less often used keys.


Cons:
1. I haven't found the octostands very useful. Due to the way they work, where you can only rotate them and doing so adjusts both the tenting and tilt simultaneously, there's really only one 'neutral' tenting position which I don't find comfortable. For now, I've swapped to a couple of small desktop speakers stand wedges instead but it's a stop gap measure because they're too narrow to be completely stable and I'm not sure if the angle is quite right, either. I'm having a hard time finding a comfortable position for my forearms. In contrast, I have zero forearm issues on a Maltron. This could also be due to the way the palm rests on the Maltron are angled.

2. Despite the thumb clusters being easy to reach in theory, I find touch typing with the thumb clusters to be hard and tend to have a lot of typos with them. I think there are multiple factors:
   - The bump on the home keys are very low on the key, below where my thumbs would naturally sit so it's odd and slow to try and find them. At some point I might try sticking something on them.
   - Dual use keys are potentially a bit unreliable, resulting in the opposite of the function I intended. However, this is potentially a PEBCAK issue because I'm not exactly sure when it occurs.
   - Every thumb key is almost too easy to reach: there is maybe too little tactile difference in how they feel versus the keys on the Maltron. However, this could just be because I've used the Maltron for so long and it's so ingrained in muscle memory now.

3. if your desktop usage means it's hard to leave the keyboard in the same position everyday, the split nature is a bit fiddly because the position and orientation will change frequently. This is potentially a contributor to my forearm discomfort as possibly I'm using a poorer positioning on some days. Compounding this is I'm not sure exactly which position is the best.

4. it's the first layer based keyboard I've used and I underestimated how hard it is to get used to switching layers, learning to sequence instead of chord and to work out the best key mapping. I'm not yet convinced it's 100% better than a full sized keyboard for me. It seems like there's tradeoffs both ways. I do appreciate why some would prefer it, though, since overall travel distance is decreased in exchange for longer sequences of key presses and given sequencing works very naturally when typing text, it probably should work well for everything else too, given sufficient practice. Also, layers do mean I can map some punctuation characters to better positions and reduce pinkie usage.

5. I think I've experienced the keyboard getting into a weird state and I had to unplug it but again I'm not 100% sure because it's not reliably reproduceable.


Overall, I'm at a productive speed now and the engineering quality to my naive eye seems pretty high.  However, the forearm discomfort is still unresolved so I'm tending to alternate with the Maltron. I'll see how it goes longer term.

[anawilliam850]

Hi!
Pros of ErgoDox EZ:

Programmable with powerful features like layers and tap/hold distinction.
Ability to choose your own switch type and replace switches easily.
Good community driven lineage and open source.
Supports flexible height, tenting and tilting.
Can distinguish toggled layers with shine model.
Cons of ErgoDox EZ:

Not contoured, which might not be as ergonomic as the Maltron.
Arbitrary shoulder separation might not be ideal and could result in the mouse being further away.
Wrist rests might not be ideal with tenting and tilting.
Only 6 keys per thumb cluster vs 8 on Maltron.
Pros of Kinesis Advantage 360:

Contoured and programmable.
Adjustable tenting and arbitrary shoulder separation.
Long history in the market.
Cons of Kinesis Advantage 360:

Limited switch and keycap options with the signature series.
Limited to wired connections and ZMK programming engine only available with Bluetooth model.
Key switches are not easily replaceable.