I think you are right, that removes the race condition where the pointer
exits before the client sends the lock. If the client wants to lock when
the user hits a button always, it can just release on the leave event.
I suppose there still is a race if the user hits the lock-cursor button
and then moves the mouse out so fast that it exits before the client
sends the lock request. But this is a lot harder to hit that the quick
enter+exit one.
Kristian Høgsberg wrote:
On Mon, Feb 25, 2013 at 9:48 PM, Bill Spitzak <[email protected]> wrote:
The pointer lock is a one-shot (ie on exit and enter the pointer is not
locked again), right?
It's intended as a persistent condition for the surface. Whenever the
surface receive keyboard focus, the pointer lock is activated. This
stays in effect until the wl_pointer object is destroyed. It could
work as a one-shot thing too, but you can that behavior by manually
destroying the wl_pointer object when you get the leave event.
Alternatively you can implement the persistent behavior with the
one-shot lock by always locking on wl_keyboard.enter.
Kristian
Kristian Høgsberg wrote:
The pointer_lock interface is modelled after the HTML5 pointer lock
extension:
+ <request name="lock_pointer" since="2">
+ <description summary="return pointer object">
+ The lock_pointer request lets the client disable pointer
+ motion and request relative motion events.
+
+ This request initializes the pointer lock and activates it in
+ case the surface is active. If the surface isn't active when
+ the server receives the request, the compositor will activate
+ the pointer_lock when the surface is eventually activated.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
