Bug 90735

fwiw, there's a patch on the list that significantly improves slow mouse behaviour now. and 0.17 already had some other fixes to accommodate for ultra-slow mouse motion.
http://lists.freedesktop.org/archives/wayland-devel/2015-June/022509.html

So far that only affects slow motions, I haven't looked at faster motions yet.


One question though: do you notice a difference between touchpad and mouse? or do they suffer from the same issues?

I do notice a difference between the touchpad and mouse, yes. The issue is extremely noticeable with the touchpad, in which acceleration and precision is crucial. With a mouse, I find myself overshooting and undershooting in much the same way, but I am able to compensate for it a bit better.

That being said, in neither circumstance to I feel comfortable with the cursor as it stands now. I have not tried libinput 0.17 yet, though.

btw, what touchpad do you use? can you attach an evemu-recording of it please?

I have a synaptics touchpad. The one in the Dell XPS 13 9333.

I am testing the libinput 0.17 with the low velocity patch, and I think it is an improvement. That being said, it still feels a bit off. If I get the acceleration right for medium speed cursor movements, a quick movement sends me flying over my target. And if I set it right for quick movements, medium speed movements cause me to undershoot. Slow cursor speeds seem to be ok now though.

I am not sure how to do a evemu-recording, you might need to specify a bit more how to do it.

Lastly, what is the rationale against having separate settings for both acceleration and velocity, and rather this dynamically changing acceleration?

evemu is simply sudo evemu-record /dev/input/eventX, with your device. Starting it without arguments will produce a list of devices.

(In reply to Britt Yazel from comment #4)
> I have a synaptics touchpad. The one in the Dell XPS 13 9333.

right, that's one with resolution. good enough then.
fwiw, some touchpads provide physical resolutions, others don't. we're generally better on the ones that do because we can deal with physical movements over guesstimates based on device units.
 
> I am testing the libinput 0.17 with the low velocity patch, and I think it
> is an improvement. That being said, it still feels a bit off. If I get the
> acceleration right for medium speed cursor movements, a quick movement sends
> me flying over my target. And if I set it right for quick movements, medium
> speed movements cause me to undershoot. Slow cursor speeds seem to be ok now
> though.

right, I agree on the quick movement being off, especially on touchpads. looking into this already, but don't have anything to show yet. we currently use the same pointer acceleration function for touchpads and mice, but I think the profile of the functions needs to be different.

> Lastly, what is the rationale against having separate settings for both
> acceleration and velocity, and rather this dynamically changing acceleration?

reluctance to expose too many knobs for user configuration. Every knob added multiplies the testing and maintenance effort. also, anything that's user-configurable will be (mis)used, potentially preventing improvements down the road. So the knobs that we do expose should be there for a reason and not just short-term fixes because something isn't working as expected right now.

(In reply to Peter Hutterer from comment #5)
> 
> reluctance to expose too many knobs for user configuration. Every knob added
> multiplies the testing and maintenance effort. also, anything that's
> user-configurable will be (mis)used, potentially preventing improvements
> down the road. So the knobs that we do expose should be there for a reason
> and not just short-term fixes because something isn't working as expected
> right now.

Right, that makes sense. I guess I'm just used to advanced config options in Windows allowing me tweak them separately. Also, there is only a single slider in the X11 version of Gnome, but I can get my touchpad working fantastic there. What exactly is that slider doing that the libinput one isn't?

And a last little quirk is that if the slider is in fact a acceleration curve adjustment option in Gnome-Control-Center, having it called "pointer speed" seems a bit weird. For me speed=velocity as far as cursor adjustments are concerned. You might not have any leverage over with the folks at the gnome camp, but if it is in fact a universal slider for both acceleration/velocity/whatever else, maybe calling it "pointer response" could be a little less counter intuitive. If you agree, perhaps you could ask one of them to change that lol.

Ok I'm doing a recording, how long should I make it exactly?

Created attachment 116412 [details]
evemu-record results

(In reply to Britt Yazel from comment #6)
> Also, there is only a single
> slider in the X11 version of Gnome, but I can get my touchpad working
> fantastic there. What exactly is that slider doing that the libinput one
> isn't?

https://github.com/GNOME/gnome-settings-daemon/blob/master/plugins/mouse/gsd-mouse-manager.c#L448
good luck figuring it out :) I should also note that the xserver's ptraccel code doesn't take those numbers unchanged either.

> And a last little quirk is that if the slider is in fact a acceleration
> curve adjustment option in Gnome-Control-Center, having it called "pointer
> speed" seems a bit weird. For me speed=velocity as far as cursor adjustments
> are concerned. You might not have any leverage over with the folks at the
> gnome camp, but if it is in fact a universal slider for both
> acceleration/velocity/whatever else, maybe calling it "pointer response"
> could be a little less counter intuitive. If you agree, perhaps you could
> ask one of them to change that lol.

If you know the difference between acceleration, velocity, etc. then you're IT-literate enough that it shouldn't matter :) for anyone else not calling it speed will be quite confusing.

Lol fair point. Did that recording give you what you needed?

yep, for now anyway. thanks

are you happy to give a git repository a try?

I'd like to get your opinion on the branch up to this commit here:
https://github.com/whot/libinput/commit/b4c5d76c6511d89d83d7ca4d8e86fd3edd971a60

git clone http://github.com/whot/libinput
git reset --hard b4c5d76c6511d89d83d7ca

build/install/restart X

note: this github branch is very much work in progress, it'll move around a bit, hence the direct commit sha

ya I'll give it a try. I'll let you know if I run into any hangups

Wow much better! It is much more predictable now. Whatever changes you made seem to work awesome!

The deceleration (is that a thing?) might be a bit off though now, and I'm just now noticing it. It now feels like the cursor comfortably accelerates up to speed and gets to the ballpark region of the screen that I want in a nice and predictable way, but I find myself slightly overshooting or undershooting still, and I think it might have to do with the final moments of my finger movements. I tend to slow my finger down as I near my target, and that adjustment to my finger speed is translating a little weird to the cursor. Does that make sense?

Created attachment 116681 [details] [review]
0001-touchpad-tweak-the-touchpad-acceleration-curve.patch

very much trial and error and a first result only. likely needs various changes for other touchpads but this feels pretty good on my T440.
Haven't looked at the speed config knob yet, don't expect it to do anything useful.

Applies on top of current master (1ba2f460bb316c9257)

It's getting better, though not quite there yet. I am noticing that really minute touch movements are not registering as movements under libinput, whereas the same minute movements (I'm talking 1-2mm) do register under synaptic drivers. That might be a reason for a lack of perceived precision, or it could all be in my head.

