[PATCH 4/5] Use current time for event timestamps

[Chase Douglas]

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