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

[Peter Hutterer]

On Wed, Jan 05, 2011 at 12:37:57PM +0000, Daniel Stone wrote:
> Hi,
> 
> On Wed, Jan 05, 2011 at 03:12:38PM +1000, Peter Hutterer wrote:
> > On Thu, Dec 23, 2010 at 09:10:45AM +0000, Daniel Stone wrote:
> > > 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.
> 
> Is there any way I can change your mind about the double-delivery? I
> just cannot see this ending well at all.

leave the code as-is, and depending whether we fix it or not we change it or
leave it as-is. I don't think we can expect to get a 100% correct
implementation on the first go anyway and we've got a few months time to
sort this out.

> > > 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? :)
> 
> Note that it's not affected by window hierachy changes (e.g. creating a
> new window, moving windows), or by _new_ grabs or selections.  If a
> window disappears, then we necessarily have to stop reporting events to
> it; also, if a client explicitly drops its selection or grab, I'd honour
> their wishes.
> 
> It's only delivering to new grabs/selections that weren't in the
> original delivery set that's a problem, since they'll be getting partial
> touch data.

fair enough.

Cheers,
  Peter