<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 11, 2016 at 11:03 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
</div></div>Come to think of it, we would still introduce a race condition, just for<br>
the other use case. If the intention is that the lock should be<br>
one-shot, the client may not be able to respond with a .destroy() in<br>
time, resulting in the compositor potentially re-locking when that is<br>
not what the client intended. To support both use cases race free we'd<br>
need to bake that into the request creating the lock. Is it worth<br>
complicating the request for fixing both races?<br></blockquote><div><br></div>There should *only* be "one shot" requests, which are very quickly accepted or denied by the compositor. The client creates it in response to an input event, and it includes the input event id.<br><div><br></div><div>Most/all things that triggers pointer lock (the mouse entering the 
region, the mouse being pressed in the region, a press+release in the 
region, a keystroke) could be implemented by clients and it does not do 
any pointer lock protocol until after it has detected the triggering 
event, and thus can include the event id.<br><br>It is extremely unclear from your proposal whether you are going to allow a pointer lock to happen without an input event to the client. Some description of how pointer lock looks to a user would help here. Some guesses of mine:<br><br></div><div>- Pointer lock is "grabbed" immediately on program startup, or when the surface is full-screened. I think this could be done by the client making the request at these points with a zero event id. Also responding to mouse-enter events would probably cover all the real-world examples.<br><br></div><div>- Some kind of global compositor-chosen hot key triggers pointer lock. But then it is rather mysterious how you deal with pointer lock requests from more than one client at the same time. If that is chosen by the keyboard focus, then the client will get the keystroke and thus the client can trigger pointer lock in response to the keystroke.<br><br></div></div></div></div>