Bug 90086

Summary: Mouse "deadzone" makes games unplayable
Product: xorg Reporter: Jonathan Cox <joncox1987>
Component: Server/Input/CoreAssignee: Peter Hutterer <peter.hutterer>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium CC: peter.hutterer
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
0001-filter-enforce-minimum-velocity.patch
none
0001-filter-up-the-motion-timeout-to-1-second.patch
none
event-debug log
none
Log of evdev where everything seems OK
none
Libinput log where there are issues none

Description Jonathan Cox 2015-04-18 15:28:05 UTC
Mouse movement does not appear to track with very slow and precise movement in games.  During normal desktop usage this does not appear to be an issue.  I have found numerous threads discussing this in detail. Seems to affect every window manager I have tried and persists across multiple machines.

Just one of several threads I have found about this issue.

https://bbs.archlinux.org/viewtopic.php?id=195147
Comment 1 Peter Hutterer 2015-04-22 02:30:38 UTC
ok, found the issue. really slow movement times out the velocity calculator.  That results in a zero velocity and a zero movement. Two patches coming up to fix this.
Comment 2 Peter Hutterer 2015-04-22 02:33:31 UTC
Created attachment 115255 [details] [review]
0001-filter-enforce-minimum-velocity.patch
Comment 3 Peter Hutterer 2015-04-22 02:34:19 UTC
Created attachment 115256 [details] [review]
0001-filter-up-the-motion-timeout-to-1-second.patch

I don't know if this one is still needed with the other one, but if the speed is too high on slow movements now then we may need to up the timeout like in this patch here.
Comment 4 Jonathan Cox 2015-04-23 01:58:30 UTC
It seems like the patches made a little bit of a change here, but its still not quite right.  I'm not really sure how to describe this, but it doesn't really feel fluid. Mouse stutters a little bit as I try to move it slowly but doesn't move other than that. Before it didn't seem to move at all if I went slowly.
Comment 5 Peter Hutterer 2015-04-23 06:09:38 UTC
pls grab the libinput code from git, build it and run
    sudo ./tools/event-debug --device /dev/input/eventX

against your device node. move the mouse slowly, as you usually do and attach the output here. That should give more hints as to what's happening.
Please apply the two patches though. And you probably need to change the printf line in print_motion_event() too to see the small movements:

diff --git a/tools/event-debug.c b/tools/event-debug.c
index 3629e74..c1ae9ca 100644
--- a/tools/event-debug.c
+++ b/tools/event-debug.c
@@ -210,7 +210,7 @@ print_motion_event(struct libinput_event *ev)
 
        print_event_time(libinput_event_pointer_get_time(p));
 
-       printf("%6.2f/%6.2f\n", x, y);
+       printf("%f/%f\n", x, y);
 }
Comment 6 Jonathan Cox 2015-04-23 06:50:20 UTC
Created attachment 115285 [details]
event-debug log

Towards the end is where I was having the problem
Comment 7 Jonathan Cox 2015-04-23 15:34:59 UTC
Created attachment 115294 [details]
Log of evdev where everything seems OK
Comment 8 Jonathan Cox 2015-04-23 15:35:59 UTC
Created attachment 115295 [details]
Libinput log where there are issues
Comment 9 Peter Hutterer 2015-04-30 06:43:29 UTC
[copy of my comment on https://bugzilla.redhat.com/show_bug.cgi?id=1208992#c24]

ok, I finally fired up openarena and it's quite obvious what the problem is. I put a printf into libinput and whenever the delta is less than 1 it won't move.

Bit of further investigation showed the problem isn't in libinput, that works as expected. Problem is in the DGA code in the X server. There the delta is cast to an int but it doesn't accumulate (it does for normal pointer motion but DGA hooks in differently). So for all deltas less than 1 you get a DGA motion event of 0, without accumulation.

This would've affected any device in the past, the reason this only popped up now is because previously the devices sent integer deltas which were fed into the DGA system directly, before acceleration applied. So the min delta was always 1.

libinput does pointer acceleration, the delta it passes on is already normalized and accelerated (or decelerated, in this case). Hence the small deltas which disappear when casting to int.

Moving this to the server, this needs to be fixed there.
Comment 11 Peter Hutterer 2015-06-01 01:12:25 UTC
commit 4c2f2cb4c8ca1ab894a65828fdd39aea9b014f69
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue May 5 14:18:54 2015 +1000

    dix: Add unaccelerated valuators to the ValuatorMask

commit da10d0cb4283ad5a9c4290555751f61795d11b49
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue May 5 14:48:41 2015 +1000

    dix: hook up the unaccelerated valuator masks


And in the xf86-input-libinput driver:
commit 19c91044e44dd31deaeb638a919c64e9a9182448
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue May 5 14:17:10 2015 +1000

    Use the new unaccelerated valuator ValuatorMask features

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.