<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class=""><br>
On 12 January 2016 at 22:28, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> There should *only* be "one shot" requests, which are very quickly accepted<br>
> or denied by the compositor. The client creates it in response to an input<br>
> event, and it includes the input event id.<br>
><br>
> Most/all things that triggers pointer lock (the mouse entering the region,<br>
> the mouse being pressed in the region, a press+release in the region, a<br>
> keystroke) could be implemented by clients and it does not do any pointer<br>
> lock protocol until after it has detected the triggering event, and thus can<br>
> include the event id.<br>
<br>
</span>For what it's worth - post-hoc expansion on my reasoning - I think<br>
Bill has the genesis of a point here. Usually, our requests have<br>
followed one of two patterns: either you request activation in<br>
response to a specific event (button or key event allows you to create<br>
a selection), or retained state (creating a wl_data_device gets you<br>
selection/etc events on that seat until you destroy it).<br>
<br>
The proposed one-shot-but-delayed request to me felt like a really<br>
awkward compromise between the two, and not really one backed up by a<br>
strong enough usecase to justify a third (delayed but not retained)<br>
model for requests taking effect.<br>
<br>
It's entirely possible that there's something I'm missing here, but<br>
for consistency if nothing else, having the split instead be between<br>
these two classic methods (oneshot-immediate vs. fully-retained,<br>
rather than oneshot-delayed vs. fully-retained) could be good for<br>
future versions.<br></blockquote><div><br></div><div>I would agree there is something missing here.<br><br></div><div>I do not see any reason for anything other than a "one shot" which is created by the client *AFTER* it receives the possibly-triggering input event. I am still waiting for a description of how one of these pre-set locks is triggered, I have serious doubts that any possible trigger could be something other than an action that would send an event to the client, or at a moment the client is doing something like configuring the surface.<br><br></div><div>Nor do I see any problem with race conditions provided the one-shot request has an id for the triggering event:<br><br></div><div>- Client gets event that it thinks should trigger pointer-lock/confine<br><br></div><div>- Client sends pointer-lock/confine request which includes the event serial number (and creates the pointer-lock proxy object)<br></div><div><br></div><div>- Client can read relative motion events (these are identical whether or not pointer lock works, and also correct for motion before the pointer lock request was received by the compositor). Client can also read absolute pointer motion events, but it needs to know these change depending on whether they are before or after the accept event.<br><br></div><div>- Client can change the confinement region (ie it can move the cursor). These are ignored if pointer lock has been rejected or has expired<br><br></div><div>- Client (may) get an accepted event stating that pointer lock worked.<br><br></div><div>- Client gets a cancelled event. If it did not get an accepted event then it knows pointer lock did not work.<br><br></div><div>Imagine the compositor cancels pointer-lock on the next mouse-up event, and a client tries to grab pointer-lock on mouse down. Normal event sequence (--> indicates requests)<br><br></div><div> button-down event<br></div><div> --> pointer lock request<br></div><div> --> set cursor image<br></div><div> --> cursor motion<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> accepted event<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> button-up event<br></div><div> cancelled event<br></div><div> motion/enter/exit events due to grab being lost<br></div><div> --> set cursor image<br></div><div><br></div><div>Now imagine the simplest race, where the compositor sees the mouse button being released before it gets the pointer-lock request:<br><br><div> button-down event<br></div><div> --> pointer lock request<br></div><div> --> set cursor image<br></div><div> --> cursor motion<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> motion event<br></div><div> --> cursor motion<br></div><div> button-up event<br></div><div> motion/enter/exit events due to grab being lost</div><div> cancelled event (due to compositor finally seeing the pointer lock request)<br></div><div> --> set cursor image<br></div><div><br></div>Client can tell this happened because it did not get an accepted event. But it is also interesting that a client may not care: it should act exactly the same and to the user it looks like the pointer-lock gesture worked, except the end position of the cursor is different.<br><br></div><div>I can imagine schemes where the end cursor position is correct, but I think it requires putting an event serial number on the cursor motion requests. The idea is that if the mouse button has not been pressed again, it is warped back to the set position plus the result of any later motion events. Compositor sends accepted+cancelled to indicate this happened. Not sure if it is worth the complexity however.<br><br></div></div></div></div>