[RFC XI 2.1 - inputproto] Various fixes in response to Peter Hutterer's review

[Daniel Stone]

Hi,
For those of you not on IRC, Chase and I had a fairly long, if
meandering, discussion on all of this stuff: I said I'd summarise my
position and send it out to the list.  I think we're fairly close to
agreeing though.

On Fri, Nov 19, 2010 at 01:52:39PM -0500, Chase Douglas wrote:
>  A touch event is not delivered according to the device hierarchy. All touch
> -events are sent only through their originating slave devices.
> +events are sent only through their originating slave devices. However,
> +dependent touch devices will only emit touch events if they are attached to a
> +master device. This is due to the touch delivery being dependent on the
> +location of a cursor.

I find this fairly worrying.  The main reason not to send touch events
through MDs is that it would necessarily cause a storm of
DeviceChangedEvents.  However, we can handwave this away in the spec by
avoiding listing touch classes on MDs, and stating (as my original
revision did) that touch capabilities must be taken from the SD, as
given in sourceid of the event.

The reason this concerns me is that it creates (even more) divergent
event delivery paths for touch events vs. normal events.  This is a pain
in and of itself when trying to understand event flow, which can be
difficult at the best of times, but especially if we're going to be
generating synthesised pointer events from touch events.  This would
mean that the same touch would be generating two events which go down
completely separate delivery paths.  The worst case here is that one
touch causes two clients to react and do two different things: this
would be bad bad bad bad bad.

So I'd be much happier if touch events were also delivered through the
MDs as well.

> +Touch events are broadcast to all clients registered for touch events on a
> +set of windows. The window set is determined at the beginning of each touch
> +and depend on whether the touch device is a direct or dependent device.
> +
> +Direct device window sets contain the windows from the root to the child
> +in which the touch originated.
> +
> +Dependent device window sets depend on whether other touches are active. If
> +other touches are active, the window set of the other touches is used. In this
> +manner, all dependent device touch events are sent to the same set of windows.
> +If no other touches are active, a new window set is created for the touch. The
> +set is formed in the same manner as direct devices, but location used is the
> +cursor position of the attached master device. If the touch device is floating
> +it will not emit any touch events for the new touch.

This is a nice touch (sorry) - I like it.

> +Appendix B: Known Missing Features
> +
> +???  Any form of grabbing or grab-like semantics for touch events

Except that we do already have grab-like semantics: the proposed
delivery mechanism is to start at the root window and work its way down
to the deepest child, with delivery progressing as clients express
disinterest in the event.  IOW, exactly like grabs, except that all
clients get deliveries, but all but one are told not to act on them.

Since this matches our existing grab semantics so closely, I've proposed
to Chase that touch delivery act exactly as normal event delivery does
today: start with a list of grabs, going root-to-child, and then when
that's exhausted, work your way through a list of normal selections,
going child-to-root.

Chase's proposed usecases are highly WM-centric, anticipating that the
WM (or an external gesture recogniser) does global gesture recognition
(e.g. 'this is a pinch action'), and informs clients out-of-band.  My
proposed usecases are all quite app-centric; I still believe the apps
can use a common library to do this, and that there's no need for
another client to get involved, which adds at least one roundtrip.

So, his plans are best served by root-to-child delivery, whereas mine
are best served by child-to-root.  In the best tradition of (UNI)X, I
suggest we do both, not just to keep everyone happy, but because it's a
1:1 match for the input delivery semantics we have today.

The one thing that still concerns me here is promiscuous event sending:
where every client that has selected for the events receives them
whether it wants to or not.  The reason given for this is to enable
low-latency fallthrough, so that if the WM has a touch grab and decides
it doesn't want the touch events, the client doesn't have to round-trip
to the server to get a potentially huge buffer of all the touch data.

This is fine in theory, and I'm all for avoiding the roundtrips, but I
do worry that we've replaced one problem (buffering the touch data,
which may be huge, in the X server), with several problems (buffering
the touch data, which may be huge, in n clients).  Since a client would
be able to declare disinterest in a touch stream and pass it on to the
next client at any time, every client would have to buffer every touch
stream, and be ready to act on it.

Chase and I talked quickly about hints for this: clients being able to
say 'please do not send me any more events from this touch stream', for
cases like a global gesture recogniser that has decided it sees nothing
of use to it, as well as the corresponding 'please do not send any other
clients any more events from this touch stream', for when a client has
decided that the touch stream is meaningful to it, and that it won't
pass it on.  This would pretty much solve my concerns, except that it's
an irritating burden for app developers, and would probably be
reasonably difficult to get correct.  The penalty for forgetting to do
it, or getting it wrong, would be waking up every app with a touch
selection in the window trace every time you have an event, as well as
making them copy in the touch data, etc.

Anyone else have any thoughts?

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101201/293dd66a/attachment.pgp>