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

[Bill Spitzak]

Again this seems excessively complicated, requires lots of communication 
long before the lock happens, makes the methods used to trigger the lock 
very limited and dependent on compositor features, and it does not look 
like it is possible to avoid an unwanted blink in the cursor.

- Client must sent the lock_pointer immediately on startup, but also 
resend it after each lock is lost. This just seems strange and unbalanced.

- Client has to destroy the (unused) locked_pointer object and send a 
new lock_pointer request when the widget layout changes. This is a lot 
of overhead, and also somewhat painful for some toolkit designs, and it 
just seems wrong for clients to have to send widget layout to the 
compositor.

- Client has no choice about what triggers the lock other than the 
region sent with the lock_request. In particular shift keys or different 
mouse buttons cannot change it.

- I think there are race conditions when new lock_pointer requests are 
sent. Probably solvable by allowing them while the previous 
locked_pointer object still exists (it just cancels it) but this is 
worrisome.

- The client must hide the cursor and draw a fake one. This will blink 
as there is no synchronization between changing the cursor image and 
mapping another surface. And it means that the client cannot take 
advantage of any hardware acceleration the compositor applies to the 
cursor. Toolkits have to implement two different methods of changing the 
cursor image, too.

- I am utterly mystified about the "confine" object as it appears it 
does nothing that cannot be done with your "lock" object and the client 
moving a fake cursor, restricting the position to being inside the 
confine region.

Here is my variation, this is identical to what I have suggested several 
times before but I will try to update the terms to match what you have:

- The lock_pointer request is sent in response to a triggering event, 
such as a mouse-down inside the region. It does not have a region 
argument, but does have an event serial so the compositor can identify 
the triggering event. The compositor can then decide to grant or refuse 
the lock, or even popup some user interface to allow the user to choose.

- There is no "locked" event, only an "unlocked" event. If the 
compositor refuses the lock it sends the unlocked event immediately.

- Remove the "_hint" from the name of "set_cursor_position" request, and 
make it actually move the cursor. The mouse x/y events reported to the 
client are the same as you have them, they do not jump to this position 
until the lock is destroyed (and only if the device is relative). Note 
that if the client hides the cursor they have EXACTLY the same api as 
you are proposing, perhaps that will make it clear what I am requesting.

- Remove confine_pointer request and confined_pointer object. Instead 
the client uses lock_pointer and locked_pointer, and uses 
set_cursor_position to place the cursor inside the confine region. This 
allows the region to be arbitrarily complicated (like have holes in it 
or have a slower-motion area near the edge or restrict the mouse to the 
surface of a 3D tumbling sphere).

- (Maybe) Add an argument to lock_pointer to reuse the normal grab 
machinery such that release of all the mouse buttons will automatically 
cancel the lock. The reason for this is to avoid round trips by reusing 
code that is in the compositor anyway.