Touch events

Kristian Høgsberg krh at
Tue Feb 21 13:25:39 PST 2012

2012/2/21 Chase Douglas <chase.douglas at>:
> On 02/21/2012 09:16 PM, Kristian Høgsberg wrote:
>> 2012/2/20 Chase Douglas <chase.douglas at>:
>>> On 02/17/2012 06:01 PM, Kristian Høgsberg wrote:
>>>>  - input protocol restructuring: break up events into wl_pointer
>>>> (enter/leave/motion/button/axis events, set_pointer_surface request),
>>>> wl_keyboard (enter/leave/key events... what else... unicode event,
>>>> set_map request? pending kb work), and wl_touch (down/up/motion/cancel
>>>> events) interfaces
>>> [snip]
>>> So the client window will receive touch events without delay, but may
>>> receive a cancel? I am in favor of this approach, but you need to add a
>>> way to tell the window when the window manager has "rejected" a touch
>>> sequence as well. Otherwise the client will never know when they can
>>> perform destructive operations with it.
>> No, we don't need that.  Don't do destructive operations on something
>> that could be the first half on a globall gesture.  If you need to
>> know for sure that nobody is going to take over the events, wait until
>> the touch session is over (all touch points up, none cancelled).
> That doesn't make any sense. What if I'm playing a game? Latency
> matters, and I need to know that the touches are mine early on. In the
> case of a game, the environment should leave touches alone and
> immediately tell the game that the touches are owned by it.

I didn't say that applications always have to wait for touch end.
Just that if you're doing something irrevocable like, sending an email
or formatting your floppy, you don't want to trigger on something that
could be part of a global gesture.  Like touch down, then move. You
need to wait for touch end in that case.

On the other hand, if you're scrolling in your web browser or moving
around in a game, you just assume you own the events you get and
scroll/move around.  If later in that touch session, you get the
cancel event, you can just leave the web page/game where you
scrolled/moved to.  Or you can undo what you did, for example, if you
scribbled in a paint app as part of the global gesture.  Because you
have to be able to do that anyway.

> Touches are used for much more than just button tapping, and waiting
> until a touch is lifted to do anything won't work.
> Another reason this won't work is if your environment wants to recognize
> a double-tap sequence. The first tap will end, at which point the
> wayland application will attempt to use it. But a second tap comes along
> and the environment performs an action.

This doesn't seem like a valid use case.


More information about the wayland-devel mailing list