[PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol

[Bill Spitzak]

On 01/01/2016 08:54 AM, Daniel Stone wrote:

> I almost wonder if we couldn't make peoples' lives easier by merging
> locking and confinement into a single interface, adding a bool for
> whether or not to allow pointer movement (confine) or not (lock). Or
> perhaps, rather than a bool, we could add an allow-null
> wp_relative_pointer argument instead: gives you lock if non-null, or
> confine if null.

Yes please merge these two almost-identical apis into a single one. Base 
it on the confinement version. This already allows the client to update 
the confinement region as often as wanted. A zero-sized region can force 
the cursor to be at a particular point, which is what the pointer lock 
does (with my oft-requested enhancement that the normal cursor-setting 
code can be reused to set the cursor image).

If you want to duplicate the almost-useless current pointer-lock, the 
client can just hide the cursor, and make a fake one using a new 
surface. Setting the region also sets the "hint" as he calls it.

> Also, for symmetry with wp_relative_pointer, should this take a
> wl_pointer instead of wl_seat?

Seems like a good idea

>> +      If the compositor decides to unlock the pointer the unlocked event is
>> +      sent. The wp_locked_pointer object is at this point defunct and should be
>> +      destroyed.
>
> Egads. :( This is a bit hostile - what's the harm in allowing latent
> objects to remain?

I think he is just trying to say that the object is now useless. The 
client does not have to destroy it, but it probably should.