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