[PATCH xserver 08/10] Input: Add initial multitouch support from Xi 2.1
Daniel Stone
daniel at fooishbar.org
Wed Jan 5 04:37:57 PST 2011
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110105/9a2939c8/attachment.pgp>
More information about the xorg-devel
mailing list