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.

Created attachment 115255 [details] [review]
0001-filter-enforce-minimum-velocity.patch

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.

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.

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);
 }

Created attachment 115285 [details]
event-debug log

Towards the end is where I was having the problem

Created attachment 115294 [details]
Log of evdev where everything seems OK

Created attachment 115295 [details]
Libinput log where there are issues

[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.

http://patchwork.freedesktop.org/patch/48517/
http://patchwork.freedesktop.org/patch/48516/
http://patchwork.freedesktop.org/patch/48518/

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