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

[Daniel Stone]

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>