Bdtyktl

Assume I hold the 3 keys E, R, F at once, in that order.

Because of key ghosting, the keyboard cannot distinguish that combination with other combinations (probably ERFG, ERG, or EFG), and assume that only 2 keys E and R are pressed.

I understand that it is a hardware limitation. However, is it possible to map that keyboard state to another combination, such as ERF?

In other words, I want that whenever I hold ERF or other key combinations indistinguishable from ERF, the system register that ERF are held.

For reference, my OS is Arch Linux and my keyboard model is Fühlen L411.

If the keyboard works without additional (custom or vendor-specific) drivers just as a USB keyboard, then I think it's... partially possible.

There is Device Class Definition for Human Interface Devices (HID) document from usb.org Document Library. These are the relevant parts:

Page 62, Keyboard Implementation [emphasis mine]:

The following are the design requirements for USB keyboards:

• Non-modifier keys must be reported in Input (Array, Absolute) items. Reports must contain a list of keys currently pressed and not make/break codes (relative data).




• [...]




• The keyboard must send data reports at the Idle rate or when receiving a
  Get_Report request, even when there are no new key events.




• The keyboard must report a phantom state indexing Usage(ErrorRollOver) in
  all array fields whenever the number of keys pressed exceeds the Report
  Count. [...] Additionally, a keyboard may report the phantom condition
  when an invalid or unrecognizable combination of keys is pressed.



• 
  

  [...]

  
  
  

  Key Event   Modifier Byte  Array  Array  Array  Comment
  
  ---------------------------------------------------------------------
  
  None        00000000B      00H    00H    00H
  
  RALT down   01000000       00     00     00
  
  None        01000000       00     00     00     Report current key
  
                                                  state even when no
  
                                                  new key events.
  
  A down      01000000       04     00     00
  
  X down      01000000       04     1B     00
  
  B down      01000000       04     05     1B     Report order is
  
                                                  arbitrary and does
  
                                                  not reflect order of
  
                                                  events.
  
  Q down      01000000       01     01     01     Phantom state.
  
                                                  Four Array keys
  
                                                  pressed. Modifiers
  
                                                  still reported.
  
  A up        01000000       05     14     1B
  
  B and Q up  01000000       1B     00     00     Multiple events in
  
                                                  one report. Event
  
                                                  order is
  
                                                  indeterminate.
  
  None        01000000       1B     00     00
  
  RALT up     00000000       1B     00     00
  
  X up        00000000       00     00     00 
  
  

  
  

NOTE This example uses a 4-byte report so that the phantom condition can be more easily demonstrated. Most keyboards should have 8 or more bytes in their reports.

Note although "most keyboards should have 8 or more bytes in their reports", a keyboard "may report the phantom condition when an invalid or unrecognizable combination of keys is pressed". This means if the keyboard itself cannot recognize the combination (e.g. the internal wiring make some key combinations indistinguishable even for the keyboard electronics), it reports the phantom state in all array fields.

Moreover, you cannot tell one phantom state from the other, even if the keyboard itself can (e.g. all phantom states that include E may be distinguishable from all phantom states that include M, still the keyboard has to report them identically to obey the specification). The only useful information you could use is the last non-phantom state.

In general keyboard input is processed as scancodes, then keycodes (see this article on keyboard input). Scancodes are press/release events rather than absolute data. Since reports from a USB keyboard "must contain a list of keys currently pressed and not make/break codes", I guess it's the driver that translates reports to scancodes.

I don't know if phantom state is reflected by scancodes. I expect it is not, but I cannot check this right now (the answer will be edited). I tried to test with showkey -ask (tty2 and X11) and xinput --test (X11) if phantom state is reflected by scancodes, keycodes. I used both my laptop keyboard (which probably doesn't use USB, no trace in lsusb) and an external USB keyboard. There was no indication that phantom state is reported at this level. If I'm right, all "normal" ways of remapping keys won't work for you.

But if you wrote your custom driver that has access to reports sent by your keyboard then you could definitely detect phantom states. However, due to limitations discussed above, the best you could do is:

• making any phantom state act as if E+R+F were pressed;


• making any phantom state immediately after (non-phantom) E+R act as if E+R+F were pressed.

Your best bet is to define a Custom Console Keymap.

Note that this will only work if Keyboard ghosting is not already happening on the Hardware Level, ie. the Keyboard does not send Events for your Keys E, F, R but only for one of the three keys, when pressed simulataneously.

You can check what keycodes / scancodes (-s) are generated by your keyboard when calling 'sudo showkey' or 'sudo showkey -s'.