<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - xf86-input-libinput: Rough and lopsided mouse movement in games/apps that reposition mouse" href="https://bugs.freedesktop.org/show_bug.cgi?id=96982#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - xf86-input-libinput: Rough and lopsided mouse movement in games/apps that reposition mouse" href="https://bugs.freedesktop.org/show_bug.cgi?id=96982">bug 96982</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>(In reply to Danni H from <a href="show_bug.cgi?id=96982#c8">comment #8</a>) > You mention that subpixel movement is buffered inside the server. Would this > make it an X.org Server bug, then? Does WarpPointer take integer or float > arguments for the destination coordinates? Will this bug remain after the > move to Wayland? That is probably what concerns me the most right now. WarpPointer predates subpixel coordinates by about 20 years :) so no, it only takes integer coordinates. There is an XIWarpPointer request that takes subpixel coordinates but that requires switching to XI2 (which is only... 8 years old?) we cannot change the WarpPointer protocol request itself because that's ABI and has been for 20 years. Either way, since this is a protocol restriction it will not affect Wayland clients directly but likely still be an issue when XWayland is in play. > > The odd thing about unity3d here is that it continuously sends WarpPointer > > requests (and to which the server replies with a core Motion event). unity3d > > does this that even while the mouse isn't moving. > > I believe this is also fairly standard practice among applications that use > this method of mouse movement (and why I don't think this is strictly > Unity3D's fault - see SLADE also has this issue). Additionally, if the > application were to reposition the mouse pointer only if the mouse were > moving, it would still result in the fractional becoming lost, so movement > would still be somewhat lopsided. yeah, I agree, it'd still not be right but slightly less of an issue. The thing is: you still have this issue with evdev whenever pointer acceleration causes subpixel motion (I'd have to figure out when exactly this happens), it's just not as obvious. You can somewhat work around this by using the libinput "flat" acceleration profile. In that mode no pointer acceleration is performed by libinput and motion is sent as-is to the server (which also doesn't accelerate). So you only get full-pixel motion and many people claim it provides a more natural feel for games anyway (ymmv). > If I propose a patch, will it be considered for inclusion? Or, is there some > workaround that can be applied here to the hundreds of Unity3D games that > will basically never receive an update to fix the issue? tbh, I don't know *how* to fix this (short of the above workaround). I contemplated the idea of making the xserver aware about within-pixel warp requests so that it retains the subpixel data when we're warping from 100.4 to 100. That would be relatively easy but it would cause odd and inconsistent behaviour once we go beyond the first pixel so that's a no-go. And short of that hack I cannot come up with a satisfying solution.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>