[RFC PATCH libinput 1/2] Add a string-based input API
spitzak at gmail.com
Tue Dec 9 15:45:02 PST 2014
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
More information about the wayland-devel