Keysym event in the text protocol

[Bill Spitzak]

On 07/28/2014 02:49 PM, Jasper St. Pierre wrote:

> Try looking at the code next time. It creates a temporary file, unlinks
> the file, writes the XKB description to it using xkb_map_get_as_string,
> and sends it over.

Okay I think I see this now. I'm not sure why there is a cutoff between 
sizes sent over the protocol and ones that are out-of-band like this, 
xkb data does not seem all that large. Making the protocol descritpion 
say that it is an out-of-band block of memory, instead of a file 
descriptor, may help but may also be unnecessary obfuscation.

> We already have "libinput for keyboards", it's called "libxkbcommon".

Yes that is why I am asking the question. Despite the obvious 
similarity, the plan is for a totally different arrangement of how 
clients talk to these two libraries.

The current scheme prevents devices, or RDP, or privileged clients such 
as the input method, or even the compositor, from producing fake 
arbitrary keysyms. This I think is going to be a very annoying 
limitation so I am trying to figure out what advantages there are that 
outweigh this problem.

> The reason that keyboards are crazy special is because they're a
> multitool, and I've answered this exact question before, *in a thread
> that you've replied to*! [0]
>
> The keyboard case is *hard* because it's a tool for language input,
> which already makes everything 100 times more difficult

You are describing what the input method will do. This is already a 
different process than the clients.

> and then you
> add on stuff like shortcuts like Ctrl+C / Ctrl+V which are
> position-based, and Ctrl+F for "find" which is language-based...

Okay I think I see what you are getting at, though I am unconvinced that 
any real clients will actually do this, clients are not going to 
interpret the keyboard layout, but may recognize alternative hardware 
they know about, but this could be done with a hardware id rather than 
an xkb configuration. Also it seems like a client could do 
keysym->keysym translation, they don't have to do keycode->keysym.

It seems like this should be implemented by having "Alt+V" translate to 
the "Paste" keysym. This moves all the keyboard mapping to a common 
location in the keyboard descriptions. There is no more reason the 
client should figure out that Alt+V is paste than it should figure out 
that shift+5 is "%", other than historical legacy. This idea is not as 
unworkable as you may think if the "V" keysym is also returned as the 
unshifted value, and if keysyms are replaced with small strings.