<div dir="ltr">Bill, That's an interesting idea, but there are a few problems (which may be solvable).  I do kind of like the way it completely sidesteps the acceleration issue.<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 12:43 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In any case this all sounds excessively complicated. I think this will work:<br>
<br>
- Client can create a pointer_lock object from an wl_pointer. This takes a serial of an event so the compositor can decide whether it should be allowed by the event.<br>
<br>
- Motion and push/release events still come in IDENTICAL to how they were before, except it acts as though the surface is infinite in size. This is to make it easier for toolkits to handle. There is no need for relative events as it is trivial for the toolkit to subtract the starting position. Acceleration should be unchanged.<br></blockquote><div><br></div><div>This won't quite work.  There is no such thing as an infinite datatype with which to express these absolute positions.  It's tempting to say "just use float or double" but those quickly loose precision as you go further off center.  We could allow the wl_fixed values to wrap around and trust in subtraction, but I don't know how well that will work.<br><br></div><div>Also, this still leaves the issue of how do you handle multiple pointer objects.  This doesn't completely solve it at all.  For instance, suppose I'm playing an FPS game and I look upper-right and click to fire. The pointer position being reported may be right over my close button.  If the toolkit still thinks it's getting regular pointer events, then we have a problem.  <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- The client will only get an enter event if it has gotten a leave event before pointer lock is granted (this is probably impossible on most compositors). There is no difference between this enter event and a normal one.<br>
<br>
- I don't think the client will get a leave event until pointer lock is cancelled, and only if the cursor ends up outside the surface.<br>
<br>
- Tablets may change to a relative mode.<br></blockquote><div><br></div><div>There's a race here.  How does the client know that it got relative events and not absolute?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- The cursor stops moving. A new api is added (maybe to the pointer_lock object) that allows the cursor to be positioned. The coordinate system is exactly the same one the mouse events are using.<br></blockquote><div><br></div><div>Are the events the client gets after it sets the pointer starting from the newly set position?  If so, then how do we solve the inherent race of the client not knowing where in the pointer event stream that happened?  If not, then how does the toolkit with another wl_pointer object (other than the relative one) handle it properly?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- The client can change the cursor image (including making it invisible) using the same api as always.<br>
<br>
- The client cancels pointer lock by destroying the pointer lock object. Depending on the hardware this will either make the pointer move to the last cursor position, or move the cursor to the absolute pointer position. Either of these may cause leave, enter, and move events.<br>
<br>
- The compositor can break pointer lock by sending a special event. This may be the only event that the pointer_lock object can produce. When the client gets it it should destroy the pointer lock object. I don't think it should be called "leave" and it has nothing to do with enter/leave.<br>
<br>
Examples:<br>
<br>
Game where pointer position controls things: client requests pointer lock on activation, and possibly on enter events. A smarter client can wait until the mouse hovers a bit before grabbing it. Client then hides the cursor and uses the relative events until the game ends or pointer lock is lost.<br>
<br>
Restrict motion to the surface: client acts like the game, but does not hide the cursor. Instead on all motion it clamps the motion to the allowed area and places the cursor there, and acts like the motion is to that point.<br>
<br>
"Slow scrollbar": on push client requests pointer lock. It then scales down the motion, moving it's scrollbar and the cursor the same so they still look locked together. On release it destroys the pointer lock.<br>
<br>
Eyedropper color picker: client requests pointer lock after user enters color picker mode. It then moves the cursor to match the pointer position. On push/release it uses a privledged api to pick the color off the screen at that location. Depending on the app it may drop pointer lock at this point, or stay in color picker mode.<br>
<br>
Tumble 3D controller: Client requests pointer lock on push of the shift key and destroys it on release of the shift key. It probably hides the cursor. It then computes tumble on all movements while the mouse is down.<br></blockquote><div><br></div><div>I don't see why the above proposal doesn't also solve these cases.<br></div><div>--Jason <br></div></div></div></div>