Keyd is remapping Right Shift to Left Shift, even with a (nearly) blank configuration file

[Pickelgold]

Keyd is mapping Right Shift to Left Shift (Left Shift is still mapped to Left Shift) even with only the following configuration:

[ids] *

Steps to reproduce:

1. While keyd is stopped, verify that left shift and right shift are independently detected using https://keyboard-tester.com/
2. Start keyd with the above minimal configuration
3. Retest using https://keyboard-tester.com/. Pressing either left shift or right shift should both result in left shift being shown.

Why is this a problem?

• The USB HID specification, among others, has different codes for left shift and right shift
• Some applications, such as certain games and productivity software, allow users to assign different key bindings to left shift and right shift

As to my knowledge, this bug extends only to shift, not to alt. I wasn't able to test the behavior for control.

[sigprof]

I see the same behavior. Testing with xev shows that the bug also affects the Ctrl and Windows keys (the latter are mapped to the Super modifier in my config); when keyd is running, I get Shift_L, Control_L and Super_L for both left and right side keys. But the right Alt key (mapped to ISO_Level3_Shift) is handled properly (separately from the left Alt, which is mapped to Alt_L).

This breaks at least things like XbkOptions shift:both_capslock, which rely on both Shift keys sending distinct keycodes.

[sigprof]

After some more reading of the documentation this seems to be “working as designed”, just the design does not take the potential issue of ignoring the modifier side into the account.

The default configuration of keyd is actually included in the source code; after removing the C string escaping it is:

[aliases]
leftshift = shift
rightshift = shift
leftalt = alt
rightalt = altgr
leftmeta = meta
rightmeta = meta
leftcontrol = control
rightcontrol = control

[main:layout]
shift = layer(shift)
alt = layer(alt)
altgr = layer(altgr)
meta = layer(meta)
control = layer(control)

[control:C]
[shift:S]
[meta:M]
[alt:A]
[altgr:G]

So both Shift keys are actually mapped to layer(shift), and the shift layer enables the S modifier, which corresponds to the left Shift key. The same thing is done with Meta and Control keys. Only Alt keys enable different layers with different modifiers.

If you are not using the shift layer to remap Shift+something combinations, you can remap the right Shift key to send the proper event for the right Shift directly instead of enabling a layer:

[main]
rightshift = rightshift

The same thing could be done for rightmeta and rightcontrol.

But if you actually need to remap some key combinations with Shift/Control/Meta and want those mappings to work even when the right side Shift/Control/Meta keys are pressed, you would either need to live with the modifier being reduced to the left side one, or patch keyd to add support for the right side modifiers (e.g., add mod names like RS/RC/RM, and then define layers like [rightshift:RS]). This would require duplicating the bindings in both layers though (shift and rightshift, etc.).

[DamianFekete]

I'm affected by this issue as well, I can't use right-control key in different keyboard shortcuts in far2-wl after installing keyd.

Related I guess: https://github.com/rvaiya/keyd/issues/114

[5long]

For me it's virt-manager: virt-manager defaults to right control to grab focus away from virtual machine consoles. Although I can manage with rightcontrol = rightcontrol, the default behavior is pretty surprising (in a slightly annoying way).

[wwalker]

I'm having the same problems. screenkey requires pressing both left and right shift keys as a toggle.

gnome-boxes requires "right control" and "right alt" pressed simultaneously.

So, I am adding this to my default.conf:

[main]

rightsuper   = rightsuper
rightshift   = rightshift
rightcontrol = rightcontrol
rightalt     = rightalt
rightaltgr   = rightaltgr

Is there any downside to this?