On Fri, Apr 07, 2017 at 01:43:57PM +0300, Pekka Paalanen wrote: > On Fri, 7 Apr 2017 14:04:40 +1000 > Peter Hutterer <[email protected]> wrote: > > > For the initial patchset, see > > https://lists.freedesktop.org/archives/wayland-devel/2017-March/033626.html > > For a high-level description, see > > http://who-t.blogspot.com.au/2017/04/inputfd-protocol-for-direct-access-to.html > > > > This is a relatively unexciting update, the notable bits are: > > * instead of having a per-device type get_seat_* request, we now have just a > > basic get_seat() request that returns all inputfd-capable devices. This > > allows for mice, keyboards, etc as well without having more requests > > * the property description has a link to the github repo i started for the > > dictionary > > * the fd was split into a read/write fd to allow for pipes, the type was > > extended for an evdev-protocol-carrying pipe. (I'm not convinced this > > is good enough yet, just as a note) > > Hi, > > I don't understand the need for two fds. Yes, pipes are > one-directional, but one could use a AF_UNIX socket for bidirectional > comms (socketpair(2)). Having a second pipe fd for writing does not > allow for a synchronous command a la ioctl() anyway. > > You have read and write fds in the same event. Wayland is > incapable of sending an argument of type fd that is not actually a real > open file descriptor. This means that if the write fd is not needed, > one still needs to create a valid open fd, send it, and close it. > > Even if you send the same fd in both arguments, the receiver will > receive two different valued fds. Determining if they are the same > underlying "file" is... I don't actually know how to do that. Something > about comparing fstat(2) information. > > We had the problem with the linux_dmabuf protocol, where one needs > to send a variable number of fds. We solved it by sending one event per > fd. >
ftr, I've reverted this locally again, so we're back down to one fd, thanks. Cheers, Peter > > > > This addresses some of the immediate comments. The big list of TODO is: > > * LED control, force feedback, and other write-back channels that don't work > > on the fd but go through sysfs > > * battery status and other notifications > > > Thanks, > pq _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
