[PATCH weston 1/3] Introduce pointer lock interface

[Bill Spitzak]

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.

> 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.