<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - wl_fixed is not precise enough for high dpi mice" href="https://bugs.freedesktop.org/show_bug.cgi?id=85715#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - wl_fixed is not precise enough for high dpi mice" href="https://bugs.freedesktop.org/show_bug.cgi?id=85715">bug 85715</a> from <a class="email" href="mailto:derekf@osg.samsung.com" title="Derek Foreman <derekf@osg.samsung.com>"> Derek Foreman</a> <pre>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. 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. 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>