[PATCH 3/4] protocol: Introduce pointer_lock interface

[Kristian Høgsberg]

On Tue, Feb 26, 2013 at 11:55 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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.

You're confusing keyboard and pointer focus.  The pointer_lock kicks
in when the surface receive keyboard focus, not pointer focus.  It
would be very nasty if just mousing over a surface would lock the
pointer.

Kristian