On 09/14/2011 02:04 PM, Peter Hutterer wrote: > On Wed, Sep 14, 2011 at 12:09:02PM -0500, Chase Douglas wrote: >> On 09/14/2011 11:59 AM, Peter Hutterer wrote: >>> On Wed, Sep 14, 2011 at 10:22:36AM -0500, Chase Douglas wrote: >>>> This is potentially both a performance and client complexity >>>> improvement. >>> >>> this needs more description, especially for the archives (we just talked >>> about this here at the XDC), please add that to the commit message. >>> >>> and one more thing: if a client can reject a sequence at any time it may be >>> that the sequence already disappeared by the time the reject is processed. >>> (this shouldn't happen unless the client buffers the request but thats been >>> known to happen). >>> >>> should we allow clients to reject any touch (even invalid ones) without >>> returning a BadValue? >> >> Hmmm... The same could happen with accept too: >> >> * Client A owns touch >> * Client B has a touch grab and is listening too >> >> 1. Client A accepts touch >> 2. TouchEnd sent to client B >> 3. Client B accepts touch (which means, I accept iff I become the owner) >> 4. TouchEnd reaches client B >> 5. Client B gets an error from the touch acceptance because at the time >> the server got the accept request, the touch has already ended for client B >> >> We probably need to think a bit more about this... > > accept is a different case where the client should handle errors > appropriately. reject is more fire-and-forget. same with Ungrab, iirc it > always succeeds even if you don't actually have the grab.
This makes sense to me after further thought. I agree we should not emit an error on reject if the touch id is invalid, as you suggest. I'll send a v2 with this change and a more verbose commit message. -- Chase _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel