Comment 20 for bug 543065

> That only works if you have less than 255 possible keys.

Yes. That can only work if you have less than 255 actual keys. You can still have more possible kernel key codes and assign X keycodes dynamically for actually existing keys. It can work, if only xkb will use keycodes directly and you will modify xkb table.

> The keysym is not sent with the event.

It means that xkb is completely in user level, isn't it?

There is a third ugly hack method inspired by "Extended MEDIUMRAW Mode" in Linux kernel. I guess that this one can be used to transfer keycodes without breaking protocol compatibility, but it will introduce need to modify input handling:

3) Use virtual key sequences to transfer more data:

Define say 17 reserved keys in the range < 256 - one ExtraEscape and sixteen ExtraData0-ExtraDataF.

Process keypresses in the following way:

- If the input keycode is from range 0-255 (except these 17 keys), handle it in a standard way.

- If the input keycode is outside this range, send it as a sequence of more keycodes: Each event can represent 4 bits, 4 events will create all 16 bits.

- These four events may be release only. If you allow press events as well, then it will need no ExtraEscape.

This method will still break applications waiting for "single press/release of any key".