[PATCH xserver 08/10] Input: Add initial multitouch support from Xi 2.1

[Peter Hutterer]

sorry, late reply but the holiday season took its toll

On Thu, Dec 23, 2010 at 09:10:45AM +0000, Daniel Stone wrote:
> On Thu, Dec 23, 2010 at 10:34:35AM +1000, Peter Hutterer wrote:
> > On Wed, Dec 22, 2010 at 11:56:30AM +0000, Daniel Stone wrote:
> > > On Wed, Dec 22, 2010 at 03:10:07PM +1000, Peter Hutterer wrote:
> > > > no. if the current hierarchy event processing isn't good enough, fix it but
> > > > don't shortcut it like this.
> > > 
> > > Well, we can only have a single delivery tree for each touchpoint: if we
> > > deliver once through the SD and once through the MD, we run the risk of
> > > a single touch being delivered in parallel to two sets of clients (e.g.
> > > one tree which has grabs on the device ID, and another which has grabs
> > > on XIAllMasterDevices), or at best, delivering the same touch twice to
> > > the same clients.
> > 
> > the same is true for pointer events. we rely on clients to be smart enough
> > to know that if they select for events from device X and for events from
> > XIAllMasterDevices, they will get duplicate events (with different states
> > too).
> > 
> > "don't shoot yourself in the foot. oh, btw. here's a gun. good luck."
> 
> Sure, but the same touch being owned by different clients is not OK.  If
> client A grabs touches on that device, and client B grabs touches on all
> MDs, then both clients will be the owner of that touch, which is quite
> obviously broken.  I can't think of a way to post touch events twice
> that doesn't result in instant breakage with the first usecase you can
> think of.

decouple the touches? aiui, the main difference here is that when it comes
to pointer events, we pretend there's two different events even though they
are the same physical event. the same can be true for touches, and it
already is since on the protocol a touchid is always coupled with a
deviceid, hence the client does not see touch:5 from device:4 as the same
event as touch:5 from device:2.

> > > > I don't quite understand the need for this. Once the sprite trace is
> > > > established, anything in listeners should be ok to deliver to, right?
> > > > if so, we don't need this for loop and can just run it on TouchBegin.
> > > 
> > > Sure, but grabs can (and will) change at any time, so if one client
> > > ungrabs and then another client regrabs mid-stream,
> > > CheckPassiveGrabsOnWindow will hand us back a grab for a client which
> > > has never seen that TouchBegin.
> > 
> > I'm confused. if you run through the window hierarchy at TouchBegin and you
> > store all clients that will receive the TouchBegin and subsequent other
> > events, you are good until TouchEnd time, right?
> > 
> > for all subsequent events, you can just go through the list (and remove
> > clients from that list if the reject grabs). I don't quite understand why
> > CheckPassiveGrabsOnWindow() would be called at any other time. am I missing
> > something here?
> 
> Well, event selections can change without the resource changing.  So a
> TouchBegin|TouchMotion|TouchEnd selection can be changed by the client
> into a MotionNotify|ButtonPress|ButtonRelease selection and we'd still
> be delivering it touch events.  In this case, I'd rather respect the
> client's wishes and stop delivering it touch events.

the spec you sent out claims that:
"The delivery of touch events is not changed by any modifications to the
window hierarchy after the window set has been determined for the touch, nor
is it affected by new grabs or selections."

so I don't think that's an issue, right? :)

Cheers,
  Peter

> For grabs, you've just made me realise it's broken, as re-grabbing will
> free the existing grab before adding the new one with a new ID.  So we
> might need something more intelligent for that corner case, I guess.
> 
> tl;dr: You're right for grabs, but we still need it for selections.