Keysym event in the text protocol

[Bill Spitzak]

On 07/28/2014 05:14 PM, Daniel Stone wrote:

> the fact that our original design for the keyboard
> interface started off with keysym events _only_ (not on mailing lists, I
> don't think - was an in-person meeting a couple of years ago) but we
> couldn't figure out a way to make it work, I'm pretty confident in this.

That is very useful to know.

A densely-packed index using keycode may be much more easy to use than 
the sparse keysym enumeration. There are also bad keyboard definitions 
where more than one key translates to the same keysym, so the 
translation cannot be inverted. I would guess these are the reasons 
behind the decision.

I would like to see character composition removed from xkb so that 
western programmers are forced to use the input method, this would also 
remove most of the code smell of having a per-client copy of the 
xkb_state, and allow a preview of "dead keys". Not sure what to do with 
legacy X applications that are not using the X input method, however.

I would also like to see consistency with other devices. Currently 
everything that is not a "keyboard" produces identifiers that are more 
like keysyms than keycodes. These should probably also produce a 
densely-packed index number and an xkb mapping. The reason is devices 
that wish to emulate keyboard keys (imagine the soft buttons that are 
around the edges of drawing tablets). You could say that it is the 
client's responsibility to handle this but this is just not going to 
happen when the author of the software does not have an instance of the 
device. But rather than the old method of faking keyboard events, the 
device could just send it's own xkb mapping for it's buttons, the client 
would work but have the capability of telling the events came from the 
device.