[PATCH 3/4] protocol: Introduce pointer_lock interface

[Bill Spitzak]

On 02/25/2013 09:28 PM, Daniel Stone wrote:

>     I suppose there still is a race if the user hits the lock-cursor
>     button and then moves the mouse out so fast that it exits before the
>     client sends the lock request. But this is a lot harder to hit that
>     the quick enter+exit one.
>
> That's like the sole entire reason we have serial numbers in the
> protocol.  There's similar checks for a great deal of requests which
> would otherwise race with focus changes.

No I realize that, it's just that it will likely have sent enter and 
move events, and possibly mouse button events, to another client, and 
has to somehow revoke these. It also sent a leave event to the locking 
client which it has to ignore. There are annoying problems if the other 
client wants a lock as well.

I have tried to come up with a working scheme that uses serial number or 
timestamps but there really isn't one because we cannot revoke stuff 
sent to other clients.

I now think the best idea is to keep it simple. The end result is that 
if there is a "lock cursor button" it will sometimes appear to not work 
if the user moves the mouse quickly.

If the client uses the serial numbers or just a timeout it can be made 
to get the lock again if the user moves the mouse back in soon enough. 
But it is never going to be perfect.