[PATCH 3/4] protocol: Introduce pointer_lock interface

[Bill Spitzak]

I think you are right, that removes the race condition where the pointer 
exits before the client sends the lock. If the client wants to lock when 
the user hits a button always, it can just release on the leave event.

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.

Kristian Høgsberg wrote:
> On Mon, Feb 25, 2013 at 9:48 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>> The pointer lock is a one-shot (ie on exit and enter the pointer is not
>> locked again), right?
> 
> It's intended as a persistent condition for the surface.  Whenever the
> surface receive keyboard focus, the pointer lock is activated.  This
> stays in effect until the wl_pointer object is destroyed.  It could
> work as a one-shot thing too, but you can that behavior by manually
> destroying the wl_pointer object when you get the leave event.
> Alternatively you can implement the persistent behavior with the
> one-shot lock by always locking on wl_keyboard.enter.
> 
> Kristian
> 
>> Kristian Høgsberg wrote:
>>> The pointer_lock interface is modelled after the HTML5 pointer lock
>>> extension:
>>
>>> +    <request name="lock_pointer" since="2">
>>> +      <description summary="return pointer object">
>>> +       The lock_pointer request lets the client disable pointer
>>> +       motion and request relative motion events.
>>> +
>>> +       This request initializes the pointer lock and activates it in
>>> +       case the surface is active.  If the surface isn't active when
>>> +       the server receives the request, the compositor will activate
>>> +       the pointer_lock when the surface is eventually activated.