[RFC PATCH libinput 1/2] Add a string-based input API

[Bill Spitzak]

On 12/09/2014 12:48 AM, Hans de Goede wrote:

> No this is about input-method like functionality.

Okay, in that case I think the api should be designed such that a text 
editor gets the UTF-8 to insert in *exactly* the same way whether the 
language is English or Chinese or Russian and whether or not this device 
is being used. This includes things that are often built into clients, 
such as compose keys and typing "alt+u+digits" to insert random Unicode 
points. All of these should be done by the input method api.

> Currently (IIRC) these devices do double translation, so the ready to
> use text gets converted into keycodes again, and then back, which is
> bound to be lossy, and a bad idea in general, so we want to get rid
> of the double translation for these.

I certainly agree this is a problem with how Wayland is being done now. 
My main concern is with remote display on some device that delivers 
keystrokes already translated into keysyms.

My personal feeling is that it would be better to have libinput or the 
compositor look up keysyms, rather than clients link with xkb. No more 
or fewer events are sent than currently, but attached to key transitions 
are the keysym (possibly none) produced by that transition. This would 
allow arbitrary code installed along with the device to do the 
translation which would allow your input device to work.

There is however very strong disagreement with this idea from the 
Wayland developers.