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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
