[RFC PATCH libinput 1/2] Add a string-based input API
Jasper St. Pierre
jstpierre at mecheye.net
Tue Dec 9 15:48:07 PST 2014
You bring this up every single time somebody mentions keyboard input, and
every single time we explain in excruciating detail exactly how you're
wrong, why you're wrong, and why the use cases you cite are broken work
Please stop bringing it up. This is your second warning.
On Tue, Dec 9, 2014 at 3:45 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel