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

[Peter Hutterer]

On Mon, Apr 24, 2017 at 10:57:37AM +0300, Pekka Paalanen wrote:
> 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.

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