Pointer lock and warping

[Bill Spitzak]

Vincent Povirk wrote:

>> When the client receives a mouse-down event, it knows it is in this mode.
>> The mode is exited when all the mouse buttons are released.

> Um, wouldn't this mean that in order to get "normal" cursor behavior
> while a button is held down, all clients have to echo the mouse events
> they receive back to the server (and do so very quickly, or else
> you'll get noticeable input lag)?

Yes I now think this mode does not have to be entered until a 
pointer-warp is done. At that point the pointer stops moving and is 
controlled only by further pointer-warps. This is compatible with 
current behavior. The mouse will jitter once if the first warp is an 
echo of a previous position and the compositor has managed to display 
the pointer at a new position, but I don't think that is a real problem.

> I guess the intent here is to grab the pointer as soon as the mouse
> goes down, so that you can't lose any events between pressing the user
> pressing the button and the client starting the grab, but the desire
> to "filter" mouse events in this way is weird enough that I think it
> has to be opt-in. And with this proposal there's a possibility of
> losing events before the mouse is released, if you're not able to warp
> the cursor in time.

No event are ever lost. As long as any mouse buttons are down the client 
will keep getting mouse-drag events that are exactly the same whether 
the pointer warp is done or not (ie they report where the mouse would be 
if the pointer warp was not done). This is exactly the same as the 
pointer-lock proposal.

> I think that for any mouse input "filtering" system to work correctly
> (including pq's proposal), a client needs to inform the compositor
> when ending the grab of the last event that it was interested in
> (normally a mouse up)

The grab ends automatically when all the buttons are released, exactly 
like the implicit grab does already. It then acts as though the mouse 
jumped to the pointer-warp location, sending move/enter/exit events as 
necessary and changing the pointer focus.

The client can tell which events are which by whether they are 
before/after the release. Though not technically necessary, it would be 
helpful if keyboard and mouse release events to include an indicator 
that "nothing is held down anymore". This can be used to recover from a 
screw up where the client got out of sync remembering what was held down.