[RFC v2 wayland-protocols] inputfd - direct input access protocol

[Pekka Paalanen]

On Sun, 23 Apr 2017 09:47:20 -0700
Roderick Colenbrander <roderick at gaikai.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170424/306060dd/attachment-0001.sig>