Pointer lock and warping

[Pekka Paalanen]

On Wed, 24 Apr 2013 23:22:50 -0500
Vincent Povirk <madewokherd at gmail.com> wrote:

> 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), so the compositor can resume normal input
> processing from there after the client has had a chance to process all
> the events up to that point and decide on the correct cursor position.
> Otherwise, the fact that client and compositor can handle events in a
> different order means strange things can happen to your mouse input.

Hmm, yeah... a client decides it wants to end the pointer lock, sends
its last pointer warp event, and destroys the locked wl_pointer. If the
server in the mean time sends more events to the locked wl_pointer, they
will be lost: the server is not using them to update the pointer
position, and the client does not get them.

I'm not sure this is worth fixing, is it? It would certainly complicate
things a lot, and the benefit is not obvious.

The client would be required to ack all input events by e.g. ack'ing
the last motion serial (which we don't even generate yet?) it
processed, and the server needs to keep the input events stored until
the client acks them, just in case the client does not ack a few
remaining events.


Thanks,
pq