The mouse cursor moves jerkily and sticks (doesn't move for short periods of time) when the mouse is moved slowly. It's more noticeable for diagonal movement. Using Fedora 22 x86 64 bit workstation spin updated as of June 1 2015, libinput version 0.15.0-1.fc22, GNOME desktop, standard AOpen optical mouse. 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 (Windows, Fedora 21 too), diagonal movement is smooth. I suggest looking at the whole mouse coordinate pipeline. I speculate that if something like mouse movement distance (perhaps needed for acceleration) is calculated somewhere as an integer rather than a float (a diagonal movement has fractional X and Y movement values when vertical and horizontal would be over 1.0 for the same movement speed) which would make diagonal movements seem slower to the mouse acceleration calculations. Anyway, it makes fine movements to select small objects on the screen more difficult than before. Other possibly related bugs are: 1225535 (erratic VMWare mouse), 1222214 (touchpad movement, libinput), 1218660 (touchpad movement jerky), 1208992 (slow mouse is jerky in SDL games), 1204387 (jerky mouse compared to Fedora 21)
give this one a try please: http://koji.fedoraproject.org/koji/taskinfo?taskID=9912847
Yes, MUCH better! Diagonal moves are now as good as any other direction. libinput-0.16.0-2.bz1227039.fc22.x86_64.rpm got it working again.
libinput-0.16.0-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.16.0-2.fc22
libinput-0.16.0-3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.16.0-3.fc22
libinput-0.16.0-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.16.0-4.fc22
I too have this problem, I commented on #1208992. I have tried libinput-0.16.0-4.fc22, the problem persists. I also made an hwdb entry for my mouse (Microsoft Comfort Mouse 6000). It didn't help. I confirmed it working via: udevadm info /dev/input/event8 | grep MOUSE_DPI --> MOUSE_DPI=1000@125. The problem is that on very low motions, pixel by pixel, the cursor does not move, when you speed up a little the cursor lags, at normal/high speeds there is no problem. In Fedora 21 (and other distros) everything is perfect.
Kadir, can you record such a slow motion with evemu-record and attach it here. Thanks. Note that 1000 DPI is the default anyway, so the hwdb entry doesn't change things - don't expect it to magically fix things ;)
Here is a recording of a sequence of such slow motions attached. The issue is very noticeable when I move sliders controls. For example I have this extension called Dash to Dock. There is a slider control for increasing/decreasing the size of the dock. The slider moves per pixel. So if I wanted to increase the size of the dock by 1px, I should move the slider very slowly. With this mouse issue, it is very hard to move it by one pixel. It becomes even harder when the slider control has a sticking/snapping point, for example the slider control for balancing the left and right audio outputs has such a point right in the middle. The same goes for when your, let's say, watching a (YouTube)movie. If I want to go forwards or backwards for a couple seconds (or scrubbing to a certain point in the movie), it becomes very difficult to do that. Only when you speed up the mouse movements considerably, the mouse moves smoothly. So to summarize: --> When you stop moving the mouse and then move very slowly (for example with slider controls), the cursor does not move or it starts lagging as you try speeding up (making it very hard to do precise movements) --> When you are normally using the mouse and want to close a window, as you move the mouse slower when you come closer to the X (to close a window), the mouse starts moving a lot slower than expected, thereby making it hard to hit a button. I can imagine that for a person who does some graphics work or photo editing, this mouse behaviour can be frustrating. I have tried everything I could think of (not that know that much), including making a hwdb entry :) Just for testing I fired up Ubuntu Mate 15.04, the mouse movements are perfect there. Fedora 20/21 also did not have this problem. If I can be more of assistance to you, let me know. I can test out new builds also. Maybe the problem is that there is some sort of faulty or unintended acceleration/de-acceleration going on...
Created attachment 1034456 [details] recording with evemu-record
libinput-0.17.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.17.0-1.fc22
kadir: try this scratch build here please http://koji.fedoraproject.org/koji/taskinfo?taskID=9938199
Peter, thank you for this build, your hard work and letting me test it out. There is certainly an improvement of the mouse behaviour. It takes less amount of force to move the mouse. So the mouse moves even with the slightest touch, that is very good. I tested that out with mouse-dpi-tool and whereas it used to take around 8 or 9 mickeys to move the cursor, it now takes only 2 or 3. But the amount of lag still seems a little bit too much. When I start moving the mouse slowly, the cursor still lags a bit behind my movements, this lagging disappears at normal and high speeds. Is it possible that this can be tweaked a little bit more? I do not know if this is a bug or expected behaviour. Like I said, in Fedora 21 this was not like this. For the sake of comparison, I really looked closer at the behaviour of the mouse of the PC at my office (Windows 7 Pro). In Win 7 the mouse takes almost no force to move and it seems there is no acceleration, at least not observable. The mouse always moves at the same low or high speed, based on the settings of the mouse. BTW, I saw an open bug at Freedesktop --> https://bugs.freedesktop.org/show_bug.cgi?id=89485 I think that my issue seems to be the same as discussed at that bug. If so, is the acceleration of the mouse pointer still work in progress? Can it be completely disabled at some point in time?
I've had a play with the acceleration and I'm struggling a bit what you mean by "it's lagging a bit behind". I tried to take out the velocity averaging but at the speed I'm going here it doesn't make much of a difference. That was the only bit in the code that could've potentially lagged behind by one or two motion events. Do you mean it's just moving too slowly compared to what you expect from the mouse motion? that would mean the deceleration at low speeds is too strong (it's currently at 30% as minimum).
Last night (in my timezone) I have had a bit more time playing with the latest build you provdided. With "xinput list-props" I made sure that the "libinput Accel Speed" was 0.000000. This build (libinput-0.17.0-2.bz1227796.fc22.x86_64.rpm) is almost perfect imo. It's exactly what you just mentioned: the mouse pointer is moving too slowly compared to what I expect from the mouse motion at slow speeds. I noticed that when I'm for example hovering between buttons that are laid out next to each on a toolbar, the cursor is slightly slower compared to what you would expect. At this point this is the only (little) issue left imo. If this could be speeded up a little bit (to be more like moving with normal speed), this issue could be considered fixed.
Try this one here please: http://koji.fedoraproject.org/koji/taskinfo?taskID=9952979 (intentionally not explaining in detail to avoid confirmation bias)
Peter, thank you very much for this build. I did some serious testing with this build. I also did some extensive side by side comparisons with Fedora 21 (running on my laptop, a MacBook), of course with the same wired mouse (Microsoft Comfort Mouse 6000). This latest build you provided is clearly better than the previous one (I sure hope it is not some placebo effect :)). I would say the mouse behaviour is very good right now. The mouse is very responsive and smooth! However, to get the exact same behaviour as Fedora 21, I think it would take one more of that last improvement you made, again assuming it's not some placebo effect and if such an improvement is even possible. I would like to test that out also. Would it possible to test one last build before closing this bug as solved?
Package libinput-0.17.0-1.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.17.0-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9555/libinput-0.17.0-1.fc22 then log in and leave karma (feedback).
The build provided under comment 15 is better (mouse is more responsive, see comment 16) than the package 'libinput-0.17.0-1.fc22' which is in testing right now.
libinput-0.17.0-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
See comment 16 and comment 18, bug is not solved (yet).
(In reply to Kadir from comment #16) > This latest build you provided is clearly better than the previous one (I > sure hope it is not some placebo effect :)). heh, good. it wasn't a placebo, the acceleration function changed and was smoothed out. The patch has a crude ascii-art here: http://lists.freedesktop.org/archives/wayland-devel/2015-June/022509.html the first version of the patch simply capped at 0.3 so you'd have a mirrored L shape ("____/") at 0.3 rather than the function being tilted at a different incline to meet in the same spot. Hard to explain, but it doesn't matter anyway ;) > I would say the mouse behaviour is very good right now. The mouse is very > responsive and smooth! good to hear, that was my impression too, it was a lot easier to control at low speeds and much more predictable. > However, to get the exact same behaviour as Fedora 21, I think it would take > one more of that last improvement you made, again assuming it's not some > placebo effect and if such an improvement is even possible. I would like to > test that out also. > > Would it possible to test one last build before closing this bug as solved? yes, but I'm now out of ideas on what to change here. tbh I'm not aiming for a 100% exact behaviour as in F21 simply because it'll take the majority of users a couple of days to get used to subtle changes and then not think about it anymore. What I'm aiming for is "good behaviour" instead and I'm happy to tweak this until that's the case. But simple behaviour matching isn't the goal here. anyway, I'll take suggestions, or at least descriptions on what is still not quite right (right != exactly the same, remember? ;) your descriptive comments so far were really helpful to identify what needs to be improved, so please keep them up.
Thank you Peter for a very informative comment! You explained it very well. Your hard work is much appreciated. Now at this point the last build you gave is almost perfect. At medium and high speeds the mouse movement is perfect, there is nothing to do there. At low and super low speeds, there is some fine-tuning possible. I have tried looking for a test case to simulate really low speeds, because in daily usage these super slow movements do not happen frequently, at least not consciously but rather unconsciously. Or when you are doing some (e.g. graphics) work at pixel level. Now the thing is, for me it seems as if at super low speeds the mouse pointer onscreen is moving slower than my hand movements. It maybe sounds strange but, it is as if at really slow speeds moving the (physical) mouse is dragging the mouse pointer along. The best way I can maybe demonstrate this to you, is the following test. Take a random text, like for example; "Fedora is always free for anyone to use, modify, and distribute. It is built and used by people across the globe who work together as a community: the Fedora Project." and paste it in gedit (or some other text editor) and try selecting text. You should try selecting letter for letter and not word for word. And also don't look at the highlighted text (that is moving slower than the cursor), but strictly at the cursor and pay attention to your hand movements. To simulate super slow movements, there should be at least 0.5 seconds between selecting each letter. And try very slowly speeding up halfway trough the sentence, you will notice the cursor dragging / lagging (I hope). Now if I perform this test case, I quite easily notice that as I move the physical mouse with my hand it seems as if I am dragging or pulling (figuratively speaking) the mouse cursor (onscreen) along. To me perfect mouse behaviour is when the cursor is "glued" to the movements of the physical mouse and 1:1 with the movements of the hand of the user. In some cases (other OSes or distro's), the mouse movements (i.e. the acceleration curve) are set or can be set, too high. In that case the mouse cursor becomes jumpy, causing excessive strain on your hand/arm. Try it out, maybe you can notice the same behaviour.
Is there a way to configure or simply disable acceleration/deceleration? Every operating system allows the user to configure it because people prefer different settings and it may also depend on the mouse hardware. I've found out that libinput can be disabled (mouse only) via xorg.conf, and instead "evdev" can be used which allows the user to configure it in any way they like. But I guess that's not a proper long-term solution to stick with the old driver. :-)
(In reply to Andreas M. Kirchwitz from comment #23) > Is there a way to configure or simply disable acceleration/deceleration? > Every operating system allows the user to configure it because people prefer > different settings and it may also depend on the mouse hardware. OS X has a single slider from slow to fast. afaict, the "slow" setting puts some constant deceleration on it. so I guess with "every operating system" you meant "Windows"? we already accommodate for hw-differences by normalizing events, see http://wayland.freedesktop.org/libinput/doc/latest/motion_normalization.html
(In reply to Kadir from comment #22) > Now the thing is, for me it seems as if at super low speeds the mouse > pointer onscreen is moving slower than my hand movements. It maybe sounds > strange but, it is as if at really slow speeds moving the (physical) mouse > is dragging the mouse pointer along. [...] > Try it out, maybe you can notice the same behaviour. yes, that's adaptive deceleration, it's currently goes down to 30% of the actual motion. In that patch I linked to in comment 21 that's the first incline in the diagram before it levels out at 1. And that was so far the only bit that was modified in the packages up to now. It's there intentionally to make slow motions easier than requiring a fraction of a mm hand-movement. But as usual, better tweaking is always possible. Anyway, you're on :) http://koji.fedoraproject.org/koji/taskinfo?taskID=9997805 http://koji.fedoraproject.org/koji/taskinfo?taskID=9997815 http://koji.fedoraproject.org/koji/taskinfo?taskID=9997819 http://koji.fedoraproject.org/koji/taskinfo?taskID=9997823 http://koji.fedoraproject.org/koji/taskinfo?taskID=9997827 http://koji.fedoraproject.org/koji/taskinfo?taskID=9997828 let me know which one is closest to what you like. Everyone else is welcome to test too of course.
Thank you Peter for these builds, I did some heavy duty testing, it sure was hard with some of these builds! I used the following settings with all the six builds: xinput list-props 8 Device 'Microsoft Comfort Mouse 6000': libinput Accel Speed (265): 0.000000 Here are my results: libinput-0.17.0-2.1.fc22.x86_64.rpm --> low speeds a bit too slow --> alsmost good libinput-0.17.0-2.2.fc22.x86_64.rpm --> low speeds a bit too slow --> alsmost good libinput-0.17.0-2.3.fc22.x86_64.rpm --> low speeds still a bit too slow --> alsmost perfect libinput-0.17.0-2.4.fc22.x86_64.rpm --> Seems perfect! libinput-0.17.0-2.5.fc22.x86_64.rpm --> A bit slow from mid to high speeds --> no good, at higher settings, this becomes better libinput-0.17.0-2.6.fc22.x86_64.rpm --> Same as build 5 but even slower --> no good IMO build libinput-0.17.0-2.4.fc22.x86_64.rpm is just perfect! Like I described in comment 22, it seems as if with this build the mouse cursor is "glued" to my mouse movements. It moves slow when I want to and it moves fast when I want it to. I say this build is the best so far! and I perfectly happy if this build becomes the stable and default.
I tried them out too, and they're close but missing fine control. Here's a test you can do for fine control: open a photo in GIMP, set zoom to 100% (just press "1"), pick the rectangular selection tool, drag out a rectangle. Notice the width (or height) numbers in the status bar as you drag, they quite often jump in chunks of 2 to 4 pixels, 1 pixel accuracy is hard to do with some of the libinput variations. 2.1: Okay, but chunky 2 pixel resolution. 2.2: Zippy acceleration! Too fast. Also touchy when slow, but has the finest control of all, but not quite down to always moving 1 pixel. 2.3: Chunkier than 2.1 when slow. 2.4: Better in both slow and fast, still chunky (sometimes 1 pixel, sometimes 2 when moving sideways). 2.5: Chunky when slow, 2 pixels or worse. 2.6: Feels nicest, but chunky by 3 pixels.
(In reply to Alexander G. M. Smith from comment #27) Alexander, I tried your test with GIMP. I can regularly move sideways 1 pixel at a time. Of course it's hard, because moving per pixel strains your hand if your doing that alot. But I have no trouble moving the cursor per pixel. Maybe the chunky behaviour has to do with another setting, I really don't know :)
Alexander, I have been trying the GIMP test some more. With : xinput list-props 8 libinput Accel Speed (265): -0.250000 Moving sideways per pixel becomes much easier with libinput-0.17.0-2.4.fc22.x86_64.rpm Could you give this setting a try?
Still skips pixels. Nice to hear you had it working, so it's not a GIMP problem. Slightly better at the slower mouse speed. I even tried Accel Speed of -1.0, and it still skips pixels. I tried libinput varieties 2.2, 2.4 and 2.6 and they all had the skipped pixels problem at all tested speeds, 2.2 had it the least. By the way, my old mouse (an AOpen branded Logitech model M-BJ69) shows up without any DPI information in udevadm info, maybe your mouse's higher DPI hides the problem.
Alexander: did you run the mouse-dpi-tool yet? Without dpi-normalization it's hard to compare acceleration and if your mouse is old it's likely a 400 or 800dpi mouse and you really need an hwdb entry then.
Official libinput-0.17.0-1 seems to skip less pixels than previous versions but still hard to use for slow movements with Logitech MX518. How can acceleration/deceleration be configured by the user to match his needs?
Ran the mouse-dpi-tool, turns out it is 400 dpi and samples at 125hz. Oddly, "udevadm info /dev/input/event3" includes the 400@125 DPI setting and "udevadm info /dev/input/mouse0" does not (I had previously only seen the mouse0 one, not trying all the eventN ones until now). Which one is used? The event3 one does have an extra line that suspiciously says: E: LIBINPUT_DEVICE_GROUP=usb-0000:00:1d.0-1 Anyway, while moving the cursor with the mouse-dpi-tool active and GIMP in another window, I can see the mouse mickeys ticking in, and for every tick, the cursor moves, but sometimes moves 2 pixels!
the property is only set on the event devices, and libinput ignores mouseX devices anyway (they're the legacy ps2 emulation devices). so if it does show up for event3 that means it's set correctly and libinput should normalize. the device group tag is unrelated to this, see http://who-t.blogspot.com.au/2015/02/libinput-device-groups.html but either way, that low resolution is likely the source of why everything feels so different. we normalize the resolution to 1000 dpi but the side-effect of that is that the minimum delta your device produces is 2.5. and that must be what causes the pointer accel code to misbehave, or at least behave differently. I think that's something we have to address differently, though I don't quite know how yet. I guess getting a new 10 dollar mouse would make that problem go away for you :) (In reply to Kadir from comment #26) > libinput-0.17.0-2.1.fc22.x86_64.rpm --> low speeds a bit too slow --> > alsmost good > libinput-0.17.0-2.2.fc22.x86_64.rpm --> low speeds a bit too slow --> > alsmost good both expected > libinput-0.17.0-2.3.fc22.x86_64.rpm --> low speeds still a bit too slow --> > alsmost perfect > libinput-0.17.0-2.4.fc22.x86_64.rpm --> Seems perfect! very very confusing... > libinput-0.17.0-2.5.fc22.x86_64.rpm --> A bit slow from mid to high speeds > --> no good, at higher settings, this becomes better > libinput-0.17.0-2.6.fc22.x86_64.rpm --> Same as build 5 but even slower --> > no good both expected Right, so 1, 2, 5 and 6 were the experiments, I'd like you to test 3 and 4 again, especially at low speeds (they're the same at high speeds anyway). Confirm results or change your mind, I take either :)
Andreas: did you test any of the rpms I posted in comments 25? did you run the mouse-dpi-tool? we're still working on a solution.
(In reply to Peter Hutterer from comment #34) > we normalize the resolution to 1000 dpi but the side-effect > of that is that the minimum delta your device produces is 2.5. What happens if you cap the minimum acceleration (you said it was at 0.3) so a delta of 2.5 comes out at one screen pixel or some other even multiple? That would get rid of some of the skipping (a form of aliasing). Perhaps 0.25? Or antialias the mouse position (have fractional coordinates and draw it antialiased too). Admittedly, not going to happen :-) Or at slow enough speeds (delta 2.5 or less), switch to always moving one pixel per mickey? At those speeds (trying to do fine control), anything else is annoying to the user and scale factors aren't useful. Though that would cause problems if high DPI mice have noise in their outputs when they aren't being moved.
(In reply to Peter Hutterer from comment #34) Peter, I did some a/b testing with my brother (who is also a Fedora 22 user). We each did back and forth testing without knowing the build (2.3 or 2.4). We both came to the conclusion libinput-0.17.0-2.3.fc22.x86_64.rpm is better than libinput-0.17.0-2.4.fc22.x86_64.rpm So in our opionion libinput-0.17.0-2.3.fc22.x86_64.rpm is perfect! And no more tweaking is necessary.
(In reply to Alexander G. M. Smith from comment #36) > (In reply to Peter Hutterer from comment #34) > > we normalize the resolution to 1000 dpi but the side-effect > > of that is that the minimum delta your device produces is 2.5. > > What happens if you cap the minimum acceleration (you said it was at 0.3) so > a delta of 2.5 comes out at one screen pixel or some other even multiple? > That would get rid of some of the skipping (a form of aliasing). Perhaps > 0.25? The acceleration is a factor of the velocity, which is calculated based on the last event or couple of events. The min acceleration is only something you'd hit when you move really slowly, in the order of 1-2 events per second. But other than that, yes, I think we need to take the DPI into account to calculate the minimum movement, the current situation is clearly not it. Do you mind filing a separate bug for that now that we've identified that it's a different issue? (In reply to Kadir from comment #37) > (In reply to Peter Hutterer from comment #34) > > Peter, I did some a/b testing with my brother (who is also a Fedora 22 > user). We each did back and forth testing without knowing the build (2.3 or > 2.4). > > We both came to the conclusion libinput-0.17.0-2.3.fc22.x86_64.rpm is better > than libinput-0.17.0-2.4.fc22.x86_64.rpm thanks for the effort, much appreciated. so just to confirm: 3 is better than 4, that's a change from comment 26.
Created attachment 1037842 [details] accel-curves plot The curves for all the test packages. A value of 1 means no acceleration, the factor itself is applies as (dx/dy) * factor. 1 and 2 had a minimum acceleration value of 0.7 and 0.5, respectively, i.e. same behaviour as current stable, but faster. 3 had no deceleration, so on low speeds, the pointer would move exactly like the mouse did. 4 had a deceleration of 0.5 but flattened out quickly to 1 (no accel). 5 was the same as 3 but everything times 0.75, so slower overall. 6 was no pointer acceleration or deceleration at all. This graph shows the curves. 1-4 are identical with 1 where no separate lines are visible. 6 is just a horizontal line.
(In reply to Peter Hutterer from comment #38) > thanks for the effort, much appreciated. so just to confirm: 3 is better > than 4, that's a change from comment 26. You're welcome, it was fun doing some a/b testing :) Also thanks for explaining in detail about the accel curves and the builds! Yes indeed, build 3 (libinput-0.17.0-2.3.fc22.x86_64.rpm) is the best build overall and I'm very happy using it. Does this mean build 3 will become stable and the default? If so, this bug can be closed as solved :)
maybe. I need to tune the other settings around it, right now the speed slider has no effect on the new algorithm, at least not for low speeds.
If testing is needed, I am more than happy to do testing of more builds :)
what do you think of this one? http://koji.fedoraproject.org/koji/taskinfo?taskID=10185353
Peter, thank you for this build. It's a very good build! I have a hard time pointing out the difference between this build and libinput-0.17.0-2.3.fc22.x86_64.rpm. Is there a change between the (overall) speeds at medium and high? I say they are both good. I think I like this latest build a bit better :) I am very curious to see the difference in accel-curves. FYI, I also tested the build at #1231304 (libinput-0.17.0-5.2.bz1231304.fc22.x86_64.rpm). For me at least, the build you provided in this bug (libinput-0.17.0-2.7.fc22.x86_64.rpm) is clearly better than the one in that other bug (#1231304).
(In reply to Peter Hutterer from comment #43) I see you put the acceleration back, had to change the mouse settings slider to 1/4 of the way across (rather than the usual half way). Fine control is great, on my 400dpi mouse. libinput-0.17.0-5.2.bz1231304.fc22 is fine with me.
Alexander: note that the scratch build here is different to the one from bug 1231304. I don't expect this one here (libinput-0.17.0-2.7) to do much for your 400dpi mouse though. Kadir: the difference is at extremely low speeds. without deceleration, subpixel precision is impossible at low speeds. Look at the accel curves plot, it's like the original with the first incline being very steep. So anything resembling normal movement hits 1, only extremely slow movement is slowed down further. For normal movement, 2.3 and 2.7 are identical.
(In reply to Peter Hutterer from comment #46) > > Kadir: the difference is at extremely low speeds. without deceleration, > subpixel precision is impossible at low speeds. Look at the accel curves > plot, it's like the original with the first incline being very steep. So > anything resembling normal movement hits 1, only extremely slow movement is > slowed down further. > For normal movement, 2.3 and 2.7 are identical. Thanks for your explanation. Ok so, if I understand it correctly, 2.7 is like 2.3 only at the lowest speed is it under 1 instead of 1 like 2.3. Like I said I have a hard noticing the difference between 2.7 and 2.3. Either build is fine with me :) I just hope one of two will make into the stable build. Although I am very curious how the problem between ≥ 1000 dpi mouse and < 1000 dpi mouse, will be solved.
yeah, it's more like 2.4 except it flattens out quicker. either way, if you're happy with it that's a good sign. should have a solution for the dpi issue soon too. as always, thanks for testing
libinput-0.18.0-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libinput-0.18.0-4.fc22
Package libinput-0.18.0-4.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.18.0-4.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10863/libinput-0.18.0-4.fc22 then log in and leave karma (feedback).
libinput-0.18.0-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.