[Wayland-bugs] [Bug 85715] wl_fixed is not precise enough for high dpi mice

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85715

--- Comment #4 from Jonas Ådahl <jadahl at gmail.com> ---
(In reply to Derek Foreman from comment #3)
> Libinput until 58e0fe270 was accidentally rounding some data internally, but
> now as far as I can tell it's weston.
>  
> Pointer-lock is what a game would use to get "raw" mouse data?  I think
> there's a question as to whether that will be normalized at all by libinput
> - it may be the case that it'll come out the other side entirely on the left
> of the radix point, and this problem doesn't actually exist there.

(FPS) Games will probably use a protocol called "wl_relative_pointer" that I
will send to the list in the near future. The wl_relative_pointer will send
motion events both accelerated and non-accelerated. The non-accelerated should
probably be normalized before leaving the compositor at least as clients will
not know what device an event comes from. I guess we could also pass along
resolution information with the relative motion event and not normalize the
non-accelerated coordinates, letting the client normalize, but not sure thats
better. We could still not call this "raw" however, since some devices
(touchpads) it is not reasonable to send the raw motion events.

> 
> Actually, I think even normalized, with the most ridiculous mouse I've seen
> (8200dpi) it's still like .049 units per "dot" without the accel curve's
> intervention.  If I'm doing my math right we're good to 102400DPI before we
> can't represent a dot in the absence of an accel curve.  I don't think
> anyone will argue a need for that.  It won't be me in any event.
> 
> Storing doubles internally and sending wl_fixed over the wire seems like it
> should be a solution to me.
> 
> Saving the rounded part and appending it to the next motion would fix it
> too, I think, but this seems a little uglier from an implementation
> perspective to me.

The reason for saving and appending the rounded part is that rounding before
sending over the wire the client would still loose the delta when receiving
relative motion events, resulting in the scene/pointer not moving for small
movements.

> 
> I guess right now clients are receiving a lot of motion events they don't
> need - they're even receiving motion events with no change when the round
> off occurs.  Should they only receive change above a certain threshold?

weston only sends a new motion event if the coordinates of the events changed
since last time. It does however send if the sub-pixel coordinates change,
which I think it should continue to do.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20141101/e547651b/attachment.html>