Keysym event in the text protocol
Jasper St. Pierre
jstpierre at mecheye.net
Mon Jul 28 14:49:20 PDT 2014
On Mon, Jul 28, 2014 at 11:36 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Yes I saw that, but it is a file descriptor. My reading was that a client
> machine must have somewhere in it's file system every possible keyboard
> that could be on a remote machine. That is actually what led to my question.
>
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.
When we finally have memfd in the kernel, we could use that instead of
mmap'ing an anonymous file.
Seriously, the code is *right there*, and you can't be bothered to actually
figure out what it does?
> I suppose the xkb description can be sent: the local compositor would
> aquire the file the first time it connects to a remote compositor. I would
> then be concerned about loading an interpreted file from an untrusted
> source, but I guess xkb descriptions are simple enough that this can be
> made safe.
>
XKB descriptions are declarative, not interpreted.
> What I am really trying to get an answer to is what is special about
> keyboards. Everybody seems to be in agreement that the compositor will call
> libinput and translate raw evdev events from touchpads into something more
> useful. Surely if there is some advantage to the xkb scheme it would apply
> equally to touchpads, and the compositor would send raw events and clients
> would link to libinput and read touchpad description files.
>
We already have "libinput for keyboards", it's called "libxkbcommon".
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]
Keyboard layouts are dynamic and have cultural influence. Nobody has
different "touchpad layouts" which they switch to at runtime to enter
different "touchpad input". Nobody has "touchpad input methods" which let
them find the gestures they're looking for from a dropdown.
The keyboard case is *hard* because it's a tool for language input, which
already makes everything 100 times more difficult, and then you add on
stuff like shortcuts like Ctrl+C / Ctrl+V which are position-based, Ctrl+F
for "find" which is language-based, and then geometry-based input like
"WASD" where it makes a nice convenient arrow shape on the left hand, and
you want that to be "Q8ZA" or whatever on a Dvorak keyboard instead.
[0]
http://lists.freedesktop.org/archives/wayland-devel/2013-November/012029.html
On 07/28/2014 10:58 AM, Jasper St. Pierre wrote:
>
>> On Mon, Jul 28, 2014 at 7:44 PM, Bill Spitzak <spitzak at gmail.com
>> <mailto:spitzak at gmail.com>> wrote:
>>
>> I am just going to have to study this further, because I am still
>> completely stumped as to why so many people think this is an
>> acceptable solution.
>>
>> This sounds to me like either the ability to transmit an entire xkb
>> description across the wire is added to the wayland protocol
>>
>>
>> Bill. Please. Can you at least *look* at the current protocol before you
>> write your current emails? Because this is why we get frustrated.
>>
>> http://cgit.freedesktop.org/wayland/wayland/tree/protocol/
>> wayland.xml#n1508
>>
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140728/415c40b8/attachment.html>
More information about the wayland-devel
mailing list