Also, it feels like the acceleration ramps up too quickly. There is a point right between the transition from slow movements and quick movements where the acceleration seems to take a jump, and it is a bit jarring. The only way to describe it is as if I am losing control of the cursor for a second. This leads you to a state where mentally the cursor is not where my mind thinks it should be, and I need to then cognitively reasses its location.

I think the big hangup is that the cursor needs to be predictable, and right now the algorithm is working in a way that my mind is not able to compensate with. The cursor "gets away from me" so to speak.

Thinking about this mathematically (note* this is pretty raw, as this is not my strong suit), what makes sense to me is this:

For the cursor to move 100% across the screen, at a maximum touchpad velocity threshold that should equal 100% across the length of the touchpad. And, at the lowest velocity threshold, the distance moved on the screen should equal that of the distance moved on the touchpad.

So something like:

Delta Xscreen = Delta Xtouchpad * (A) : whereas Amin = 1 and Amax = Screen Resolution/touchpad resolution

A is then a function of velocity bounded by these two values. And, with regards to changing velocity over a single finger movement, you could maybe treat the time between each frame as a individual events, with a recalculation corresponding to the screen frames.

Anyway, you have probably already thought of this, hope this maybe makes sense. I don't know. It made sense to me :-/

(In reply to Britt Yazel from comment #16)
> It's getting better, though not quite there yet. I am noticing that really
> minute touch movements are not registering as movements under libinput,
> whereas the same minute movements (I'm talking 1-2mm) do register under
> synaptic drivers. That might be a reason for a lack of perceived precision,
> or it could all be in my head.

libinput has a function to drop tiny movements (which I think is broken in synaptics, or at least not as consistent across devices). but that's in the sub-mm scale with libinput 0.18, on your device it should be 0.5mm.
the last patch, when applied to master doesn't have deceleration so the pointer movement is what the touchpad sends.


> Also, it feels like the acceleration ramps up too quickly. There is a point
> right between the transition from slow movements and quick movements where
> the acceleration seems to take a jump, and it is a bit jarring. The only way
> to describe it is as if I am losing control of the cursor for a second. This
> leads you to a state where mentally the cursor is not where my mind thinks
> it should be, and I need to then cognitively reasses its location.

hmm, interesting. for me it's almost too slow here and I feel the accel doesn't kick in when I think it does. You can play around with the parameters if you feel like it. the curve is a simple step of baseline, then linear up to max_accel. the parameters are:
baseline: basic speed of the device w/o accel
threshold: speed when accel starts kicking in
max_accel: maximum accel factor, will be relative to baseline (2 * baseline == twice as fast)
incline: the incline, the lower the longer it takes to reach max_accel.

In your case I guess you either need a smaller incline or a higher threshold.


(In reply to Britt Yazel from comment #18)
> For the cursor to move 100% across the screen, at a maximum touchpad
> velocity threshold that should equal 100% across the length of the touchpad.
> And, at the lowest velocity threshold, the distance moved on the screen
> should equal that of the distance moved on the touchpad.

we don't know the screen size in libinput and tbh I don't think this approach works anyway. I'm using my laptop with an external monitor connected (LVDS off), touchpads like the T650 are external, touchpads on the x220 was significantly smaller at roughly the same screen resolution of the T440, etc.

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

Hi Britt and Peter,

I've tried using the touchpad with the patch from comment 15 applied, and it feels better then the current git master. But to me personally it's too slow. I guess when the slider work gets finished I could just speed it up from the settings. The more serious problem is that there's no deceleration, minimum speed is baseline. That's too fast for slow movements. I've been playing with the parameters and this is what feels nice to me (also, I added deceleration at slow speeds):

	double baseline = 0.3;
	double min_speed = 0.2;
	threshold = 1.4;
	max_accel = 0.8;
	incline = 0.06;

	s1 = min(baseline, min_speed + speed_in * incline);
	s2 = baseline + (speed_in - threshold) * incline;

	factor =  min(max_accel, s2 > baseline ? s2 : s1);

(In reply to Velimir Lisec from comment #21)

awesome work! I don't have time to test it right this second, but will try to do it tonight. The deceleration I think is what was bugging me the most, hopefully this does the trick. You guys are awesome!

Velimir, works for me, feels just fine on my T440 here, fwiw the decel was something I that would've made a return anyway, it just was missing from the branch I'm working on here.
Not sure you're aware of this, but this one has a jump at the threshold where it goes from ~0.28 to 0.3. Other than that it's pretty much a straight line from (0, 0.2) to (3, 0.4) with no plateaus like the current code.

so this could be simplified with:
  speed = 0.0666 * speed_in + 0.2;
  factor = min(max_accel, speed)



fwiw ./tools/ptraccel-debug --mode=accel produces a graph of the accel function, though you'll need this diff first:
+++ b/tools/ptraccel-debug.c
@@ -276,7 +276,8 @@ main(int argc, char **argv)
        if (dpi < 1000)
                profile = pointer_accel_profile_linear_low_dpi;
        else
-               profile = pointer_accel_profile_linear;
+               profile = touchpad_accel_profile_linear;
+       //      profile = pointer_accel_profile_linear;

        filter = create_pointer_accelerator_filter(profile, dpi);
       	assert(filter != NULL);

This is unusual. I am using xf86-input-libinput under X, though when I switch between a Wayland and an X Gnome session, the cursor behaves slightly differently between the two. The speed is not consistent between the two, and I'm sorry to say, they way the cursor feels using xf86-input-libinput under X is still "better" than using raw Wayland.

Not that the Wayland cursor is bad by any means, it just feels like it is not as responsive to movement. Almost as if it constantly playing catch-up to where I physically want the cursor to be.

The laggyness under wayland may be caused by https://bugzilla.gnome.org/show_bug.cgi?id=745032

Finally starting to pick this up again. I have some complaints about slow movements not being right, so I wonder if dropping deceleration is the right idea. Simple patch to try out, it may be the right step, please let me know.

diff --git a/src/filter.c b/src/filter.c
index 0bb066c..5aec7df 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -662,6 +662,9 @@ touchpad_accel_profile_linear(struct motion_filter *filter,

       	factor = pointer_accel_profile_linear(filter, data, speed_in, time);

+       /* Disable deceleration */
+       factor = max(factor, 1.0);
+
        return factor * TP_MAGIC_SLOWDOWN;
 }

[Fedora 25/libinput 1.5.1/pure wayland]

The acceleration/deceleration curves definitely feel wrong to me too, and make the cursor feel like it's moving through something tacky. It isn't quick and accurate. And at slow speeds, it's unbearably slow and hard to move it small distances.

Created attachment 128092 [details] [review]
0001-touchpad-only-use-the-last-two-coordinates-for-delta.patch

This one seems to make the cursor a lot more reactive, it doesn't feel like it trails the finger motion anymore. Please give it a try.

Cursor movement is significantly improved with that patch! It feels much more responsive and better connected to your finger. Nice job.

I agree, this latest patch makes it feel WAY better

ok, great, thanks. I'm closing this one for now, if you're still unhappy in a few days time (give yourself enough time to adjust to the new behaviour) please re-open


commit cfdaaa32a73ba2f7b0379c2dbccabf120db8fc5e
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Nov 21 08:39:47 2016 +1000

    touchpad: only use the last two coordinates for delta calculation

This is a big improvement for long movements, but it still feels slow and imprecise for very small movements (< 10 pixels). Do you want a new bug for that?

yeah, that's going to be better than having it here, I tend to lose focus once we go past 30 comments in a bug ;) thanks

Here ya go!

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

Ok so I've been testing libinput 1.6 for a few days, and this is my feeling on it.

I'm not sure which I like better, the 1.5 behaviour or the 1.6. I feel like for slow-ish finger movements I am more accurate, but there are times when I quickly try to cursor and it flys much further than I had intended. It gives me a feeling of being out-of-control of the cursor.

However you have drawn the acceleration curve doesn't quite feel right, and it is hard for my mind to grasp the constantly changing acceleration. With 1.5 the acceleration felt more predictable, and I could counteract any perceived sluggishness by adapting my own behavior, but with this new set it is just odd. It neither feels sluggish or too fast, but rather both simultaneously.

I apologize for the typos. I sent that last message from my phone.

next version ready for testing: https://github.com/whot/libinput/tree/wip/touchpad-pointer-accel-v4

anyone?

Sorry Peter, I've been bogged down at work. I'll give this a test in a little while

Ok, so unfortunately due to my noviceness my computer is in an unbootable state after installing a clone of that git tree. I have no idea what I did wrong, but apparently force uninstalling libinput on Archlinux and make installing that package was enough to bork my system.

Ok, I got it working by just overwriting my currently libinput. 

Anyway, I would say that the slow to moderate motions are MUCH better. I noticed that the cursor was much more responsive and intuitive at those slower speeds. However, fast movements are tuned a bit overzealous at the moment. The cursor still appears to "fly away" during momentary jumps in cursor speed. Is there a way you can tune that down a tad?

Again, for reference, this is on a 2014 model Dell XPS 13

weird, not sure why you'd be in an unbootable state. libinput doesn't matter until gdm starts up. what git version did you test (I've been pushing to this a bit) and what accel setting did you use? and did  you change accel settings?

(In reply to Peter Hutterer from comment #42)
> weird, not sure why you'd be in an unbootable state. libinput doesn't matter
> until gdm starts up. what git version did you test (I've been pushing to
> this a bit) and what accel setting did you use? and did  you change accel
> settings?

yeah it was weird, GDM wouldn't even load. And I used the git version as you had linked it. I just downloaded the .zip of that branch and make installed it.

As far as which accel setting, I used a setting in Gnome-Control-Center at around the ~70% mark. And yes, I changed the accel setting a bit, but that level was the one that felt the most comfortable for my 'normal' pointer velocity.

@Peter: I seem to be facing the same issue on my Dell XPS 9350.

Can you help me on how I can test this commit?

I am on Ubuntu Gnome 17.04 and have updated all my packages.

To get this fix, how can I upgrade libinput? Is this fix in master already? Or can I build libinput myself and then try?

Any instructions on the same would help. Thanks a lot.

Can anyone help here? In the XORG session, the palm detection doesn't work properly. But the trackpad seems perfect.

In the wayland session, palm detection works but the trackpad doesn't feel in control at all.

Any way I can get this build to test out of my machine?

fwiw, we fixed the issue for gdm breaking after install. Caused by meson not restoring the SElinux context correctly.

Kanishk: I suspect you're still using the synaptics driver under xorg then. switching to xf86-input-libinput will change to libinput. Beyond that, no further work has gone into this since the last time I posted, been busy with a million other things, sorry.

Hi Peter,

I installed Ubuntu 17.10 and again have switched to the XOrg session since the condition still persists on the Wayland with Libinput session.

Can you tell me on how I can test this patch under Wayand with Libinput?

https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html
should have the bits you need, if not let me know and I'll add what's missing there.

Closing, libinput 1.8 or so had new touchpad accel code similar to the one linked above, this bug is now half a year old and got side-tracked with the SELinux issues. The current bug to complain about touchpad acceleration is Bug 101139