With the libinput 1.6-rc from updates-testing (libinput-1.5.901-1.fc25) I see the same problem as MatMaul mentions in the comments on https://who-t.blogspot.de/2016/12/libinput-touchpad-pointer-acceleration.html "The max speed too slow for me. While it was ok before with the gnome setting at around 80%, I am now struggling even at 100%." Downgrading fixes the issue for me. Fedora Workstation 25 and Gnome is running in Wayland mode Device is a Dell XPS13 DE (9360) (adamw has a similar one and might be able to confirm). Dmesg says "[ 1.851321] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2a1, caps: 0xf00323/0x840300/0x12e800/0x0, board id: 3038, fw id: 2375007"
DMI: Dell Inc. XPS 13 9343/0310JH, BIOS A09 08/29/2016 I also had to downgrade because the acceleration is way too slow, to the point of being unusable on the 3200x1800 screen with KDE
(In reply to darrell pfeifer from comment #1) > XPS 13 9343 Also an XPS 13? Hmmm. > of being unusable on the 3200x1800 screen with KDE TWIMC: Mine has a FHD display (1920x1080)
TMIMC: Upstream bug afaics: https://bugzilla.freedesktop.org/show_bug.cgi?id=99383
darrell: a slow pointer on a 3200 screen is somewhat expected if it's a high-dpi screen and nothing scales up accordingly. that needs to be fixed in GNOME. Thorsten's issue is probably different, because tbh I can't even control the pointer at 100% of the speed because it's so freaking fast. Does the touchpad-edge-detector agree with the kernel values? Same issue in X?
I am using KDE (not gnome) The pointer speed has been fine for at least the last year. It is only libinput-1.5.901-1.fc25 that makes the pointer speed unusable. Reverting to the previous version gives a very usable result.
(In reply to Peter Hutterer from comment #4) > Does the touchpad-edge-detector agree with the kernel values? Yup > Same issue in X? Yup
(In reply to darrell pfeifer from comment #5) > I am using KDE (not gnome) The pointer speed has been fine for at least the > last year. It is only libinput-1.5.901-1.fc25 that makes the pointer speed > unusable. Reverting to the previous version gives a very usable result. tbh, I'm not sure KDE does proper scaling for hidpi either. Can either of you verify the behaviour of the pointer on a normal-dpi screen? is it acceptable there? when you switch to synaptics, what acceleration do you need there? Please evemu-record a touch sequence where you do the following: * start nautilus (or it's kde equivalent), select a folder with a number of items * move the pointer onto a folder/file icon * start evemu-record for the touchpad * move to the icon right+down (i.e. next row, next column) in one finger movement * stop evemu-record This should be a ca 5cm movement on the screen, I can replay that here to hopefully figure out what else is going on. Both of you, please.
Created attachment 1241941 [details] evemu-record in nautilus (In reply to Peter Hutterer from comment #7) > Can either of you verify the behaviour of the pointer on a normal-dpi screen? I might have a chance to do that tomorrow. > when you switch to synaptics, what acceleration do you need there? Quickly tried, but failed: seemed to me the acceleration setting in Gnome had no effect; is looked like gnome (running in X11 mode) even didn't properly detect that it was using a touchpad. Maybe I did something wrong (yes, I uninstalled xorg-x11-drv-libinput and installed xorg-x11-drv-synaptics and there were synapitcs msgs in the log) due to time constrains. > Please evemu-record a touch sequence where you do the following: > […] > This should be a ca 5cm movement on the screen, I can replay that here to > hopefully figure out what else is going on. Attached
sorry, should've mentioned that before: synaptics isn't handled by GNOME anymore, so you'd have to change the acceleration settings with either xinput or synclient.
*** Bug 1414169 has been marked as a duplicate of this bug. ***
ok, reproduced this here on a RMI4 device (T450p). works fine on PS/2, terrible on RMI4. I suspect this may be the resolution difference, but I'm not sure yet. Upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=99383
I am having simular issues on my XPS 13 with hidpi. Using gdm as display manager, works fine in gnome (with wayland) but not usable (before downgrade of libinput) in i3 (my default window manager). I also did not find a way to adjust it in i3 yet.
scratch build with the patch I attached to the upstream bug: https://koji.fedoraproject.org/koji/taskinfo?taskID=17320483
(In reply to Peter Hutterer from comment #13) > scratch build with the patch I attached to the upstream bug: > https://koji.fedoraproject.org/koji/taskinfo?taskID=17320483 Works fine here and fixes the problem for me; many thx for digging into this!
That build is certainly much better. That being said, I feel like the degree of nonlinearity is too aggressive. At all but the fastest speed settings (in GNOME), gentle relaxed finger movements don't seem to move the cursor far enough, whereas fast finger movements move the cursor so fast that it generally just rams into the corner of the screen for me. I find that muscle memory for how far to move my index finger seems to work fairly well on a touchpad, and I thought that the 1.5 behavior was fantastic in this regard (much, much better than Windows, for example). 1.6 seems like a bit of a step backwards.
Concretely, on a large-ish touchpad (which I have on the XPS13 9350), at my preferred speed setting on 1.5, I can move the pointer all the way across the screen just by reaching my index finger farther and swiping at any speed. Conversely, with small movements, I can easily move one pixel at a time. On the 1.6 builds, to move even from the "status" dropdown in bugzilla to the "Save Changes" button (maybe 1/4 of the way across the screen), I have to stretch a little bit or move my finger quickly. If I move my finger quickly, I ted to overshoot. I understand the purpose of acceleration for mice and for *small* touchpads, but it seems counterproductive on large touchpads, at least when it's as aggressive as it is in 1.6. Hmm. I wonder if it would make any sense to to consider making the nonlinearity be a function of swipe *distance* instead of speed. Maybe that would have its own set of problems, though.
I have a similar issue-- with the latest libinput update on F25 my mouse speed is way faster than it should be. Using Peter Hutterer's scratch build from the link above (https://koji.fedoraproject.org/koji/taskinfo?taskID=17320483) fixes the issue for me. Thanks
*** Bug 1414637 has been marked as a duplicate of this bug. ***
I am not on HiDPI display. I am on 1920x1080p display and libinput-1.5.901-1.fc25.x86_64 renders my system unusable. I am Dell Precision 5510 with Plasma Desktop.
libinput-1.6.0-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a7d615e6f6
I have pointer motion acceleration set to nearly maximum on KDE and still find it slightly slow when doing a large movement across the screen. Still, it is at least reasonable and usable.
libinput-1.6.0-1.fc25 fixes the problem for me. I've submitted positive karma on it. Others should try it out and do the same so it will get pushed to stable asap. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a7d615e6f6
Still broken for me. All I can say is anything beyond 1.5 is causing weird behavior. It is still slow on 1.6. It's not only slow but when I stop to click the first click is no longer registered. I have to what seems like wait for a second and then click again. Downgrading to 1.5 and blocking all future libinput updates until the broken code is removed.
libinput-1.6.0-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-a7d615e6f6
libinput-1.6.0-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Sudhir: you'll need to file a new bug for the clicking issue, it won't get addressed if it's hidden somewhere in the comments
The speed issue is still broken here, with the touchpad of my Dell XPS 13 9360 (Kaby Lake, with HiDPI screen). It's still too slow even at max. It is definitely improved over the previous 1.6 build, but it's *still* too slow. It's really sad that this is a regression, as libinput 1.5.x was pretty much *perfect* on the laptop. With libinput 1.6.x, this bug (and *especially* the ignore-half-the-tap-clicks bug #1414935) made my laptop with Fedora 25 go from a dream to use to a nightmare (unless I plug in a mouse, which mostly defeats the purpose of getting a 13" laptop with a great touchpad). Are there plans to fix the speed some more in a new build?
I agree with Garrett. 1.5.1 was pretty much perfect out of box for me. Now I have to figure out why is it broken. Figure out the perfect acceleration which I don't seem to get. It's either too slow or jumpy. Not to mention the clicks are not being registered. Why do we have to break working systems? It's such a waste of time. I dread upgrading because everytime you upgrade 5 things will be broken. So much waste of my work hours. This bug should be reopened.
*** Bug 1415793 has been marked as a duplicate of this bug. ***
(In reply to Sudhir Khanger from comment #28) > Why do we have to break working systems? you're not the only user of libinput. it was very bad for a lot of users, bad enough that an update of the stable release was considered worthwhile.
FWIW, multiple people stopped me at DevConf this week to complain about this issue - seems like quite a lot of people have XPS 13s and are affected. Actually I have one too, I'm holding off on installing updates for now!
Unlike the title the last working version of libinput for me is libinput-1.5.0-1.fc25.x86_64. After 1.5.0 the touchpad becomes too unstable to be useful. I am on Dell Precision 5510 1920x1080p display (hardware is almost same as XPS 15 model). These are one of the only systems which are of very high quality and comes with Linux (Ubuntu LTS) pre-installed.
Ah, sorry, I was trying to summarize from all the reports. Will adjust.
I think I reproduced this on a Wacom Intuos 5 with a resolution of 18x29,compared to a 41x37 resolution on the T440 ps/2 touchpad. The wacom feels slower, though admittedly it's not 100% clear to me whether that's caused by the different surface. The t440 surface is a lot smoother than the Wacom. And of course it's impossible to reproduce exactly the same finger motion on two different touchpads... The bug appears to be identical in xorg and wayland, so I think we can rule out an xserver or xorg-x11-drv-libinput bug. I went through the acceleration code and I can't find where the issue is. It certainly *feels* like a normalization bug, but doing the numbers on paper shows the correct result. A physical X/Y movement results in the same normalized deltas, regardless of the device resolution. At this point I'm assuming that everything in the pointer acceleration code itself is mathematically correct. The input coordinates into the touchpad accel filter accelerator_filter_post_normalized() are correct when I print them out, the physical movements add up correctly. Measured this by moving my finger along a ruler. Also, for comparison, an RMI4 enabled touchpad on a T450p feels the same as the T440s on PS/2, despite having half the resolution and being different hardware. The only thing I noticed so far is that the speed calculated seems to be consistently lower on the Wacom than on the T440. That's of course hard to measure because, it's hard to use the same speed on every motion. But it's consistent enough that I think this is a true result. So that leaves us... in an odd place. The *distance* of the input data is correct but the *speed* is incorrect? The speed calculation is a simple hypot()/time, so this must happen before we even get to the accel code. And the only place this could happen is the touchpad hysteresis. So I disabled that and that really seems to change the speed issue. A koji scratch build for testing is below. At this point I don't quite understand *why* this changes things, but I'd welcome any test results regardless. Thanks. https://koji.fedoraproject.org/koji/taskinfo?taskID=17517750 There's another issue that I noticed observing myself. The size/surface (?) of the touchpad seems to affect how much I move my finger. On the T440s I seem to be more willing to move larger distances with my finger than on the Wacom tablet. If true, this would make things a lot more complicated, but I don't know what to think of this yet....
So I tried this out on a Thinkpad T520 (pretty old model with a physically small trackpad), an X1 Carbon first-generation (trackpad nearly as large as the XPS 13, 1600x900 display) and my XPS 13 (9360, 4K display, physically large trackpad). The 'Touchpad Speed' setting was in the middle of the bar for all three. Observations: 1. On all systems, libinput 1.5.3 basically behaves as you described in your blog post before changing this stuff: there's barely an acceleration curve at all. The pointer moves quite a long way for almost any finger movement above an extremely fine repositioning, but . I think this is the behaviour people have gotten used to, though - I certainly have. 2. The way I'd characterize 1.6.0's behaviour on the XPS 13 is that if you actually get the acceleration to kick in, it's quite responsive - if you move your finger a long way at a reasonable speed, that is. But you do have to move your finger really quite a long physical distance before acceleration kicks in at all. It's like maybe 1/3 of the size of the pad, but the pad is *big*. The kinds of movements I'm used to doing for travelling moderate distances on the screen - say, from this comment box to the URL bar in Firefox - do not trigger the acceleration at all, and the pointer just does not move very far at all. When the acceleration doesn't kick in, the pointer moves much, much 'slower' (i.e. moves less far for the same physical finger movement compared to 1.5.3). 3. The nohyst build does not, so far as I can tell, change behaviour at all noticeably on the XPS 13. 4. On the T520, with 1.6.0, you can tell the fundamental behaviour is the same - more of an acceleration curve. But it seems 'calibrated' better; it kicks in far more often. Moving your finger by much smaller physical distances triggers the acceleration curve; almost any movement beyond a fine reposition will trigger at least some acceleration, which makes the experience feel much better. 5. On the X1 Carbon, it is *definitely* the case that the pointer is much 'faster' before acceleration kicks in. It feels almost as fast as 1.5.3. It's a bit hard to tell whether acceleration kicks in more easily, just because the basic movement speed is already pretty fast, but it may do. It's a massively noticeable difference, it's not subtle at all; on the XPS 13 5. The top end of the acceleration curve on the XPS 13 seems really high. So if you try to compensate for the behaviour by using much more 'emphatic' finger movements (moving your finger a bit further, a lot faster) for relatively small cursor movements, your cursor winds up just flying to the edge of the screen quite easily. If you really concentrate you can move from, say, 2/3rd of the way down the screen to somewhere close to the URL bar with one finger movement, but it's *really* difficult: usually you wind up either right at the top of the screen, or only getting 1/3 or 1/2 of the way there. Basically I feel like the fundamental problem is that, on the XPS 13, pointer movement before acceleration kicks in is far too slow, you need too much finger movement before the acceleration curve kicks in at all, and (but this is less important) once it does kick in, it seems to ramp up a bit too fast. Tim Flink (owner of the X1 Carbon) has basically the same observations as me, and we recorded a side-by-side demo; I'll upload that.
Created attachment 1246609 [details] video of us testing libinput 1.6.0 on XPS 13 (9360 4K) and X1 Carbon (1st gen 1600x900) Recorded with the nohyst build on the XPS 13, regular 1.6.0 on the X1. As noted above, I didn't see any difference between nohyst and 1.6.0 on the XPS 13 anyway. This is quite heavily compressed to fit in BZ's size limit, I have higher quality versions I can make available if you can't make out enough detail from this.
after some analysis on the pointer events between adam's x1 and the dell I'm back to strongly suspecting HiDPI issues. For this bug, if you *DO NOT HAVE HIDPI*, please move over to Bug 1415793. Because there seem to be two different problems, one related to hidpi and one related to how the accel curve is shaped and mixing the two up leads to no results. Please do not comment here, this bug is messy enough as it is. If you *DO HAVE HIDPI*, please install the scratch build below: https://koji.fedoraproject.org/koji/taskinfo?taskID=17546245 once installed, look at /usr/lib/hwdb.d/90-libinput-model-quirks.hwdb for instructions (bottom of the file). Basically what you need to do is figure out an approximate scale factor compared to my laptop here. Or, ideally, compared to some non-hidpi laptop you have available. Apply that and check the pointer movement, if it is mostly sane after that, then we have the source of the issue. If you have two laptops, the hidpi one should feel the same as the non-hidpi one after applying the scale factor.
This bug has been approved as Prioritized bug as the popularity of xps 13 models means that this issue will affect a significant portion of Fedora's user base. https://meetbot.fedoraproject.org/fedora-meeting/2017-02-08/fedora_prioritized_bugs_and_issues.2017-02-08-15.01.log.html
Tim, I think you said you were trying the scratch build yesterday?
Note: the correct file with the instructions is /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb .
I installed the updated libinput and set the scale to 1.767 (which should be correct for 3200x1800 13.3", the XPS 13 hidpi screen). Seems to do the job.
Any update to this bug? I'm on Fedora 25 on Wayland. If this bug fix will take time, how can i revert back to the Synaptics driver? I have a Dell XPS 13(9350) machine and have migrated to Fedora 25 from Ubuntu 16.04 LTS because of Wayland support for multi-DPI monitors(HiDPI monitor needs to work well with my external FullHD monitor). Is it possible to switch back to the Synaptics driver if I'm using Wayland?
If it isn't possible to switch to the Synaptics driver under Wayland, what is the version I should downgrade the driver to get a better experience?
Kanishk for me 1.5.0 was the last working libinput version and that's what I have rolled back to and excluded all future libinput updates. I had to `dnf downgrade libinput` twice to get to the 1.5.0 version.
Thanks for your reply Sudhir. After downgrading it once, now I am on: 1.5.0-1.fc25 It does feel a little better, compared to 1.6.0.2. Any idea on whether I can use the Synaptics driver in Wayland on Fedora? I was using the Synaptics driver in Ubuntu and I felt it worked better than even the 1.5.0 libinput one here in Fedora.
The status is we're waiting for *you*! Peter posted a scratch build with extensive instructions in #c38, and no-one answered. This is a two-way process, folks.
I should have done it weeks ago but I just tried to install the scratch build from c#38 and it looks like they've been cleaned from koji. Assuming that feedback is still desired, could we get another scratch build to test?
I'm also willing to test it out and give feedback. We're still stuck on 1.6.0.2 and I've to make sure that I don't upgrade my mistake to a newer version of libinput. How can we take this forward?
The hidpi variant of this should be fixed in current GNOME master: https://bugzilla.gnome.org/show_bug.cgi?id=778119 It's not backported to Fedora yet, though, currently.
unfortunately, that only works for wayland, X support is still missing. But yeah, too many things to do, I can't do all of them and it simply hasn't gotten any attention, sorry.
xorg-x11-drv-libinput-0.25.1-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-460dd3ca0a
xorg-x11-drv-libinput-0.23.0-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ab09ad63d3
Long story short, I still don't know how to fix this for X. I have received little to no testing feedback, so I'm still in the dark here but let's just assume multiplying things is not the worst of all ideas. So I've pushed a ***TEMPORARY*** solution to f25 and f26 to at least make the behaviour less awful in X. There is a new option DPIScaleFactor available in xorg-x11-drv-libinput that simply multiplies motion events by that factor (not scroll events). Similar to the scratch build above. This option is temporary workaround and may be removed at any time once we figure out how to solve this in X. It can be applied with the following xorg.conf snippet: $ cat /etc/X11/xorg.conf.d/99-dpi-scale-factor.conf Section "InputClass" Identifier "Adjust the scale factor for pointer events (TEMPORARY HACK)" MatchIsTouchpad "on" MatchDriver "libinput" Option "DPIScaleFactor" "2.0" # ratio your dpi : 96dpi EndSection As you can guess by the name, this is intended to fix the hidpi situation, not any other pointer acceleration issues you may have. Again, this is a hack, a temporary workaround, and will produce a warning to that extent in your xorg.log. It may be removed in the future, but meanwhile it makes life a little less awful.
xorg-x11-drv-libinput-0.25.1-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-460dd3ca0a
xorg-x11-drv-libinput-0.23.0-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ab09ad63d3
xorg-x11-drv-libinput-0.23.0-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
xorg-x11-drv-libinput-0.25.1-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
This update has been in a stable for a month. If anyone is still experiencing this problem with these specific laptops, please reopen. If you're experiencing a similar problem which might have a different cause, please file a new bug.