<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#c8">Comment # 8</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:x414e54@linux.com" title="x414e54@linux.com">x414e54@linux.com</a> <pre>(In reply to Derek Foreman from <a href="show_bug.cgi?id=85715#c6">comment #6</a>) > (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. I am not even sure the raw events should be normalized. As far as I know they are not on other platforms (but worth checking). Gamers expect that a higher dpi setting will move the mouse faster, and use the mouse dpi switch for sensitivity as Sniper mode or run mode etc. You do not want it that your 400 <-> 8200 dpi setting or Sniper mode button works in one way on Windows but then is slower/faster on Linux in the same game with the same settings. > > > (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? I think 1000hz plus would also begin to cause a problem because the extra calculations libinput is doing are essentially delaying the event delivery and causing extra cpu usage. You may have so much data buffered that the next time the client requests the raw events the compositor has not finished processing them. > > 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 :) SDL only supports mouse deltas as a single 32bit integer so the fractional part is already being dropped even as a double. The same with UE4 it only supports raw mouse 32bit integers. If you overflowed in one event you would probably have to just deliver the rest of the delta in the next event with the same timestamp.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>