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.
If the client uses the serial numbers or just a timeout it can be made to get the lock again if the user moves the mouse back in soon enough. But it is never going to be perfect.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
