On Mon, Apr 24, 2017 at 10:57:37AM +0300, Pekka Paalanen wrote: > On Sun, 23 Apr 2017 09:47:20 -0700 > Roderick Colenbrander <[email protected]> wrote: > > > We originally discussed maybe using pipes and now more unix domain > > sockets for 'non kernel evdev fds'. As part of the discussion we > > realized ioctls wouldn't be available. Thinking about it some more, I > > think the lack of ioctl support is problematic. Sure we can use fds to > > send 'struct input_event' over, but EVIOCGABS is critical for > > determining capabilties and value ranges. Many others are useful too > > like the revoke ones. How should this be dealt with? > > Hi, > > whether or not you need two file descriptors for communication depends > on whether you need an out-of-band, perhaps blocking from the client > point of view, communication channel. Ioctls essentially are exactly > that, a blocking out-of-band channel. > > The downside of a secondary communication channel is that it will be > hard to correlate between messages on the two channels. If you issue an > "ioctl" that somehow changes the content of the messages you are > receiving, how do you know which incoming input events are with the new > setup? That would need to be taken into account already when designing > the input event (primary communication channel) messages. Whether evdev > has any of this, I do not know.
evdev has some flushing during ioctls, but it's been prone to race conditions in the past. I can't remember whether this has been fixed since but libevdev still has the code for it. see section "Discarding events before synchronizing" https://www.freedesktop.org/software/libevdev/doc/latest/syn_dropped.html This hasn't been much of an issue yet because we mostly care about capabilities on startup, so whether a key is down on the initial ioctl doesn't matter, we just drop that event and no-one minds. It's more of a problem for multitouch, especially when we're not reading fast enough and trigger a SYN_DROPPED but that happens only rarely. SYN_DROPPED can happen in the kernel because the buffer is only a few events big but on a custom fd/protocol, we should never lose events anyway, so that problem goes away. TLDR: send capabilities once before the first event and we're good. Cheers, Peter > If there is only one communication channel, the replies to control > messages will arrive to the client between input events, which > makes it implicitly obvious which input events are affected by the new > control setting. The downside of a single channel is that implementing > "blocking ioctls" requires at least receiving and buffering, if not > dispatching, all input events until the reply to the "ioctl". If you > buffer incoming events anyway, this shouldn't be a problem. > > OTOH, this gives one the opportunity to have non-blocking "ioctls". The > client or the application can continue doing its normal operations > until the display server manages to reply. The "ioctls" are not going > directly to the kernel, there is at least one process in between, which > means their latency is completely different compared to a direct evdev > device usage. > > In any case, as there is no way to have actual ioctls work aside from > creating evdev device nodes via uinput (AFAIK), you need to design a > protocol to mimic ioctls. > > I have somewhat lost sight of your use case for now, so I'll refrain > from making recommendations this time. I hope this at least clarified > the alternatives. > > > Thanks, > pq _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
