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

[Stephan Sokolow (You actually CAN reply)]

NOTE: I'm not sure what my current status with the list is, so this 
could take a LONG time to show up in the list if it gets stuck in the 
moderation queue.

On 17-04-24 03:57 AM, Pekka Paalanen wrote:
> 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.

Just a point to keep in mind that this would have to be clearly and 
explicitly stated in the spec.

Otherwise, it'd be perfectly possible for an implementer who's doing a 
lot of async-style coding or multiplexing on the compositor side to 
produce something spec-compliant but with the same downsides as a 
multi-channel approach.

In fact, given the desirability of minimal latency for things like 
head-tracking and high-resolution input devices, I think that'd be a 
significant risk purely as a side-effect of someone not realizing that 
removing/shrinking buffer X in some codebase breaks the spec by breaking 
ordering enforcement.

(So, really, the best way to think about it wouldn't be "ordered vs. 
unordered" but "Is it the responsibility of the compositor or the client 
to enforce ordering?" (With the latter requiring events to either have 
timestamps or some other dependency/state-tracking information.))

-- 
Stephan Sokolow

Note: My e-mail address IS valid. It's a little trick I use to fool
"smarter" spambots and remind friends and family to use the custom
aliases I gave them.