[PATCH weston 14/17] Introduce pointer locking and confinement protocol

[Derek Foreman]

On 08/12/14 08:07 AM, Jonas Ådahl wrote:
> On Tue, Dec 02, 2014 at 02:39:21PM -0800, Bill Spitzak wrote:
>> On 12/02/2014 05:49 AM, Jonas Ådahl wrote:
>>
>>> +    <request name="lock_pointer">
>>> +      <description summary="lock pointer to a position">
>>> +        The lock_pointer request lets the client disable absolute pointer
>>> +        movements, locking the pointer to a position.
>>> +
>>> +        There may not be another lock of any kind active when requesting a lock,
>>> +        and if there is, an error will be raised.
>>> +
>>> +        The intersection of the region passed with this request and the input
>>> +        region of the surface is used to determine where the pointer must be
>>> +        in order for the lock to activate. It is up to the compositor to warp
>>> +        the pointer, or require some kind of user interaction for the lock to
>>> +        activate. If the region is null, then an infinit region is used.

s/infinit/infinite/

>>> +
>>> +        The request will create a new object wl_locked_pointer which is used to
>>> +        interact with the lock as well as receive updates about its state. See
>>> +        the the description of wl_locked_pointer for further information.
>>> +
>>> +        Note that while a locked pointer doesn't move its absolute position, it
>>> +        may still emit relative motion events via the wl_relative_pointer
>>> +        object.
>>> +      </description>
>>> +
>>> +      <arg name="id" type="new_id" interface="_wl_locked_pointer"/>
>>> +      <arg name="surface" type="object" interface="wl_surface"
>>> +           summary="surface to lock pointer to"/>
>>> +      <arg name="seat" type="object" interface="wl_seat"
>>> +           summary="seat where the pointer should be locked"/>
>>> +      <arg name="region" type="object" interface="wl_region" allow-null="true"
>>> +           summary="region of surface"/>
>>> +    </request>
>>
>> - Does this need some id of the triggering event? Mostly to determine if the
>> surface had the pointer focus at the time the request was made.
> 
> It does not, and the lock is postponed until that trigger event happens.
> For example a surface can lock the pointer, but the lock may not
> activate until the user clicks the surface. It should not be hard coded
> exactly what type of event should trigger a lock.

This bit is confusing me.

A windowed game starts and asks for a pointer lock, but the window isn't
focused, so the lock is postponed...

At this point another app could request a lock and get a lock object,
which may or may not also be postponed.

However, if the first lock was already active at the time the second app
requested a lock, it wouldn't received a postponed lock object, just an
error?

So there could be a dozen postponed locks across many applications as
long as they're all set up while there isn't an active lock, and that's
ok.  But as soon as a lock triggers no new ones can be set up until it's
released?

Why the restriction?  Why can't apps set up locks at any time they want,
since they won't trigger until some time after the old lock is released
anyway?