Bug 1208992

By mickey I meant the "Covered distance in device units" reported by mouse-dpi-tool. I supposed it was the same but could be wrong.

pls make sure you have the latest of libinput and xorg-x11-drv-libinput and post the versions of both here.

then install evemu and run evemu-record (as root) against your mouse device and record a short, slow-moving sequence. we can use that to replay the events here and debug this. thanks.

Hi, 

dnf report for libinput:
Version     : 0.13.0
Révision    : 1.fc22

and for xorg-x11-drv-libinput:
Version     : 0.8.0
Révision    : 2.fc22

Thanks for helping.

I'll send the evdev record. The cursor sometimes moved because it is  bit difficult to maintain a slow speed during several seconds.

Created attachment 1011696 [details]
evdev-record for nova-mouse

evdev-record for nova-mouse

What's the model number for this device (for merging upstream). Does it have adjustable DPI rates, etc? 600 is a bit odd for a fixed mouse but can be the case for mice with multiple resolutions.

libinput-0.13.0-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.13.0-3.fc22

Package libinput-0.13.0-3.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libinput-0.13.0-3.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-5755/libinput-0.13.0-3.fc22
then log in and leave karma (feedback).

libinput-0.13.0-4.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.13.0-4.fc22

It has adjustable dpi rates, from 125 to 1000Hz, and dpi from 400 to 3200 according to the maker. There is a software on windows that allow edition of the parameters, but it seems that on linux it is mostly dynamic for the frequency.
There is a button that cycles through three different DPIs though.
I'll provide info for the three DPIs.

first setting 600@1000
second setting 1200@1000
third setting 2400@1000

I never used the windows software to setup the mouse, so I suppose that these DPIs are default values stored in the mouse firmware.

The mouse model is a nova slider x600 ( http://www.microcenter.com/product/303253/slider_x600_gaming_mouse ) . Is it what you needed when you asked for the model number?
Thanks for help, I'm gonna try your fix now.

with libinput 0.13.0-4.fc22

The mouse is faster on the desktop, which is weird because it has never been that fast, and no mouse I've ever used were that fast with default settings. That being said, it is still jumpy for small movements. It is still impossible to play FPS games because of it.

I've also tried to play with and old and cheap Logitech Optical USB Mouse, very popular at many offices, and the problem is the same on the desktop (no precision for very small movements, needed, lets say, in 3D modelling) and FPS games.

Let me know how I can help. Thanks.

libinput doesn't see it when the resolution changes (it's done in the hardware only). So the rule only applies to one of the resolutions, once you switch the mouse will be very fast. Do you know which one is the default dpi it comes out of the box with? if not, I'd say use the middle one and this rule here:

mouse:usb:v1ee2p0001:name:NOVA USB Full speed gaming mouse:
 MOUSE_DPI=600@1000 *1200@1000 2400@1000

then hw-switch the mouse to the middle resolution, that should then provide the correct pointer speed. does that work?

http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/70-mouse.hwdb has the instructions on how to add a local hwdb entry.

Thanks for helping me managing the cursor speed. I'm using the provided settings but since I don't know the speed the cursor is supposed to have, and got used to it anyway, I'll probably leave it that way.

To re-focus on the initial issue, after trying with another mouse, I really don't think that the issue with precise movements lies with DPI settings.

Have you tried to play a FPS, such as OpenArena (or any FPS games)? With my NOVA mouse or a cheap Dell mouse, it is unplayable because small and precise movements have no impact on the camera's rotation. Do you have the same experience? What can I do to more precisely pinpoint the bug's actual location?
Thanks

libinput-0.13.0-6.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libinput-0.13.0-6.fc22

