<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#c10">Comment # 10</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 Peter Hutterer from <a href="show_bug.cgi?id=85715#c9">comment #9</a>) > (In reply to x414e54 from <a href="show_bug.cgi?id=85715#c8">comment #8</a>) > > 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. > > fwiw, we only normalize the "default" setting, whatever that is. since we > can't detect when the HW changes resolution, doubling the resolution through > a switch on the mouse will provide deltas twice as high. I still have a few issues because this does not solve the problem that the delta is going to be different on Linux than on Windows for the same hardware. To get the same value I would have to find the dpi of the mouse that was used and then un-normalize the relative deltas. Especially in something like an FPS they do not deal with mouse movement in physical units and expect an integer delta. Especially as mouse sensitivity is applied in the main engine code not in the platform specific code you are going to loose a lot of information. Also I might be wrong but for example assuming 1000hz poll at 8400 dpi, normalized based on a 4200 default. Any movement less than 1/4 of an inch per second would get each individual delta rounded by the application unless they were coalesced. If the application rounded down then the mouse would not move at all and if it always round up then the game would assume the mouse moved 1 inch and not 1/4. Is it actually part of the wayland spec that the mouse deltas would be normalized to 1000dpi for example? As it is not specifically mentioned, so there might be some window managers that do not normalize and some that do. > > > > 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. > > I wonder if that's a real issue at this point. The calculations for normal > mice are fairly limited (acceleration only) so before we start optimising > here I'd like to see some real-world issues. Well it may or may no be an issue. If you are sure every compositor is going to be able to process and queue every mouse event within <1ms without adding additional latency then I guess it is not an issue. > fwiw, one of the things the X server used to do for exactly this problem was > to squash motion events together. easy since everything was already in > absolute coords by then but some smarter squashing could probably be done by > the compositor. Yes this works fine for normal GUI use but for certain applications you may need to know the timestamp of each individual event or actually receive each individual event within 1ms. Maybe to draw the specific path the mouse took or to calculate who clicked first. So coalescing them is going to be a problem and seems to defeats the purpose of a high poll rate mouse. There would need to be some way to disable the coalescing or squashing. This is why I was thinking towards something more of a real raw input system and just take the compositor out of the loop completely.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>