On Sun, Oct 07, 2012 at 12:07:01PM +1100, Daniel Stone wrote: > Hi, > > On 7 October 2012 01:58, Chase Douglas <[email protected]> wrote: > > Sorry for the delay, I've been trying to think about this to come up > > with a cogent argument. > > > > I don't like the idea of overlapping selections being allowed. There > > are two ways to handle an overlapping selection: > > > > * Only deliver to one of the selections. Which do you pick? Will the > > unpicked client be annoyed (i.e. will the developer be confounded when > > his application fails to receive touch events, and is this a problem)? > > > > * Deliver to both selections. This could cause multiple responses to a > > single physical action, which I have always found troubling. > > > > I don't think either is a great approach. I would prefer to lock it > > down so there cannot be any overlap. Are there use cases that require > > the ability for overlapping selections that I may not be aware of? > > At the time, I remember making the argument that we should allow > overlapping selections, but only for the generic > XIAllDevices/XIAllMasterDevices. The reasoning was basically that > toolkits etc want to select on those to avoid having to track device > addition/removal (with all the inherent race conditions), and if > someone else selects on just one device, that would break the whole > thing. I don't particularly mind either way tho.
correct, that is the reason why XI2 treates the virtual devices separately and I think we need to do the same for touch devices too. Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
