1

Due to complex infrastructure, I am experiencing an issue where hitting AltGr on my keyboard results in a stray Control_L signal being received on the Linux desktop on the receiving end. The issue has apparently been around in some way at least since 2012, and is described in VMware KB article 1022454 (only available through archive.org).

I can confirm that the manual workaround mentioned there works:

Use this key combination for AltGr+<key>:

  • Press and hold AltGr.
  • Press and release Ctrl.

Note: The Ctrl key nullifies the Control_L event.

  • Press and release <key>.
  • Release AltGr.

The other workarounds mentioned are irrelevant/outdated/don't work.

I can't do anything about the infrastructure components in between. Is there anything I can do in my XKB config to ignore the stray Control_L that is received in these cases?

I don't think I ever combine Ctrl and AltGr, so simply ignoring Control_L in this specific case would probably solve the problem for me.

1 Answer 1

1

It might be easier to do this at a lower level, below XKB – the X server reads key events from /dev/input, and there are several tools to pre-process events coming from there. Interception-tools is one such filter, evremap is another, there is a longer list.

(They all work by creating a new virtual input device, while the X server needs to be configured to ignore the real device.)

1
  • Reading about evremap and some of the other tools, it seems evremap can remap from a key combination to a single key, while several of the other tools can't do that. I'll choose this as the answer as soon as I get it tested. For reference to others, the config appears to use keyboard names as defined in linux headers include/linux/hil.h, and I think this config might resolve the issue I'm having: [[remap]] input = ["KEY_RIGHTALT", "KEY_LEFTCTRL"] output = ["KEY_RIGHTALT"]
    – ketil
    Commented May 15 at 6:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .