On Tue, 2017-04-18 at 14:05 +1000, Peter Hutterer wrote: > 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/0 > > > 33626.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.
Do you have an idea on how we could extend the protocol to handle LEDs, and possibly other associated non-joystick devices? That seems to be about the only blocker left. Battery is just one other property we could feed to the device, but we'd need a way to pass it to the client without a connection/disconnection cycle. "update" event? > 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
