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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
