rvaiya
ISO level 5 shift support
I'm coming from using an Apple keyboard on macOS and in such a configuration, ISO level 5 shift (as identified by the KDE input device layout for my keyboard) allows me to type many, many characters per key; for instance, ISO_level5_shift+s = ß and ISO_level5_shift+shift = §.
Simply adding ISO level 5 shift support would allow one to do this without reserving a key to be "untouched" so that it can be seen as an ISO level 5 shift by the system.
If I'm not mistaken, ISO_Level_5_Shift is a display server concept, ie something that keyd can't send as is, because keyd only deals with keycodes (as if it were a hardware keyboard). I'm afraid reserving a key and using the XKB options to map it (or using a layout that already does so) is the only way.
Hello,
I am not sure that I got the answer, but I might have a retated issue.
on linux, altGr is considered « iso_level_3_latch » or sometime « iso_level_5_latch »
Like a few french people that are using an optimise keyboard layout, I have an iso_level_x_switch key (x can be set to 3 or 5, on my layout, it is 3 currently). This key is very usefull to make all kind of diacritic like è é à ù ê î û ß ç or typographic characters like ’ or — –.
The issue I am facing, is that the dead key (iso_level_x_switch, but let's call it 1dk) is no working properly on key that have mod-taps or layer-taps.
For instance, I have the typographic apostrophe ’ on 1dk+space and use space on hold as a nav layer.
If keyd is active, 1dk+space only gives me a regular space instead of the typo apostrophe.
Similarly, without keyd activated 1dk+e → è but if I have keyd activated with e = overloadt(control, e, 200) , then 1dk+e → e
That is a related but different problem --- but good to point out! Maybe worth creating a separate issue for it.
I would guess it is because the layer activation inserts extra keypresses between the AltGr activation and the overloaded key (keyd knows nothing about how AltGr is going to be interpreted by your display server). If that's true, you can probably work around it by explicitly overriding any overload that occurs after pressing rightalt:
rightalt = oneshotm(rightaltlayer, rightalt)
[rightaltlayer]
e = e
a = a
# ... etcetera
... but that is very much a workaround. Also, just based on my first guess :P