Pointer lock and warping

Vincent Povirk madewokherd at gmail.com
Wed Apr 24 21:22:50 PDT 2013


> 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.
>
> While in this mode the mouse position is reported as though the user is
> dragging over a very large torus surface (ie it wraps at very large
> integers), the same as the pointer-lock proposal.
>
> The pointer stops moving on-screen except in response to pointer-warp
> requests from the client. The pointer *does not vanish* (unlike the
> pointer-lock proposal) because I see no way for the client to draw a fake
> pointer without a possible flicker (the client can set it to a blank surface
> to make it vanish).

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)?

Since the common case on current DE's is that holding the mouse button
doesn't change the way the cursor moves, that seems like an odd
choice.

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.

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.


More information about the wayland-devel mailing list