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

[Bill Spitzak]

On 01/03/2016 08:21 PM, Peter Hutterer wrote:
> On Fri, Jan 01, 2016 at 04:54:14PM +0000, 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.
>
> you get a much less expressive API, less checking, etc. for a fairly minimal
> benefit. Furthermore, any extension to *either/or* the lock/confine
> interface would need to handle the appropriate NULL cases for the other
> interface. Right now we can easily add a locking-specific request without
> messing up the logic of the confinement, and vice versa.

You have a confinement protocol where the client updates a region to 
move the cursor.

You have the lock protocol where the client updates an x/y and it moves 
the cursor (though you call it the "hint" and it does not move the 
cursor until after the lock is destroyed, but since this is useless 
unless the client hides the cursor, the behavior would be identical if 
it moved the cursor immediately).

An x/y position is a degenerate region.

Therefore the two are the same, provided you let the lock version 
actually move the cursor, rather than it being a "hint". Which would be 
incredibly useful, too!

>> Also, for symmetry with wp_relative_pointer, should this take a
>> wl_pointer instead of wl_seat?
>
> you'd be restricting locking and confinement to a pointer device, with a
> wl_seat you can confine and lock devices that are not wl_pointer devices,
> e.g. a wl_tablet tool in relative mode.

I'm pretty certain that would provide a wl_pointer. Absolute mode maybe 
I could understand, but not relative.