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