Bug 1208992 - Mouse cursor doesn't move in SDL games like openarena when moving the physical mouse slowly.
Summary: Mouse cursor doesn't move in SDL games like openarena when moving the physica...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1222278 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-04 22:32 UTC by fred
Modified: 2015-07-31 21:53 UTC (History)
11 users (show)

Fixed In Version: xorg-x11-drv-libinput-0.11.0-3.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-16 02:37:18 UTC


Attachments (Terms of Use)
evdev-record for nova-mouse (111.44 KB, text/plain)
2015-04-07 11:21 UTC, fred
no flags Details


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 90086 None None None Never

Description fred 2015-04-04 22:32:07 UTC
Description of problem:

Cursor doesn't move when I move the mouse slowly. More precisely, mouse-dpi-tool records the movement, but cursor does not move until the actual mouse reports more than ~10 'mickeys' per second.
It makes it very difficult to aim for elements close to the mouse cursor; since the speed must then be above 10 micks, but then cursor feels jumpy.
More importantly, it makes it really difficult to aim precisely in fps games, making them unplayable.

How reproducible:
Always

Additional Info:
I ran mouse-dpi-tool and got the following rule;
mouse:usb:v1ee2p0001:name:NOVA USB Full speed gaming mouse:
 MOUSE_DPI=600@1000

loading this udev rule made no difference.
I read about "mouse accceleration" but didnt find how to disable it to assess whether it is related or not.

Let me know if you need additional info.

FB

Comment 1 fred 2015-04-04 22:34:06 UTC
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.

Comment 2 Peter Hutterer 2015-04-07 06:58:51 UTC
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.

Comment 3 fred 2015-04-07 11:20:31 UTC
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.

Comment 4 fred 2015-04-07 11:21:48 UTC
Created attachment 1011696 [details]
evdev-record for nova-mouse

evdev-record for nova-mouse

Comment 5 Peter Hutterer 2015-04-08 05:32:10 UTC
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.

Comment 6 Fedora Update System 2015-04-08 06:22:26 UTC
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

Comment 7 Fedora Update System 2015-04-08 18:36:02 UTC
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).

Comment 8 Fedora Update System 2015-04-08 22:05:13 UTC
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

Comment 9 fred 2015-04-10 09:40:10 UTC
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.

Comment 10 fred 2015-04-10 10:26:43 UTC
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.

Comment 11 fred 2015-04-10 11:13:51 UTC
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.

Comment 12 Peter Hutterer 2015-04-13 01:28:43 UTC
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.

Comment 13 fred 2015-04-16 17:56:18 UTC
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

Comment 14 Fedora Update System 2015-04-17 00:35:01 UTC
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

Comment 15 Peter Hutterer 2015-04-17 04:35:42 UTC
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.

Comment 16 fred 2015-04-17 23:36:37 UTC
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

Comment 17 fred 2015-04-21 11:17:07 UTC
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.

Comment 18 Peter Hutterer 2015-04-22 01:53:44 UTC
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.

Comment 19 Peter Hutterer 2015-04-22 02:38:51 UTC
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.

Comment 20 Fedora Update System 2015-04-22 22:46:31 UTC
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.

Comment 21 fred 2015-04-23 22:07:25 UTC
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.

Comment 22 fred 2015-04-28 22:04:04 UTC
Hi,
Is there something I can do to help, like testing a build?
Thanks for your help

Comment 23 Peter Hutterer 2015-04-29 06:00:46 UTC
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.

Comment 24 Peter Hutterer 2015-04-30 06:42:24 UTC
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 25 Peter Hutterer 2015-04-30 07:14:07 UTC
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.

Comment 26 fred 2015-04-30 22:25:59 UTC
Great news, thanks! This is going to make many linux gamers happy :)

Comment 27 fred 2015-05-01 13:35:01 UTC
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.

Comment 28 Peter Hutterer 2015-05-05 05:24:47 UTC
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/

Comment 29 Peter Hutterer 2015-05-18 03:14:06 UTC
*** Bug 1222278 has been marked as a duplicate of this bug. ***

Comment 30 Peter Hutterer 2015-05-20 03:06:11 UTC
FYI, I've sent a pull request to Keith, hoping this should be in the X server soon.

Comment 31 fred 2015-05-21 14:45:56 UTC
Great news, I'll keep my fingers crossed :)

Comment 32 alexhultman 2015-05-23 00:50:04 UTC
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.

Comment 33 Peter Hutterer 2015-05-25 00:42:40 UTC
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.

Comment 34 alexhultman 2015-05-25 00:56:16 UTC
No I have the same issue. Removed xorg-x11-drv-libinput and it's solved.

Comment 35 Peter Hutterer 2015-05-25 01:00:59 UTC
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.

Comment 36 Peter Hutterer 2015-05-26 03:09:31 UTC
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.

Comment 37 fred 2015-05-26 15:46:46 UTC
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

Comment 38 leggirly 2015-05-26 19:32:22 UTC
I installed the rawhide xorg-x11-drv-libinput package. I can confirm the deadzone bug is no longer present.

Comment 39 alexhultman 2015-05-26 20:09:57 UTC
(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.

Comment 40 Peter Hutterer 2015-05-26 23:50:59 UTC
(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.

Comment 41 Alexander G. M. Smith 2015-05-27 20:47:58 UTC
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.

Comment 42 fred 2015-05-29 00:48:13 UTC
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

Comment 43 Peter Hutterer 2015-05-29 01:50:10 UTC
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.

Comment 44 fred 2015-05-29 14:17:28 UTC
$]  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!

Comment 45 Fedora Update System 2015-06-01 02:54:30 UTC
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

Comment 46 Peter Hutterer 2015-06-01 03:03:40 UTC
moving to ON_QA, this is a normal bug, fix is in flight see comment 45

Comment 47 Kadir 2015-06-01 20:24:19 UTC
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.

Comment 48 Matt Tober 2015-06-05 21:18:56 UTC
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

Comment 49 Fedora Update System 2015-06-05 23:51:35 UTC
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.

Comment 50 Vinicius Reis 2015-07-11 00:30:42 UTC
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?

Comment 51 fred 2015-07-11 21:09:02 UTC
I can confirm that the bug is back, in Openarena, counter strike: GO and shadow warrior (steam)

Comment 52 Fedora Update System 2015-07-12 23:04:01 UTC
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

Comment 53 Peter Hutterer 2015-07-12 23:06:02 UTC
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

Comment 54 Diogo Campos 2015-07-13 05:09:47 UTC
0.11.0-3.fc22 works for me in Red Eclipse stable upstream.

Thank you, Peter!

Comment 55 Fedora Update System 2015-07-14 15:34:39 UTC
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).

Comment 56 Fedora Update System 2015-07-16 02:37:18 UTC
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.

Comment 57 alexhultman 2015-07-31 21:53:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.