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. 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
pgp635emk3OAG.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