grab libinput from git (http://cgit.freedesktop.org/wayland/libinput/) and run the tools/event-debug helper as root. That listens to the device directly without any desktop in the way so you can see what events are produced by libinput itself. Could be that the bug is somewhere in the server if the events aren't accumulating correctly.

Hi,

I built the latest master libinput, and recorded the following sequence.
My observation is, that when the x-variation or y variation is below something like 0.10-ish, the cursor does not move.

event4 	POINTER_MOTION	+448.40s	  0.35/  0.00
event4 	POINTER_MOTION	+448.42s	  0.41/  0.00
event4 	POINTER_MOTION	+448.43s	  0.00/ -0.49
event4 	POINTER_MOTION	+448.45s	  0.55/  0.00
event4 	POINTER_MOTION	+448.47s	  0.00/ -0.53
event4 	POINTER_MOTION	+448.71s	 -0.29/  0.00
event4 	POINTER_MOTION	+449.85s	 -0.03/  0.00
event4 	POINTER_MOTION	+450.03s	  0.00/  0.00
event4 	POINTER_MOTION	+450.32s	 -0.00/  0.00
event4 	POINTER_MOTION	+450.59s	  0.00/  0.00
event4 	POINTER_MOTION	+450.91s	 -0.00/  0.00
event4 	POINTER_MOTION	+451.29s	  0.00/  0.00
event4 	POINTER_MOTION	+451.50s	 -0.00/  0.00
event4 	POINTER_MOTION	+451.87s	  0.00/  0.00
event4 	POINTER_MOTION	+452.73s	 -0.00/  0.00
event4 	POINTER_MOTION	+453.16s	  0.00/  0.00
event4 	POINTER_MOTION	+454.02s	 -0.00/  0.00
event4 	POINTER_MOTION	+454.64s	  0.00/  0.00
event4 	POINTER_MOTION	+455.06s	 -0.00/  0.00
event4 	POINTER_MOTION	+456.19s	  0.00/  0.00
event4 	POINTER_MOTION	+457.89s	 -0.00/  0.00
event4 	POINTER_MOTION	+458.64s	  0.00/  0.00
event4 	POINTER_MOTION	+459.08s	 -0.00/  0.00
event4 	POINTER_MOTION	+459.32s	 -0.03/  0.00
event4 	POINTER_MOTION	+459.53s	  0.03/  0.00
event4 	POINTER_MOTION	+459.82s	  0.02/  0.00
event4 	POINTER_MOTION	+460.26s	  0.02/  0.00
event4 	POINTER_MOTION	+460.82s	  0.00/  0.00
event4 	POINTER_MOTION	+460.85s	  0.00/ -0.00
event4 	POINTER_MOTION	+460.88s	  0.00/  0.00
event4 	POINTER_MOTION	+461.25s	 -0.00/  0.00
event4 	POINTER_MOTION	+461.46s	  0.00/ -0.03
event4 	POINTER_MOTION	+462.08s	  0.00/ -0.03
event4 	POINTER_MOTION	+462.61s	 -0.00/  0.00
event4 	POINTER_MOTION	+462.90s	  0.00/ -0.02
event4 	POINTER_MOTION	+463.17s	  0.00/  0.02
event4 	POINTER_MOTION	+463.41s	  0.03/  0.00
event4 	POINTER_MOTION	+463.44s	  0.00/  0.07

My guess here is that there is a kind of noise reduction mechanism somewhere, maybe to avoid cursor flickering when someone uses a touchpad, but ends up also "smoothing" the mouse. It is just a guess though.

can you try this scratch build here please: http://koji.fedoraproject.org/koji/taskinfo?taskID=9532690

the problem is that if the movement is slow enough, the velocity calculation "times out", i.e. it can't find a previous event to calculate the current velocity. This results in the speed being 0 which turns the deltas to 0.

This scratch build is a quickfix to up the timeout from 300ms to 1 second. Let me know if that fixes the issue or if there's more to it, there could be another bug hidden in there.

And here's a second scratch build, please try that too. This one is a more correct fix. It ensures that there's a minimum velocity for each movement.
scratch build of the fix alone:
http://koji.fedoraproject.org/koji/taskinfo?taskID=9532949

scratch build with both timeout and the minimum velocity fix:
http://koji.fedoraproject.org/koji/taskinfo?taskID=9532958

As said in the upstream bug I don't know if we still need the larger timeout once the min. velocity fix is in, so I've attached both. Let me know how you go.

libinput-0.13.0-6.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Hi, I've tested the second build https://kojipkgs.fedoraproject.org//work/tasks/2960/9532960/libinput-0.14.1-2.bz1208992.fc22.x86_64.rpm

The problem persists. It is impossible to do precise movements.

I think I agree that this is the same bug as https://bugs.freedesktop.org/show_bug.cgi?id=90086 .

Do you experience the issue as well? It seems that anyone playing games hits it, and I can reproduce it even on OpenArena.

Hi,
Is there something I can do to help, like testing a build?
Thanks for your help

not yet, I'm still trying to figure out where this issue comes from, sorry (and fixing a number of other bugs).

An explanation on how to reproduce it reliable won't go amiss though - the more reliable and less time I have to spend on reproducing it, the more likely can I find the bug. I take evemu recordings too if they can reproduce the problem during evemu-play.

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.

I forgot, if you are affected by this I recommend uninstalling xorg-x11-drv-libinput for now (or removing /usr/share/X11/xorg.conf.d/90-libinput.conf) and instead using xorg-x11-drv-evdev and xorg-x11-drv-synaptics. A solution to this requires updates to the server (addition of a public API) and the matching changes to xorg-x11-drv-libinput.

The server API requires upstream review, so this will take a few days.

Great news, thanks! This is going to make many linux gamers happy :)

I wanted to let you know, that, now using the xorg-x11-drv-evdev, the change is also very noticeable even in daily desktop use for pixel-precise movements.

