[PATCH 3/4] protocol: Introduce pointer_lock interface

[Kristian Høgsberg]

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.