geekhack Community > Ergonomics
Alternatives for long time Maltron user?
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:
--- Quote from: vvp on Thu, 27 October 2022, 07:05:47 ---I used Kinesis Advantage from around 2002 to 2014 when I switched to my custom version of Kinesis Advantage (Katy).
--- End quote ---
Katy looks cool!
--- Quote from: vvp on Thu, 27 October 2022, 07:05:47 ---Kinesis Advantage has a thumb cluster somewhat higher than Maltron. That may be a problem for you.
--- End quote ---
I'm inclined to agree. Taking a closer look, it actually looks quite uncomfortable.
--- Quote from: vvp on Thu, 27 October 2022, 07:05:47 ---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.
--- End quote ---
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:
--- Quote from: vvp on Sun, 30 October 2022, 09:49:00 ---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.
--- End quote ---
Nice!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version