FYI, I've sent a patchset out to the xorg-devel list that should address this issue.

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

*** Bug 1222278 has been marked as a duplicate of this bug. ***

FYI, I've sent a pull request to Keith, hoping this should be in the X server soon.

Great news, I'll keep my fingers crossed :)

I just wanted to say I'm also having this issue. Just installed Fedora 22 and the mouse just feels wrong compared to Fedora 21. I had to set the sensitivity to lowest in the system and increase it on my mouse (gaming mouse) to get the feel somewhat bearable.

alex: you're seeing a different issue, please file a new bug and assign it to me, together with the output of the mouse-dpi-tool. Thanks.

No I have the same issue. Removed xorg-x11-drv-libinput and it's solved.

This issue only affects games using SDL and other clients using the Xorg DGA extension. Is that what you're seeing? If so, then sorry, you're right, it's the same issue. If you're seeing the wrong movement speed during normal desktop use, then your mouse needs a hwdb entry -> new bug please.

I've pushed the server and xorg-x11-drv-libinput to rawhide now:
http://koji.fedoraproject.org/koji/buildinfo?buildID=638981
http://koji.fedoraproject.org/koji/buildinfo?buildID=638975

You should be able to run those on f22 as well for testing, let me know how you go. F22 builds will come soonish too, but any testing ahead of time would be appreciated.

I wish I could but 

dnf install xorg-x11-drv-libinput-0.10.0-3.fc23.x86_64.rpm xorg-x11-server-Xorg-1.17.1-14.fc23.x86_64.rpm  xorg-x11-server-common-1.17.1-14.fc23.x86_64.rpm

fails with  
nothing provides libdbus-1.so.3(LIBDBUS_1_3)(64bit) needed by xorg-x11-server-Xorg-1.17.1-14.fc23.x86_64.

even though I do have dbus and libdbus.

I don't really get the whole dnf thing so i'll let the updates come through the usual channels unless you eventually let me know how to install the test packages.

Thanks

I installed the rawhide xorg-x11-drv-libinput package. I can confirm the deadzone bug is no longer present.

(In reply to Peter Hutterer from comment #35)
> This issue only affects games using SDL and other clients using the Xorg DGA
> extension. Is that what you're seeing? If so, then sorry, you're right, it's
> the same issue. If you're seeing the wrong movement speed during normal
> desktop use, then your mouse needs a hwdb entry -> new bug please.

I'm not sure what I have, but once I removed xorg-x11-drv-libinput it got solved on the desktop. I was having really really really bad desktop mouse movement. Slow mouse movement resulted in like no or almost no mouse movement. Maybe it's a different issue. Not familiar with hwdb but it worked in Fedora 21 and it works now with xorg-x11-drv-libinput gone.

(In reply to fred from comment #37)
> I wish I could but 
> 
> dnf install xorg-x11-drv-libinput-0.10.0-3.fc23.x86_64.rpm
> xorg-x11-server-Xorg-1.17.1-14.fc23.x86_64.rpm 
> xorg-x11-server-common-1.17.1-14.fc23.x86_64.rpm
> 
> fails with  
> nothing provides libdbus-1.so.3(LIBDBUS_1_3)(64bit) needed by
> xorg-x11-server-Xorg-1.17.1-14.fc23.x86_64.
> 
> even though I do have dbus and libdbus.

yeah, not your fault, caused by some new rpm flags in rawhide I guess (or possibly a change in the dbus library, haven't looked into it). sorry about that, I only looked at the xorg changes and they are compatible between f22 and rawhide, hence my wrong assumption that you can install it.

(In reply to alexhultman from comment #39)
> I'm not sure what I have, but once I removed xorg-x11-drv-libinput it got
> solved on the desktop. I was having really really really bad desktop mouse
> movement. Slow mouse movement resulted in like no or almost no mouse
> movement. Maybe it's a different issue. Not familiar with hwdb but it worked
> in Fedora 21 and it works now with xorg-x11-drv-libinput gone.

as I said, you have a different issue, please file a separate bug so we can fix it.

I ran into the same problem in the recently released Fedora 22 (installed the Workstation spin).  I'm using an ancient AOpen USB optical mouse, with no special features.  GNOME desktop.  libinput 0.15.0-1.fc22  And likely suffering from the X server bug Peter Hutterer mentioned.

I did find a better way of detecting this bug.  It's more obvious when you compare mouse movements in different directions.  If you move slowly vertically or horizontally, the cursor moves smoothly.  If you move diagonally, the cursor stutters and seems to stick.  Under other operating systems (Fedora 21 too), diagonal movement is smooth.

How can I check that I'm using libinput as an input driver ? I'd like to close this bug, but I want to make sure that I'm running libinput and not another input driver.
Since I messed up with my conf files in /usr, I'm not sure I put them back in the right state or place. so it's best if I have a quick way to check the driver I'm running.
Thanks

xinput list-props "device name"
if you see a bunch of properties starting with libinput then you have the libinput driver for that device. you could also check the xorg.log with journalctl but it's a bit harder to parse.

btw, whenever you change config files put them in /etc/X11/ rather than /usr. X reads both directories and the split is designed so you can have distro-installed files at the same time as manually added ones.

Alexander: different bug, please file a new one and assign it to me. I'm renaming this one now so we don't mix them up.

$]  xinput list-props 10
Device 'NOVA USB Full speed gaming mouse':
	Device Enabled (135):	1
	Coordinate Transformation Matrix (137):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Accel Speed (271):	0.000000
	libinput Accel Speed Default (272):	0.000000
	libinput Natural Scrolling Enabled (273):	0
	libinput Natural Scrolling Enabled Default (274):	0
	libinput Send Events Modes Available (256):	1, 0
	libinput Send Events Mode Enabled (257):	0, 0
	libinput Send Events Mode Enabled Default (258):	0, 0
	libinput Left Handed Enabled (275):	0
	libinput Left Handed Enabled Default (276):	0
	libinput Scroll Methods Available (277):	0, 0, 1
	libinput Scroll Method Enabled (278):	0, 0, 0
	Device Node (259):	"/dev/input/event4"
	Device Product ID (260):	7906, 1

So I believe it's a fix ;)

Thanks!

xorg-x11-drv-libinput-0.10.0-5.fc22,xorg-x11-server-1.17.1-14.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/xorg-x11-drv-libinput-0.10.0-5.fc22,xorg-x11-server-1.17.1-14.fc22

moving to ON_QA, this is a normal bug, fix is in flight see comment 45

Hi,

I have exactly the same problem with my mouse under Fedora 22:

"xinput list-props 8
Device 'Microsoft Comfort Mouse 6000'"

I use the following packages:

xorg-x11-server-Xorg.x86_64 --> 1.17.1-14.fc22 
xorg-x11-drv-libinput.x86_64 --> 0.10.0-5.fc22 
libinput.x86_64 --> 0.15.0-1.fc22   


I have run mouse-dpi-tool, I see exactly the same problem as the original bug. The mouse movements were fine under Fedora 21.

Same Problem, Fedora 22, playing Urban Terror


Device 'Logitech G500':
	Device Enabled (148):	1
	Coordinate Transformation Matrix (150):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Accel Speed (280):	0.000000
	libinput Accel Speed Default (281):	0.000000
	libinput Natural Scrolling Enabled (282):	0
	libinput Natural Scrolling Enabled Default (283):	0
	libinput Send Events Modes Available (265):	1, 0
	libinput Send Events Mode Enabled (266):	0, 0
	libinput Send Events Mode Enabled Default (267):	0, 0
	libinput Left Handed Enabled (284):	0
	libinput Left Handed Enabled Default (285):	0
	libinput Scroll Methods Available (286):	0, 0, 1
	libinput Scroll Method Enabled (287):	0, 0, 0
	libinput Middle Emulation Enabled (288):	0
	libinput Middle Emulation Enabled Default (289):	0
	Device Node (268):	"/dev/input/event3"
	Device Product ID (269):	1133, 49256

Installed Packages
Name        : libinput
Arch        : x86_64
Epoch       : 0
Version     : 0.15.0
Release     : 4.fc22

xorg-x11-drv-libinput-0.10.0-5.fc22, xorg-x11-server-1.17.1-14.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Well, it's happening again.

* Fedora 22 Workstation, 64 bit.
* xorg-x11-server-1.17.2
* xorg-x11-drv-libinput-0.11.0-1.fc22.x86_64
* libinput-0.19.0-1.fc22.x86_64

Note: It happens with both Microsoft and Steelseries usb mouses that I have. Both of them were working great before last libinput/xorg update.


Should I open a new bug ticket?

I can confirm that the bug is back, in Openarena, counter strike: GO and shadow warrior (steam)

xorg-x11-drv-libinput-0.11.0-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/xorg-x11-drv-libinput-0.11.0-3.fc22

sorry about that, I dropped the patch with the 0.11 update. but the ABI versions we need in F22 is different to what the upstream patch is written for. all fixed now

0.11.0-3.fc22 works for me in Red Eclipse stable upstream.

Thank you, Peter!

Package xorg-x11-drv-libinput-0.11.0-3.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-libinput-0.11.0-3.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11518/xorg-x11-drv-libinput-0.11.0-3.fc22
then log in and leave karma (feedback).

xorg-x11-drv-libinput-0.11.0-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Hey Peter I just wanted to let you know with libinput 0.20 my problems are solved and it works really well. It probably wasn't this bug but anyhow - it works well now. Moving the cursor on the gnome desktop feels nice now and gaming works very well.