[PATCH 27/42] dix: add helper functions for adding/removing touch listeners

[Peter Hutterer]

On Tue, Dec 20, 2011 at 09:04:38AM -0800, Chase Douglas wrote:
> On 12/19/2011 07:27 PM, Peter Hutterer wrote:
> > On Mon, Dec 19, 2011 at 07:20:38PM -0800, Chase Douglas wrote:
> >> On Dec 14, 2011, at 7:02 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> >>
> >> [snip]
> >>
> >>> +static void
> >>> +TouchAddActiveGrabListener(DeviceIntPtr dev, TouchPointInfoPtr ti,
> >>> +                           InternalEvent *ev, GrabPtr grab)
> >>> +{
> >>> +    if (!ti->emulate_pointer &&
> >>> +        (grab->grabtype == CORE || grab->grabtype == XI))
> >>> +        return;
> >>> +
> >>> +    if (!ti->emulate_pointer &&
> >>> +        grab->grabtype == XI2 &&
> >>> +        (grab->type != XI_TouchBegin && grab->type == XI_TouchEnd && grab->type == XI_TouchUpdate))
> >>> +        return;
> >>> +
> >>> +    TouchAddGrabListener(dev, ti, ev, grab);
> >>
> >> If I'm reading this right, we are adding the possibility of active grabs
> >> of touches. I didn't think that was part of the protocol.
> > 
> > If a client actively grabs the device for touch events, then it should get
> > the events, right? There's nothing in the protocol to prevent this.
> 
> To be clear, a client actively grabs a device in whole, not just for
> touch events. The question then is what we should do for touch events in
> this circumstance. After thinking about it, it makes sense to send touch
> events to the actively grabbing client. I'm good with this now.

yeah, that was my initial thinking. an explicit grab request should be just
that.

> >>> +}
> >>> +
> >>> +void
> >>> +TouchSetupListeners(DeviceIntPtr dev, TouchPointInfoPtr ti, InternalEvent *ev)
> >>> +{
> >>> +    int i;
> >>> +    SpritePtr sprite = &ti->sprite;
> >>> +    WindowPtr win;
> >>> +
> >>> +    if (dev->deviceGrab.grab)
> >>> +        TouchAddActiveGrabListener(dev, ti, ev, dev->deviceGrab.grab);
> >>
> >> Non-touch active grabs do not allow for replaying events. Shouldn't we
> >> continue this policy and return if an active grab was found?
> > 
> > this hunk is there for activated passive grabs and implicit passive grabs
> > which happen on pointer emulation.
> 
> It looks like this is right for passive and implicit grabs that are
> activated. What do we do about explicit active grabs? The pointer
> protocol does not allow for syncing and replaying events from explicit
> active grabs, so event propagation begins and ends with the grabbing client.
> 
> If we wanted to mimic this behavior for touch events, we would deliver
> to the grabbing client and implicitly accept the touch sequence for the
> client. TBH, I think the current approach you have is the most flexible,
> but there's a nagging feeling that we might find an issue with it.
> Otherwise, why can't we sync and replay explicit active grabs of pointer
> events?
> 
> /me hopes he remembers explicit active grab semantics properly :).

IIRC the code should implicitly accept the touch if the device is ungrabbed.
If not, that's missing and I'll have to add it. Since touch events are
always grabbed one way or another, I think accepting on ungrab it is the
best course of action.

Given the touch grab semantics, ownership-selecting clients will still get
the events until the accept happens. but they need to deal with that anyway.

as for pointer replaying on active grabs: possible, if you issue a sync grab
and the next event is a button press events. good luck testing this :)

Cheers,
  Peter