<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#c5">Comment # 5</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:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> Pekka Paalanen</a> <pre>(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? (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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>