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

[Bill Spitzak]

On 12/08/2014 06:07 AM, Jonas Ådahl wrote:
> On Tue, Dec 02, 2014 at 02:39:21PM -0800, Bill Spitzak wrote:

>> - 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.

Okay I think a lot of my confusion was that I figured the pointer lock 
was created in response to an event such as a button press. It sounds 
like it is instead some kind of setup that a client would create asap 
that means it will get the pointer lock on click.

Though I am still rather confused that the only way to "release" a 
pointer lock is to destroy this object. Is the client supposed to 
immediately recreate it in preparation for the next click?

Can you explain how a client would use this to make a slow scrollbar 
that works like this:

1. User presses the mouse down on the scrollbar

2. Until the release the mouse it acts like it is moving much slower, 
and the cursor and scrollbar move together

3. When user releases it, the cursor either continues to move at normal 
speed relative to where it was, or it may jump to an absolute position 
sending the correct enter/exit/move events. This can be chosen by the 
compositor, perhaps depending on the input device type.

Also an explanation of exactly how an FPS shooter program will work, as 
this seems to be your primary goal. It is not very clear how the game 
can request that the user be allowed to click on another client, and 
what the game has to do to regain pointer lock.

> Don't think it's very beneficial to add various kinds of locks that
> unlocks at specific events. The client can simply unlock on mouse
> button release. Not sure what round trip you are talking about here

The round trip is that after the mouse-up, the compositor cannot send 
enter/move to the surface the mouse is over until it receives the 
destruction notify from the client.

I agree this is not very important but it is how the mouse works 
normally on mouse press (it's called "grab" then, but it basically is a 
form of this pointer lock in that all events are sent to the first 
client until release).

> Do you have a suggestion for a better wording?

Make it clear that this object is not in *response* to the lock-causing 
event, but instead a setup that, I guess, a client does immediately 
after creating the surface and immediatly after any release.

Examples of the slow scrollbar and fps shooter would help a lot.

> The pointer is only potentially warped when unlocking

Your docs claim the cursor is moved when locking.

> We don't want clients to control the cursor position. If the client
> really wants to be in control, it should lock the pointer, hide the
> cursor, and then draw its own cursor sprite, either as part of its own
> scene, or as a subsurface.

That will blink unless api is added to lock a change in cursor image to 
the showing of another surface. Seems really complicated.

I also find it rather incredible that clients can assume they can change 
the cursor image, including hiding it, but are not allowed to assume 
they can move it!