Bug 1415793

*** This bug has been marked as a duplicate of bug 1413306 ***

Repoening.  This bug is intentionally new because the problem exists even on the new builds that fix bug 1413306.  (Or at least I'm reasonably confident that it does.  Did something change between when I tested those builds and the final fix?)

Confirmed on libinput-1.6.0-1.fc25.

On libinput 1.5.0-1, with a moderate touchpad speed, I can move the cursor all the way across the screen in a single movement without any flicking by moving my finger about 3/4 of the way across the touchpad.

With 1.6.0-1, even at the fastest speed, I have to move my finger *fast* to get the cursor across the screen, and I find it basically impossible to be accurate at that speed.

Given that your blog post described the intent of the changes in 1.6 as increasing touchpad accuracy and reducing excessive accelartion, I wouldn't be surprised if this is just another normalization bug or similar.

I reopened the other bug so let's close this one again, more people on CC at the other one for testing.

*** This bug has been marked as a duplicate of bug 1413306 ***

Reopening, I'm going to use this bug for the non-hidpi related issues and leave bug 1413306 for hidpi only. sorry about the mess...

scratch build for testing:
https://koji.fedoraproject.org/koji/taskinfo?taskID=18007385

this is the first time that I'm actually quite happy with the touchpad acceleration. Default is slightly too fast on two of the laptops here, but the adjustment speed is quite huge now, so this should cover things well enough.
remember to give yourself at least 20 min to re-adjust muscle-memory.

Hi Peter,

1.5.0 - no manual intervention (aka increase acceleration from Plasma systemsettings). I can go from edge to edge by swiping about 75% of my touchpad. No jumping of cursor.

1.6.901 - without increasing acceleration it takes 2-3 full swipes across the touchpad to go from one edge of the screen to other. Setting acceleration alleviates some of the pain by reducing the swipes require but it starts feeling jumpy. I have no idea what would be the perfect acceleration and how to get touchpad to be as smooth as it was in 1.5.0.

If there was a way to provide some scientific input that would be best because we have gotten into personal taste territory.

I'm now running libinput-1.6.901-1.bz1415793.fc26.x86_64, and it seems like the acceleration is a little more predictable but the speed for gentle movements is still quite a bit too slow.   With the speed slider all the way at max, to move the cursor all the way across my screen, I have to move my finger very nearly all the way across the touchpad.  This might be reasonable behavior with the speed set to a lowish setting, but IMO it's poor behavior at the high end of the speed range.

I'll probably revert back to 1.5 soon because it was much more usable.

I haven't run it long enough to adapt to the new acceleration profile, but I think it still may be too aggressive.

Hi, is there any way to see the current libinput version number? (To make sure that I have it installed and it overwrote the previous install I have)

joe: for the libinput version run libinput-list-devices --version or, better, rpm -q libinput because that gives you the precise package number.

luto, sudhir: please point a camera at your screen and touchpad at the same time and record yourself doing a couple of slow, medium and fast movements. With the new accel please. Make sure the pointer is visible together with your finger(s), because I'm seriously wondering if we're looking at a bug or just completely different expectations on how a touchpad should behave.

Feel free to send me a link to the video directly if you don't want to make it public.

Hi Peter,

Here are the two videos one with 1.5 and libinput-1.6.901-1.bz1415793.fc26.x86_64

You can see that although 1.6 is usable but is slow. In real world I can't use touchpad to copy text because by I am not able to move on the screen with one swipe.

https://sudhirkhanger.portknox.net/s/WdhACUsdH1zYBuD
https://sudhirkhanger.portknox.net/s/mcBrPDav56ByGWL

Created attachment 1258407 [details]
screenshot of touchpad

>I'm seriously wondering if we're looking at a bug or just completely different expectations on how a touchpad should behave.

Yes, I would also like to know what we are aiming for with libinput. Do you expect to move the mouse from edge to edge with a single swipe? Do you think one should use multiple swipes to move across the screen?

You can also see in the 1.6 video that sometimes it doesn't pick up clicks.

My expectations is that my touchpad should work as it worked in 1.5 version where I can move my cursor from edge to edge using only 75% of my touchpad. If you look at the image attached you will notice that only use middle are of my touchpad and never complained about it because it just worked out of box.

I am running the latest version from koji you posted. If you need information let me know.

sudhir - I've been trying to download this for the last 2 hours and it fails after a few seconds. In chrome I'm up to 2 seconds of streaming video now, any wget/direct download fails. Can you put those up somewhere more reliably please? Thanks.

(In reply to Sudhir Khanger from comment #12)
> Yes, I would also like to know what we are aiming for with libinput. Do you
> expect to move the mouse from edge to edge with a single swipe? Do you think
> one should use multiple swipes to move across the screen?

my expectation for pointer movement is:
* 'normal' speed movements should match the on-screen pointer movements, though I found that a slight slowdown enhances precision, i.e. 5cm of touchpad movement result in maybe 4cm of on-screen movement. That feels most comfortable
* 'fast' movements should accelerate, so that a movement from e.g. one icon in nautilus to the one two rows down and five over should be a flick of the finger
* crossing the screen from the bottom left corner to the top right to show the overview should not take more than 1.5 swipes, i.e. I might not always get there with the first swipe but definitely with the second.

Here's a 20 sec video for how it looks like on my laptop:
https://people.freedesktop.org/~whot/touchpad.mp4


> You can also see in the 1.6 video that sometimes it doesn't pick up clicks.

please file a separate bug for that, but it could be related to https://bugs.freedesktop.org/show_bug.cgi?id=99976
 
> My expectations is that my touchpad should work as it worked in 1.5 version
> where I can move my cursor from edge to edge using only 75% of my touchpad.

fwiw, in the 1.5 version the acceleration basically had a constant factor of 2 for most movements, the 1.6.x version goes a lot higher but it doesn't apply as quickly. So while fast movements are faster, you have normal movements slower. That's particularly an issue on high-dpi screens but apparently a mismatch of expectations on normal screens too.

Hi Peter,

Sorry about the links. They came out to be a bit too big. I have uploaded them to YouTube and should work now.

https://youtu.be/nBTc31C722s
https://youtu.be/jopj8LAgRyY

Feel free to download them as I might remove them later.

Based on those expectations I would say 1.6 works quite well.

1.5 was much faster as in 0.75 swipe will cover the whole screen. If you are copying text which spans from top to bottom and if it requires more than 1 swipe then you get in trouble. If you remove your finger then you lose the selection marker or you will have to try a couple of fast movement to be able to cover the whole screen.

Thanks for the videos, I looked at them and I think we definitely have a mismatch in expectations. The difference in the 1.5 vs 1.6 behaviour looks like it's exactly what the new acceleration code was supposed to address. Look at the graphs in https://who-t.blogspot.com.au/2016/12/libinput-touchpad-pointer-acceleration.html to get an idea of the changes.

but basically, the summary is that to implement your preferred behaviour would mean reverting the previous changes (which judging by bugreports was quite hated). It was prone to overshoot, amongst other issues.

(In reply to Sudhir Khanger from comment #14)
> 1.5 was much faster as in 0.75 swipe will cover the whole screen. If you are
> copying text which spans from top to bottom and if it requires more than 1
> swipe then you get in trouble. If you remove your finger then you lose the
> selection marker or you will have to try a couple of fast movement to be
> able to cover the whole screen.

There are two immediate solutions here: you can hold the button down with e.g. the thumb and keep resetting the finger as required. That's what I do here. Or, if you're a fan of tapping, you can enable the tap drag lock which allows you to lift the finger, see the illustrations here:
https://wayland.freedesktop.org/libinput/doc/latest/tapping.html

I wonder if what's going on is that the GNOME "touchpad speed" control has a highly suboptimal effect.  Unless I'm guessing wrong, it calls "libinput_device_config_accel_set_speed", which in turn gets here:

	/* Note: the numbers below are nothing but trial-and-error magic,
	   don't read more into them other than "they mostly worked ok" */

	/* adjust when accel kicks in */

I don't think this does what users (e.g. me) expect.  When I change the speed, I'm not trying to tell the desktop that I want to tweak how the nonlinear response of the touchpad behaves -- you've put considerable effort into tuning the nonlinear response, and I think you've done a good job.  I'm just trying to say "go faster".  By "go faster", I don't mean "accelerate faster"; I literally mean "go faster".

Perhaps the behavior should be that the speed is converted to an actual scale factor [1] and then to use that scale factor to either rescale the input (physical movement) or the output.

As an argument for rescaling the input: this would cause a speed change to just change the sensitivity of the pad or equivalently to rescale my finger motions.  Seems reasonable.

As an argument for rescaling the output: this would be like saying that I have the same physical concept of "slow", "medium", "flick", etc. as everyone else but that I just want the pointer to cover more distance.

[1] 1 + 0.5 * speed_adjustment, perhaps, but maybe something that turns -1 into something more like 0.1 and +1 into something a bit bigger than 2 is the way to go.

(In reply to Andy Lutomirski from comment #16)
> I wonder if what's going on is that the GNOME "touchpad speed" control has a
> highly suboptimal effect.  Unless I'm guessing wrong, it calls
> "libinput_device_config_accel_set_speed", which in turn gets here:
> 
> 	/* Note: the numbers below are nothing but trial-and-error magic,
> 	   don't read more into them other than "they mostly worked ok" */
> 
> 	/* adjust when accel kicks in */
> 
> I don't think this does what users (e.g. me) expect.  When I change the
> speed, I'm not trying to tell the desktop that I want to tweak how the
> nonlinear response of the touchpad behaves -- you've put considerable effort
> into tuning the nonlinear response, and I think you've done a good job.  I'm
> just trying to say "go faster".  By "go faster", I don't mean "accelerate
> faster"; I literally mean "go faster".

Right. There are three effects libinput provides, base 'speed',
'acceleration' and 'threshold'. The base speed is obvious, acceleration is
effectively the incline of the linear function and threshold is when we
start acceleration. The attachment below has an illustration of the various
curves. also look at this paper here for some analysis of what windows and
macos did, and what the xorg does without libinput:
http://www.lifl.fr/~casiez/publications/UIST2011-NoMoreBricolage.pdf

Note that a higher speed would (imo) also apply higher acceleration, i.e. a
steeper incline, since a high speed implies quicker cursor movements and
faster responsiveness (mostly guesswork, but backed up by the bricolage
paper's graphs). The historical X behaviour as defined in the protocol is to
just specify a multiplier for mickeys (and a treshold) but unless my maths
is out this also implies a steeper acceleration curve at higher settings.

libinput doesn't expose the threshold as separate item but is is quite
conservative on the threshold range - its range is actually comparatively
narrow and even when you have the max speed set, it doesn't immediately
accelerate.

also note that the -1 to 1 value range is just normalization (slowest to
fastest), we can adjust those internally at will. In hindsight it should've
been just 0-1 but that ship has sailed.

> Perhaps the behavior should be that the speed is converted to an actual
> scale factor [1] and then to use that scale factor to either rescale the
> input (physical movement) or the output.

> As an argument for rescaling the input: this would cause a speed change to
> just change the sensitivity of the pad or equivalently to rescale my finger
> motions.  Seems reasonable.
> 
> As an argument for rescaling the output: this would be like saying that I
> have the same physical concept of "slow", "medium", "flick", etc. as
> everyone else but that I just want the pointer to cover more distance.

I'm not sure I fully understand your suggestion here, can you rephrase them?

Created attachment 1260265 [details]
illustration of the proposed acceleration curves

This is an illustration of the new proposed acceleration curves at various speed settings, compared to the current acceleration at the default 0.0 speed. Note how base speed, incline and threshold all change as the speed setting is changed.

Nice paper!  In their language, I was suggesting that the "speed" slider should either rescale the X axis (input) or Y gain axis (which is the same thing as rescaling the output).

Does your illustration mean you're proposing changing something from the way it works in 1.6?  The illustration looks reasonable to me.

yeah, look at the 'current' label(In reply to Andy Lutomirski from comment #19)
> Nice paper!  In their language, I was suggesting that the "speed" slider
> should either rescale the X axis (input) or Y gain axis (which is the same
> thing as rescaling the output).

that's mostly what I'm doing, but apparently not aggressive enough. see the various curves in the svg, they represent the various scaling patterns. Amongst other things it scales the base speed to something I considered almost unusably fast on my touchpad here.
 
> Does your illustration mean you're proposing changing something from the way
> it works in 1.6?  The illustration looks reasonable to me.

yeah. the 'current' curve is 1.6.x, the other lines are the ones proposed here. I don't have the comparative values for the 1.6.x in this graph but compare the 0.0 graph to the 'current' one, they're for equivalent speed settings. the base speed is slightly slower but it accelerates sooner and stops accelerating at a lower maximum speed. That's the one that has a really good response rate on the T440. I'll play around with it a bit more to increase the spread of the acceleration so the base speed gets faster at max accel. That should make everyone happy (haha. hahaha. ;)

Hmm, so 1.6.x has a large slope in the gain everywhere?  Maybe that's why I have such bad accuracy problems with it.  I would imagine that I'm fairly good at repeatably moving my finger 2cm but I'm much worse at repeatably doing it at the same speed.  With the new proposed curves, as long as I keep the speed within a decently wide range, I'll get roughly the same motion.  (Assuming I'm understanding your plot correctly.)

Fingers crossed :)

Created attachment 1262312 [details]
illustration of 1.6 vs proposed curves

same graph but this time for better comparison between old and new. The old accel method didn't really max out which is the likely cause of the overshoots. It kicked in soon at high speeds which made prediction a bit harder. The new one is a lot more predictable (I think), for some speeds it will actually accelerate sooner but the slope is a lot more gentle. Note that anything beyond 400mm/s is flicking speed, so only the left half really matters here.

I think the only requirement now is to lift the baseline so that the base speed at max accel is closer to e.g. 1.0  and fans out evenly down to almost 0. Need to think about how to do the calculation here while still keeping things linear (and whether linearity even matters here, I honestly don't know).

I'm wondering if the gain should be flatter at the speeds where it's likely to be used.  That way, if I try to move the cursor at a normal speed (I'm assuming that 200-400 mm/s or so is "normal") then the distance moved would be more or less proportional to the actual distance I move my finger without depending too much on how fast I move my finger over that distance.  IOW, maybe the gain should increase rapidly starting above 400 mm/s to some higher gain value and then settle at that higher value to support efficient flicks.

200mms is already relatively fast and the top end of where movement has to be accurate and unaccelerated. 'normal' movement would be in the 50-200 range. And I found that the graphs are helpful comparing algorithms but not necessarily at *designing* them, a good-looking line can feel absolutely terrible when used.

One of the issues I found with any two-step acceleration is that it's hard to predict where it kicks in because the actual speed changes all the time. But you're right, something like that could work because it clearly did for the xorg acceleration where the increase was relatively fast but topped out soon.

fwiw, the tree for this is here:
https://github.com/whot/libinput/tree/wip/touchpad-pointer-accel-v4

it'd be easy enough to install and play around with various toggles to find something that works best for you. Just pushed another version there (1799d00)  that has a wider range and could work.

Any update on this guys? I installed Ubuntu Gnome 17.04 just to get Gnome 3.24.1 to get the https://bugzilla.gnome.org/show_bug.cgi?id=778119 fixed. Even now, under Wayland, my trackpad is erratic. Under X, with the Synaptics driver, it works perfectly.

I need to use Wayland for multi DPI monitor setups and this trackpad issue is just not letting me use it.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Andy, Sudhir, in case you're still paying attention to this bug: do you still find this an issue with recent versions (e.g. 1.10) of libinput? Reason being that I have other bugs complaining that it's too fast now and I want to make sure we don't have 3 people pulling in 5 different directions.

Ref: https://bugs.freedesktop.org/show_bug.cgi?id=101139

Hi Peter,

According to me, it is perfect. It's been working as per my expectation. Fast move and slow move are both excellent as far as my experience goes.

I'm quite happy with the libinput-1.10.2-4.fc27 behavior.

Thanks for the update, much appreciated.

Andy, Sudhir: can I get you both to try the branch in  https://bugs.freedesktop.org/show_bug.cgi?id=101139

https://github.com/whot/libinput/tree/wip/touchpad-pointer-accel-v6

Just so I know ahead of time how many ppl I'll upset with that one :) 
Thanks

Hi Peter,

Are there rpms/copr that I could quickly use to test on my side? I don't have experience with building.

Regards.

I'm hoping neither of you is on F25 or F26 :)

F27 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=26741576
F28 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=26741606

I feel like slow is a bit slow but otherwise is working fine. I will report in a day or two again once I have used to thoroughly.

fwiw, the *default* setting was changed to be a bit slower, but you can change the speed with the libinput Accel Speed property or by using the GNOME toggles.
I'm under no illusion that the default speed works for everyone, but as long as they can find a reasonable setting that's good enough.