[PATCH weston 1/3] Introduce pointer lock interface

[Peter Hutterer]

On Tue, Sep 23, 2014 at 04:50:19PM -0700, Bill Spitzak wrote:
> 
> 
> On 09/23/2014 03:15 PM, Jason Ekstrand wrote:
> >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.
> 
> Thanks
> 
> >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.
> 
> I figured the fixed type would be used, and wrap around. At 100 units/per
> inch the 24.8 fixed type would wrap to where the sign changed after the
> mouse was moved in the same direction for 1.3 miles. I think clients can
> ignore this possibility, or if they really want to it should be easy to
> detect and correct it.

fwiw you'd be hard-pressed to find a mouse with less than 400dpi these days,
800 and 1000dpi are common, ignoring specific gaming mice with higher
resolutions.

when thinking of wrapping, don't assume the best case of several movements
in the same direction, then a wrap. Assume the worst case of several
movements in the same direction to just below the wrapping point. And then
an event sequence that causes a wrap with every single event as the
coordinates go back/forth across the wrapping point.

Cheers,
   Peter

> >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.
> 
> The toolkit will have to know it turned on pointer lock. It needs to
> remember what widget requested pointer lock so it can send the events to it,
> so it already has this ability.
> 
> >    - Tablets may change to a relative mode.
> >
> >There's a race here.  How does the client know that it got relative
> >events and not absolute?
> 
> It does not have to know. The events are still "absolute". What is different
> is that if the pen is at 100,100, and the user lifts it and drops it at
> 50,50 then moves to 51,50 then the client will see a motion event to 101,100
> rather than 51,50. This I think is the same way a tablet in relative-motion
> mode works when pointer lock is off.
> 
> Also I'm not sure this is actually a good idea anyway. Now think the tablet
> should continue working as before. The user playing his FPS may want to jump
> the pen around to change direction. If the client knows the device is a
> tablet it can do this itself.
> 
> >    - 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.
> >
> >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?
> 
> The motion events have nothing to do with where the cursor is placed.
> 
> As I see it there is one pointer_lock per visible cursor, which I think
> means there is one per seat.
> 
> When the pointer lock is created all motion events, even if there are
> multiple xy devices on that seat, go to the pointer lock client, and the
> cursor stops moving and enter/leave events are not produced.
> 
> >    Examples:...
> 
> >I don't see why the above proposal doesn't also solve these cases.
> 
> I don't claim is solves any more problems, just that it is simpler, by not
> introducing a lot of new events. I also suspect it will be lot easier to
> reuse code in toolkits and clients for both pointer-lock and normal modes
> with this solution.
>