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

Peter Hutterer peter.hutterer at who-t.net
Mon Apr 24 23:51:52 UTC 2017

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"

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.


> 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

More information about the wayland-devel mailing list