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.
