On 04/17/2012 10:56 PM, Peter Hutterer wrote: > On Mon, Apr 16, 2012 at 11:20:18AM -0700, Chase Douglas wrote: >> On 04/12/2012 10:27 PM, Peter Hutterer wrote: >>> On Wed, Apr 11, 2012 at 11:22:13AM -0700, Chase Douglas wrote: >>>> During testing I was able to cause a pointer grab replay to fail by >>>> sending a lot of events at once on a beefy machine. The grab replay >>>> request time was equal to the event stamp time, but both were later >>>> than currentTime. This means it is somehow possible to generate events, >>>> send them to a client, and have the client make a request based on those >>>> events all before the server time is updated. >>> >>> I wonder if this could be as simple as a missing UpdateCurrentTime() in >>> AllowSome() or at the very least the need to call UpdateCurrentTime() before >>> converting client time to server time in the Proc*AllowEvents. >> >> Yes, it could be one of those. However, we will continue to leave >> ourselves open to mischief if we don't close the real issue at the source. > > if currentTime is never updated during event processing and no client > currently sends requests, don't we end up sending all events with the same > timestamp forever then?
Maybe, and I noticed that this change was actually messing up utouch tests too. > A more generic solution to this would be to add UpdateCurrentTime() before > dispatching client requests so that the server time is up-to-date whenever a > request is processed. Yeah, I added a call to UpdateCurrentTimeIf() to the top of the Dispatch() loop. I think this should resolve the issue while allowing us to keep "real time"-ish event timestamps. Patch forthcoming. -- Chase _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
