On Tue, Feb 26, 2013 at 11:55 AM, Bill Spitzak <[email protected]> wrote: > On 02/25/2013 09:28 PM, Daniel Stone wrote: > >> 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. >> >> That's like the sole entire reason we have serial numbers in the >> protocol. There's similar checks for a great deal of requests which >> would otherwise race with focus changes. > > > No I realize that, it's just that it will likely have sent enter and move > events, and possibly mouse button events, to another client, and has to > somehow revoke these. It also sent a leave event to the locking client which > it has to ignore. There are annoying problems if the other client wants a > lock as well. > > I have tried to come up with a working scheme that uses serial number or > timestamps but there really isn't one because we cannot revoke stuff sent to > other clients. > > I now think the best idea is to keep it simple. The end result is that if > there is a "lock cursor button" it will sometimes appear to not work if the > user moves the mouse quickly.
You're confusing keyboard and pointer focus. The pointer_lock kicks in when the surface receive keyboard focus, not pointer focus. It would be very nasty if just mousing over a surface would lock the pointer. Kristian _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
