[PATCH] Add touch events to protocol.

Josh Leverette coder543 at gmail.com
Thu Jul 7 12:14:13 PDT 2011

With the exception of incoming phone call scenario, how does one go about
cancelling a touch event anyways? Unless I'm wildly mistaken, this is an
unlikely scenario. The way you normally cancel touch events is you touch
down on a button, then move your finger off the button and lift up, but that
is all handled by the application itself, not the window manager. Correct?
Therefore applications should always work under the assumption that the
touches will not be cancelled unless they implement cancellation support,
but for the rare even that they receive the cancel event from the WM, just
commit whatever actions have been completed thus far. (treat it as the
fingers lifting off the screen)

2011/7/7 Chase Douglas <chase.douglas at canonical.com>

> On 07/07/2011 09:52 AM, Kristian Høgsberg wrote:
> > 2011/7/7 Chase Douglas <chase.douglas at canonical.com>:
> >> On 07/07/2011 07:28 AM, Kristian Høgsberg wrote:
> >>> On Tue, Jul 5, 2011 at 1:08 PM, Chase Douglas
> >>> <chase.douglas at canonical.com> wrote:
> >>>> On 06/29/2011 07:54 AM, Laszlo Agocs wrote:
> >>>>> +
> >>>>> +    <!-- Indicates the end of a contact point list. -->
> >>>>> +    <event name="touch_frame">
> >>>>> +    </event>
> >>>>> +
> >>>>> +    <!-- Sent if the compositor decides the touch stream is a global
> >>>>> +         gesture. No further events are sent to the clients from
> that
> >>>>> +         particular gesture. -->
> >>>>> +    <event name="touch_cancel">
> >>>>> +    </event>
> >>>>>     </interface>
> >>>>
> >>>> I never understood the concept behind "touch cancel". If I'm a client,
> >>>> I'm supposed to sit around waiting for a touch cancel event at any
> >>>> point? Is it bounded in time, or could I get a touch cancel event 20
> >>>> seconds into a stream of motion events? I don't see a way to get
> around
> >>>> explicitly conferring whether a touch  is "accepted" or "rejected"
> >>>> (implicitly or explicitly) at some point, which is what XInput 2.1 is
> >>>> aiming to do. However, the exact mechanisms may be different in
> Wayland
> >>>> since we don't have the old X cruft to deal with.
> >>>
> >>> Yes, any stream of touch event, no matter how long, can be cancelled
> >>> by the compositor at any time.  The use cases are when the compositor
> >>> recognizes a global gesture (three finger pinch to go to home screen
> >>> or so) or if an important system event happens (incoming phone call or
> >>> such).
> >>>
> >>> Whether and how to undo the effects of the touch events up until the
> >>> cancel is an application policy decision.  If you're just scrolling a
> >>> browser window, it probably doesn't make sense to undo the scrolling.
> >>> Even if you're, say, painting in a paint app, it probably makes sense
> >>> to just treat cancel as end and commit the paint action, provided the
> >>> user can just undo that if necessary.
> >>
> >> I think undoing automatically would be better, but I'm not a paint app
> >> developer, and it's beside the point :).
> >>
> >>> In general, undoing the touch stream is similar to undo, which most
> >>> apps are already handling.  From an application point of view, if you
> >>> have to handle unowned events (that's the XI 2.1 term, right?) for a
> >>> small initial window (100ms, 3s or a week), you end up with the same
> >>> application side complexity, and I don't see what it is apps can do
> >>> differently once they know that the remaining event stream belongs to
> >>> them.
> >>
> >> Lets say the WM responds to a short flick gesture. The user performs the
> >> entire gesture before the WM has decided whether it matches the flick
> >> pattern. Now we've sent the touch stream in its entirety to the wayland
> >> client, and we have to cancel it after the fact.
> >>
> >> This leaves the client in a precarious situation. It has received the
> >> entire stream of touch events for a touch, but it doesn't yet know if
> >> the stream might be cancelled or not. The client may be buffering the
> >> application state so it can undo changes if it receives a touch cancel.
> >> We don't want to force it to buffer state changes forever, so we must
> >> provide some guidance to developers on how to handle this situation. Do
> >> we say that after 1 s the client can assume the touch stream is theirs?
> >> That's hackish and may produce annoying side effects if the machine is
> >> swapping and goes "dead" for a few seconds.
> >
> > The touch stream ends with either 1) all touch points up or 2) touch
> > cancel.  If the application receives up events for corresponding to
> > all touch down events, the touch stream belongs to the client.
> What do we do when the user performs a one finger flick and the flick
> hasn't been recognized until the touch end (one definition of flick is
> if the final velocity at touch end is above a certain threshold)? Do we
> withhold the touch end event from the client until we are sure?
> If we withhold the touch end event, we should at least send a touch
> update event to describe the location of the touch end event (if
> different than the previous event). If you do that, then the touch end
> event is the same as a touch ownership event, as it only conveys the
> fact that the client now owns the touch stream.
> At best we can eliminate one event, the touch ownership-like event, if
> the compositor is certain before the touch stream ends that the stream
> does not comprise a compositor gesture. The trade-off for potentially
> saving one event is we are forcing clients to assume a touch stream can
> be canceled at any time, which may be a burden for a very long touch
> stream.
> -- Chase
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110707/f868b8ac/attachment.html>

More information about the wayland-devel mailing list