<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#c6">Comment # 6</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>(In reply to Pekka Paalanen from <a href="show_bug.cgi?id=85715#c5">comment #5</a>) > (In reply to Derek Foreman from <a href="show_bug.cgi?id=85715#c3">comment #3</a>) > > 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. > > I missed something. Why don't you see a problem with relative motion, when > you filed this bug in the first place? Assuming both would use wl_fixed_t. > > Or was the comment not about relative motion events? I had errantly assumed that relative motion would be passed "raw", or simply normalized but not accelerated. > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=85715#c2">comment #2</a>) > > If deltas and coordinates in wl_fixed_t is enough for clients to work > > properly, we could just cut off the left over fraction from converting from > > double to wl_fixed_t and append it to the next event. This would fix the > > issue of small movements being dropped. > > I'd rather not go mangling the event data like this. I can't explain it, but > it feels "dirty". You do not deliver all of a physical (raw) event, but let > it somehow affect following events, that is, the physical vs. protocol > events are not exactly N:1. I can't give an example when that matters. I do > expect, that not all clients will linearly accumulate the relative motion. > They could do something else, like control a 3D-rotation where the order of > operations matters. I just have a feeling that "carrying fractions over" > will shoot someone's foot in the future. > > > What it wouldn't fix is clients > > receiving these small movements, and to fix that we either need a new larger > > data type in the Wayland wire protocol, or have a non-fraction and fraction > > values as separate ints or something. > > Yeah. Let's go with this. For instance, int32_t for integer part plus > uint32_t for fractional part. It takes the same amount of bytes as a double. > It's simple. It's obvious. It's not surprising. I do wonder if libinput could just calibrate the low end of its accel curve so that a single "dot" mouse motion would result in 1/256 units of motion. Some of these gamer mice also have ludicrous poll rates (1kHz is common, I'm not making this up. Please future reader don't feel the need to explain screen refresh rates to me - I did not design these mice.) is it worthwhile to try to keep the size of these events smaller than a double? If that's not a concern, your int+frac notation seems to solve the problem with a maximum of overkill and a minimum of ambiguity. I just hope developers don't decide throwing away the frac part is ok :)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>