Bug 98839

Do you have tapping enabled and if so do you notice a difference when you disable it?

No, I keep it disabled, but I notice no difference when I enable it.

I just tried out the patches you posted recently: https://lists.freedesktop.org/archives/wayland-devel/2016-December/032326.html

The result is generally better, especially at medium speeds (yay!) but does not address the issue brought up here: the cursor's stickiness and lack of movement when pivoting and rolling the fingertip, or moving it in a very small circle. It's like at very slow speeds and distances, the cursor only wants to move horizontally or vertically, not both.

I can now successfully move the cursor with pixel-level precision vertically or horizontally, but any kind of both-vertical-and-horizontal movement (diagonal motion, making circles, etc.) is sluggish, jerky, and feels unnecessarily constrained to the X and Y axes.

Have we checked the size of your touchpad yet? 105x97mm - is that accurate? If not, please run the touchpad-edge-detector tool (check that the axis ranges are correct anyway please).

From what I can tell, the issue is that your touchpad's deltas for this particular recording are extremely small - in the 1-4 device unit range. At the device's x/y resolutions that's 0.027/0.016mm precision. Our hysteresis code uses 0.5mm to avoid pointer wobble, so most of your movements fall into that code.

This is even further amplified by the issue that the hysteresis works ok while moving in the same direction, but whenever you change directions the margin takes effect. so rolling a finger left/right would show the worst effect, continuing in one direction should be fine. And indeed the delta shows a lot of back/forth movement at the device-unit level.

Either way, I think this also explains why the movement feels like it snaps to one axis, the hysteresis is calculated separately so you can get one axis suppressed back and the other axis move on normally. *maybe* this could be fixed by changing the hysteresis to use hypot() but that's quite expensive to run over every delta. Feel free to try this though locally.

We tried removing the hysteresis but it caused pointer wobbles for a lot of people. Did you ever use synaptics on this touchpad? Did that behave better?

I ran touchpad-edge-detector for https://bugs.freedesktop.org/show_bug.cgi?id=99000:

$ sudo touchpad-edge-detector 118x58 /dev/input/event4
Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event4
Move one finger around the touchpad to detect the actual edges
Kernel says:	x [1302..5640], y [1116..4740]
Touchpad sends:	x [1302..5641], y [1115..4740] |^C

Touchpad size as listed by the kernel: 117x56mm
User-specified touchpad size: 118x58mm
Calculated ranges: 4339/3625


I've tried the Synaptics driver and it's a *little* better that libinput, but not much. The same basic problem remains.

I can play around with the hysteresis and see if that makes a difference.

After recompiling libinput and installing it to /, is there an easier way or reloading the driver than restarting?

Turning off the hysteresis entirely definitely has an effect, but it doesn't resolve the issue.

It doesn't feel like an event rate issue either; with my touchpad, I can make medium-sized circles as fast as I can move my finger. As I reduce the size of the circles though, at about 1 cm diameter, the cursor stops moving in a circle and sort of wobbles awkwardly around its current location.

(In reply to Nate Graham from comment #5)
> Touchpad size as listed by the kernel: 117x56mm
> User-specified touchpad size: 118x58mm

close enough, I'd say

> After recompiling libinput and installing it to /, is there an easier way or
> reloading the driver than restarting?

I'm going to assume you didn't install to / given that you notice an effect but there are a few things to watch out for: use --prefix=/usr and on fedora also add --libdir=/usr/lib64. libinput master has a lower soname than 1.5.3, so you may be installing it correctly but things are still picking up the other one. Make sure to remove libinput.so.10.10.4, as master will currently install 10.10.3
Once installed, you need to restart X only (or the compositor if you're under wayland), no need to actually reboot.

For local testing, use the ./tools/event-gui app. It's not exactly the same and affected by lag but good enough to get an idea before having to restart the session.

(In reply to Nate Graham from comment #6)
> Turning off the hysteresis entirely definitely has an effect, but it doesn't
> resolve the issue.
> 
> It doesn't feel like an event rate issue either; with my touchpad, I can
> make medium-sized circles as fast as I can move my finger. As I reduce the
> size of the circles though, at about 1 cm diameter, the cursor stops moving
> in a circle and sort of wobbles awkwardly around its current location.

I think what you're seeing is an effect of the firmware skipping data, most likely to avoid pointer wobbles. The problem is simply that the interaction you want to have is very similar to someone holding the finger still but still getting changing sensor readings. This effect is particularly bad on the Lenovo T450 [1] In that case, there isn't much we can do though.

[1] https://who-t.blogspot.com.au/2016/09/libinput-and-lenovo-t450-and-t460.html

You could try the RMI4 patchset to see if it makes a difference: http://lkml.iu.edu/hypermail/linux/kernel/1612.2/00646.html

Thanks for those instructions. Turns out I hadn't actually applied the patch before and my observations were just the placebo effect. Oops. Removing libinput.so.10.10.4 and jiggling a symlink made the new one apply properly, and what a difference! It *is* better for the use case described in this problem report--not good enough to close it out, but it's definitely better. I can now draw smaller circles with the touchpad than I could before, but still not small enough. I'll play with the hysteresis again now that I'm actually able to test code changes locally.

Oh my god, with hysteresis off, it's PERFECT.

I understand that some hardware needs this. But for my hardware, it's night-and-day, the difference between almost unusable and perfect. It makes me think that applying hysteresis needs to be either user-configurable, or we should maintain a list of hardware that needs hysteresis and only enable it for only those pads.

I simply can't imagine using libinput with hysteresis again.

Have you tried the RMI4 patches yet by any chance? Would be interesting to know if that changes things.

Yes, I'm running with a version of the 4.10 kernel which has the RMI4 patches applied. I tried turning hysteresis back on and I'm sorry to say it's still awful. Might be a *little* better than with the 4.9.x kernel series, but with hysteresis on, I still can't draw tiny circles.

I really think we need to be able to turn hysteresis off entirely for certain hardware, whether via a user-exposed setting, a hardware blacklist/whitelist, or something else. For my touchpad, it's simply not needed--an anti-feature--and having it off has been a singularly more pleasant experience.

Have a look at commit afdcaf50157c0a76389740885bed3719b758dc37, that provides a blueprint for the patch required to mark your touchpad as one that doesn't require hysteresis. I'm willing to give in here to see whether we'll see any pushback (see 27078b2). Happy to review and merge a patch for this.

I think long-term we may need a "make cursor precise" vs "stabilize cursor" option or something, but let's see how long we can avoid that.

I gave libinput a try on ArchLinux (libinput-1.5.3). I experience similar symptoms as described by Nate.

I'm not sure how Nate turned off the hysteresis but I assume that this is done by setting hysteresis_margin.x/y to 0 in tp_init_hysteresis().

So I gave this a try and fixed the sources for libinput-1.5.3 and I can say that this improves the situation for me as well.

My hardware is a HP Elitebook 8540p and I fixed the touchpad (Synaptics) ranges as described here beforehand: https://wayland.freedesktop.org/libinput/doc/latest/absolute_coordinate_ranges.html

Although the pointer is very sensitive now (almost too much), I prefer this setting to what it was before.

Is there some hysteresis value that seems to make things useful? The default should be 0.5mm (which is tiny, you'd think). Is there some other value where the hysteresis still keeps the pointer from being sensitive but at the same time it doesn't prevent small movement?

I tried a bunch of different very small values, but honestly, for my hardware none of them were better than simply having it off entirely. Since the feature itself is essentially a workaround for lousy hardware, it would seem preferable to just be able to turn it off. Or--horror of horrors :)--have the value be adjustable so people can dial it into their own hardware.

I have the hysteresis value at 1/10mm atm. I'll probably keep playing with the value a little bit to find the best balance for me.

not sure if this is the same but I'd like to add that on a Wacom Intuos 5 S the touch sensitivity at small finger movements is very 'rough', like when trying to draw a small circle with a diameter of ±1cm, I get a square. all small and precise movements seem to result in horizontal and vertical movements only. This is especially noticeable when you're trying to hit the 'X' of a browser tab - you get to the area of the tab with the cursor very fast and then spend more time trying to hit that small 'X' sign. to me it seems like a combination of delayed cursor with together with the restriction of small movements to the vertical and horizontal axis only. (very different to how the touch registration behaves on the same tablet connected to my work mac with the official wacom drivers installed)

Yup, that's hysteresis. There's currently no UI switch to turn it off, unfortunately so. The issue will disappear if you re-compile the code with it disabled (comment out "tp_motion_hysteresis(tp, t);" in src/evdev-mt-touchpad.c).

thank you, that seems to improve things indeed! the cursor doesn't stick to the horizontal and vertical axis anymore and is more precise. might be worth to note that there is still a bit of lag, and by very small movements the cursor doesn't move much, drawing small circles quickly makes the cursor to stay in the midddle.

I'm experiencing the same issue as described here with hysteresis. In the long term, a knob per bug 94379, comment 29 is needed. In the meantime, I've been having a look at restoring the "PRECISE_TOUCHPAD" flag to disable hysteresis.

(In reply to Peter from comment #12)

> Have a look at commit afdcaf50157c0a76389740885bed3719b758dc37, that provides > a blueprint for the patch required to mark your touchpad as one that doesn't > require hysteresis. I'm willing to give in here to see whether we'll see any > pushback (see 27078b2). Happy to review and merge a patch for this.

I'd be interested to hear your thoughts on: https://github.com/tlvince/libinput/compare/tlvince:7272696...tlvince:9259143

Note, this doesn't restore the tag on Apple and Lenovo *40 devices. I'm aware hysteresis has been enabled/reverted a few times (e.g. 48473994c8e60189356feae7b7eae25288e5ac28) and I agree maintaining a list of device-specific flags is unscalable, but this is a real issue[1] for some users and this seems the easiest way to do it _right now_ (it could be again removed once suitable user-facing configuration is in place).

[1]: https://www.reddit.com/r/archlinux/comments/52makr/fyi_libinput_works_much_better_than_synaptics_on/dadogfd/?st=j12aqwqi&sh=ec733a11
https://bbs.archlinux.org/viewtopic.php?id=224643

sorry, only just starting to catch up with bug mail again.

the archlinux post suggests that for some users removing the hysteresis makes it worse again. As said above in comment #12, we may need a toggle for that, but rather than a config option for all users to set, I'd rather have a 'precise' vs 'lenient' choice (or whatever it'll be called). This would allow us to set other bits as well depending on the choice. Not 100% sure on all this yet though, mostly because there are so many complaints about touchpad acceleration open that I'm wondering whether this one here will go away once we fix most of those.

but the main thing: here I can get pixel-granularity movement by rolling my finger (or moving it). The hysteresis applies only for the first **0.5mm** of movement, though it applies to the axes separately. So I'd really really like to see a proper analysis by someone who experiences the problem instead of just "let's disable it", because that's just papering over the issue.

Acceleration and hysteresis are different problem spaces. I sincerely doubt that hysteresis-related complaints will disappear if you improve the acceleration.

I experience the problem and confirm that rolling my finger half a millimeter results in no cursor motion at slow speed, and ad moderate speed the cursor seems constrained to the X or Y axis exclusively. 0.5mm threshold or no, I can tell you that this happens, and that disabling hysteresis makes the problem disappear.

> So I'd really really like to see a proper analysis by someone who experiences the problem instead of just "let's disable it", because that's just papering over the issue.

This makes sense. What information do you need? Would another evemu recording be useful?

(In reply to Nate Graham from comment #22)
> Acceleration and hysteresis are different problem spaces. I sincerely doubt
> that hysteresis-related complaints will disappear if you improve the
> acceleration.

not all of them, but some of them may.

> I experience the problem and confirm that rolling my finger half a
> millimeter results in no cursor motion at slow speed, and ad moderate speed
> the cursor seems constrained to the X or Y axis exclusively.

that bit needs to be fixed then. but really, half a mm is.. tiny, I'm not sure how much movement you'd expect there.

> I can tell you that this happens, and that disabling hysteresis makes
> the problem disappear.

yeah, then we need someone (you :) to look into how to fix this. I still don't think just removing the hysteresis is a good idea, especially when it's clear that there's some other bug that snaps it to the axes. Let's fix it first so it works as intended, then we can look at it again.


(In reply to Tom Vincent from comment #23)
> This makes sense. What information do you need? Would another evemu
> recording be useful?

not really, especially because ETIME. I need someone to look at this and figure out what's going on and how to fix it.

how about adding a switch for disabling histerisis until things are sorted out? Cause now the situation is recompiling libinput after every update :/ Anyways, thanks for your work on this.

see comment #24, I'm not adding a temporary option. It adds quite a bit to my already full workload and pretty much guarantees that we can't remove it in the future.

I would like to help with this problem when I find time myself...

It appears some common laptops like Lenovo X1 Carbon (gen4 and gen5) need at lot of work and are borderline unusable (https://bugs.launchpad.net/ubuntu/+source/libinput/+bug/1696929)

However having used the Xorg synaptics driver in the past I know half the problem is hysteresis, which needs to be turned off. The other half the problem seems to be a regression in Synaptics hardware/firmware after the gen3 X1 Carbon. Frankly, it's still laggy even without hysteresis, but at least becomes usable.

Also, regarding "there's some other bug that snaps it to the axes"; yes, that's a visible problem. Drawing circles (not even tiny ones) on the touchpad results in the cursor moving in a square. It sounds to me like hysteresis has been implemented per-axis, when actually it might be better implemented in an omnidirectional fashion (one threshold, not one threshold per axis) using simple Pythagoras.

(In reply to Daniel van Vugt from comment #27)
> It sounds to me like
> hysteresis has been implemented per-axis, when actually it might be better
> implemented in an omnidirectional fashion (one threshold, not one threshold
> per axis) using simple Pythagoras.

yeah, it's per axis atm. I had a patch for this in 
https://bugs.freedesktop.org/show_bug.cgi?id=99410 which was ignored and eventually closed. Feel free to give that one a try or improve on it.

I have this same problem with a Thinkpad P50.  I used recordmydesktop to get a recording of what the "jumping" looks like: https://www.youtube.com/watch?v=EJFd2IWHCWw

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

(In reply to Peter Hutterer from comment #4)
> Did you ever use synaptics on this touchpad? Did that behave better?

Until I've updated from Debian Stretch to Testing, the combination of X.org and Synaptics was perfect and my touchpad (Acer Aspire V5 notebook) works like a charm. The problems began with wayland and libinput.

Any workarounds?

Thanks.

I too get a much more pleasant experience with zero hysteresis on a Dell Precision 5520, which is similar hardware to a Dell XPS 15 or Dell XPS 13. With hysteresis, I can't make small movements easily, and when I can they are likely to be snapped to purely horizontal or purely vertical movement. Targeting small things is needlessly tricky - the hysteresis is definitely a hindrance on this hardware, I find it hard to imagine anyone on this hardware would prefer it to remain enabled. Disabling it is like night and day.

Here's how I'm working around the problem on Ubuntu at the moment by applying a patch from an Arch Linux AUR package in a way that is friendly to Ubuntu/Debian packaging (and thus cleanly reversible using dpkg etc):

(replace 1.8.2 below with whatever version is the latest in your repos)
 
* Add "source code" to software sources in software and updates settings

* Then do all this to get the source, get the patch, apply the patch, rebuild and install (existing libinput will be replaced)

    cd ~/tmp
    apt-get source libinput10 devscripts
    cd libinput-1.8.2
    wget https://aur.archlinux.org/cgit/aur.git/plain/disable-hysteresis.patch?h=libinput-no-hysteresis
    patch -p1 < disable-hysteresis.patch
    sudo apt-get build-dep libinput10
    sudo apt-get install devscripts
    dch -i # enter a changelog message like "apply patch to disable hysteresis"
    debuild -us -uc -b
    sudo dpkg -i ../libinput10_1.8.2-1ubuntu3_amd64.deb ../libinput-bin_1.8.2-1ubuntu3_amd64.deb ../libinput-tools_1.8.2-1ubuntu3_amd64.deb

If you're using more than those three libinput packages you may need to tell dpkg to install more than

Then logout and login to use the newly built and installed libinput10

I also like making these changes for a more responsive touchpad, but YMMV:

in src/evdev.c:
    // Set the scroll thresholds to zero for instant scrolling:
    device->scroll.threshold = 0.0; /* Default may be overridden */
    device->scroll.direction_lock_threshold = 0.0; /* Default may be overridden */
in src/evdev-mt-touchpad.c in tp_unpin_finger():
    // Remove the surrounding if statement to unpin a
    // finger immediately after a click instead of only after 1.5mm:
    t->pinned.is_pinned = false;
    return;

I do the same thing.

Peter, if you're still reading along, I hope all these anecdotes offer some proof that we need at least one more more setting here ("Smooth small movements"?). I know you don't want too many options, and I agree with you, but this is getting to be a pretty common request, and I don't think that adding it will reduce us to xf86-input-synaptics' "random number generator" territory.

I've got a plan to devote Ubuntu Desktop Team time (myself) to it starting early next year. Of course it would be great if someone else committed improvements earlier than that.

In my case I find many laptops don't respond to finger movement for almost the first 5.0mm or so (not 0.5mm :). Comparing to macOS or a good Chromebook (like a Dell 7310) it appears those devices with a great touchpad experience don't really employ noticeable hysteresis at all.

Forgive me if I missed it, by why do we have hysteresis?.. As I understand it, if one finger is touching then you want maximum precision (zero hysteresis). And if multiple fingers are touching then the cursor should simply stop moving as gestures take over. So I don't yet understand why hysteresis is there at all. Although I can also see ways to improve it if we can't remove it.

Sorry, I should have both read more and remembered more. I now recall the ThinkPad X220 really needed hysteresis for single finger clicks. Due to high touchpad precision and small touchpad size, the cursor would move during the click. Lenovo "fixed" this in the X230 by making the touchpad hardware just much less precise.

OK, it sounds like we've got another simple math problem somewhere. If Peter says the intended hysteresis is 0.5mm but I'm often seeing 5.0mm then that sounds like a simple bug.

we tried to remove the hysteresis a while ago and got so many complaints about the fingers still wobbling that we had to re-instate it. It was largely whack-a-mole with the various touchpads. Search for LIBINPUT_MODEL_WOBBLY_TOUCHPAD in the log, f6c2d4b and 27078b2 mark the range that is interesting.
Things *may* be better now with SMBus/RMI4 being more common, but I don't know.

The reason we have it is that a large portion of all touchpads wobble when you hold the finger still on the touchpad. That wobbling is hard to/impossible to determine from real finger movement, the hysteresis is the only solution here.

tp_init_hysteresis() is the function here, the margins are set to res/2, so 0.5mm each direction (i.e. the whole hysteresis area is 1mm wide). The way it's implemented means that the hysteresis doesn't take effect after the first 0.5mm of movement though because continuously moving in one direction will keep moving the edge. See the comment at evdev_hysteresis().

I wonder how it interacts with touchpads that have hysteresis built into the hardware/firmware?

I mean the distances are the same, but some touchpads (like the X1 Carbon gen 4 vs gen 3) seem to be doing some hysteresis themselves. Even when disabled in software.

well, it always applies on top of the hardware hysteresis. having said that, if the hw hysteresis exceeds the 0.5mm, it should never trigger, so the hysteresis applied should always be the maximum of 0.5mm and the hw hysteresis value.

Since some touchpads are unusable without hysteresis in its current form, and some are unusable with it, that implies to me that this needs to be configurable, either by the user (preferred), or by device property introspection so we can let libinput determine based on the hardware when hysteresis needs to be on.

I don't think we can use the device properties, because there's at least one touchpad that was supposed to be non-wobbly and at least one user complained about cursor wobbles when the hysteresis was removed.

the issue is still what configuration option to intruduce. A simple "hysteresis on/off" is not good enough. we'd likely still need some hardware-specifics on top. And there are some other issues that are related to this behaviour like the pointer moving before/after a click or release.

I was thinking hysteresis should eventually be a GUI slider from the user's perspective. Just configure a distance from 0 (off) to N.

What exactly would the slider configure though? Think of it as a formal specification, so you have to specify units, behaviour, etc. And then assume you can't ever change this in the future :)

Units could be millimetres (or fractions thereof). But a simple on/off switch would be fine too. I don't mind, so long as _something_ is done.

The GUI to control Synaptics in KDE Plasma's system settings exposes a slider that does just that: it lets the user determine the small movement smoothing threshold in millimeters. I know  I know, "random number generator" and all that--but such a slider is basically what we're are asking for here. Being able to set a smoothing threshold that goes from 0mm to, say, 5mm, in increments of 0.1mm, seems like it would solve this problem.

There is some urgency here because technological progress being what it is, the percentage of laptops with really low-quality touchpads of the sort that hysteresis improves is likely to drop over time. Without the ability to configure or turn off software hysteresis, libinput will become almost unusable for a larger and larger share of our users' hardware.

And it really is almost unusable for touchpads that don't need libinput's additional hysteresis: it destroys slow-speed precision for those touchpads, and using it is a truly maddening experience. An unchangeable default that renders the touchpad frustrating for those with decent quality hardware isn't likely to generate a neverending stream of appreciation for libinput in the Linux community. :)

I need from *all* of you that want the hysteresis changed two evemu-recordings, as separate *attachments*:

start evemu-record, put a single finger down on the touchpad, hold the finger still for ~10s, then lift it.

start evemu-record, put the finger down on the tochpad, move as slow as you can to horiztonally to the left for ~2cm, lift the finger. Repeat, moving vertically up for ~2cm.

It sounds like you're not testing a major use case that's most annoying: changing directions without lifting fingers. By that I mean moving right then left, or up then down. Hysteresis seemingly breaks this use case the most. Is that intentional?

As I understand it, this relates to the observation that drawing small circles results in the cursor moving in a square. Because that demonstrates both axes changing directions. This use case I suggest also directly relates to trying to target a button with your finger.

So I feel your request might miss the issue...?

yes, it's intentional. the data this gives me is 1) if the firmware does motion filtering, a static finger should not generate pointer events and 2) the minimal delta the firmware will give me on slow movements. both help to calibrate the hysteresis.

I know what the software does, what I need to know is what the hardware does. or some of it anyway...

Created attachment 135028 [details]
Nate Graham - single finger held still for 10s

Created attachment 135029 [details]
Nate Graham - slow movements left then up

Attaching the requested files.

Hardware: HP Spectre x360
Distro: Kubuntu 17.04
Kernel: 4.10.0
Session: X, not Wayland
libinput version: compiled from git master as of about 30 minutes ago

Created attachment 135030 [details]
x1carbongen4_results.zip

Test results from ThinkPad X1 Carbon gen 4.

Lots of pressure events for small finger movements. Not so many position events...

Created attachment 135031 [details]
x1carbongen5_results.zip

Results from ThinkPad X1 Carbon gen 5.

Give this branch a try please, thanks:
https://github.com/whot/libinput/tree/wip/touchpad-hysteresis-issues-v2

I like the ideas I'm seeing in your git branch.

Unfortunately that branch made zero improvement on either X1 Carbon gen 4 or 5.

Typo:

+	if (!tp->hysteresis.enabled)
+		tp_maybe_disable_hysteresis(tp);

should be:

+	if (tp->hysteresis.enabled)
+		tp_maybe_disable_hysteresis(tp);

After I fixed the typo, the fix was good but not perfect. On both X1 Carbon gen 4 and 5.

The system doesn't see long enough periods of a stationary finger in reality to learn to disable hysteresis soon enough. But if I held my finger still for a short while it would switch over properly.

While I like your thinking with that heuristic, and it should probably stay, I still think some defaults (of off) need to be hardcoded for the problematic touchpad models.

I tried out that branch on my hardware (after applying Daniel's fix) but it didn't make any difference for me, even after holding a finger stationary for 30 seconds to try to get it to learn.

Maybe my hardware does less filtering than Daniel's. Still, it's a night-and-day difference without hysteresis, and I don't see any jumpiness at all when it's off.

doh, I thought I had pushed the !enabled fixed, done now and force-pushed so the branch is up-to-date and ready for testing. Thanks for spotting that. Commit is currently 1b251c2676130 but I may need to push more later.

The current event count of 5 means holding the finger stationary for ~60ms on most touchpads. That's short enough that I can trigger it here even when trying not to, usually it triggers before I even start moving the fingers, right after I place it on the touchpad for the first time. That's on a T440 which is equivalent to the X1 3rd iirc, so an older touchpad.

I recommend testing with sudo ./build/libinput-debug-events --verbose, that prints a message when the hysteresis is disabled. If the message appears, then hysteresis is ignored.

Nate: attachment 135028 [details] has several non-moving event streams that last a second or even longer. So it should definitely activate on your touchpad. I tested all the attachments above (still and moving) and they all disable the hysteresis within the first fraction of a second, before the first events come out of the device.

The only case where the period may be significantly longer than 60ms would be if the touchpad firmware filters pressure and you don't get *any* events before the next motion event some time later. That can happen, see E 1.557756 in Nate's attachment 135029 [details] which is 119ms after the previous one. But that is the exception. Needs fixing, sure, but a very niche issue.

It feels like the tests you asked us to record are not indicative of normal use. Under normal laptop use there is apparently not a period of 5 pressure change events early enough. You start using the laptop and it feels awful - can't put the cursor anywhere you want it to go. Hysteresis is at least 5mm and the cursor refuses to move in natural curves -- only vertically or horizontally. Only by staying still for a short while does it switch over. Although it _should_ theoretically by the time you get to the first button click. Maybe we need to spend more time testing the branch...

On that note, I'm still suspicious as to why hysteresis is so large -- around 5mm on multiple different machines. The only theory we have that explains that is hardware hysteresis having an additive effect, because you say it should be less than 1mm. Actually I have a second theory that weird unsmooth acceleration curves [1] also contribute to the unnatural feel and poor pointer control but that's a different bug. Perhaps also default acceleration curves are decelerating for minimal velocities, which changes the hysteresis distance??

Long term I feel the only reliable options for hysteresis are to:
  (a) Hard code hysteresis off for some hardware; and
  (b) Make it a user-visible option.

I've spent more time using a Macbook and Chromebooks and they are dramatically better, for various reasons. There is no noticeable hysteresis there -- the tiniest finger movement is responded to.

P.S. X1 Carbon gen 3 is very different to gen 4 and 5. Gen 3's touchpad is just wonderful and amazing (although also works best without software hysteresis). I can provide stats from that one too if you are curious.

[1] https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html

Try the branch again, I changed it to a timeout-based approach in case the other events get swallowed. commit fd96be761e53. That one is at a fixed 80ms but that *has* to be short enough. It's less than our tap timeout, iirc...

Please do test this more, especially with the --verbose flag I mentioned above to check if the hysteresis is in fact disabled on the fly. And of course the usual checks that the new version is actually being used, etc.

As for the other commments: I don't know why the hysteresis is so large. It's initialized as res/2 which is 0.5mm in physical dimensions. even if the hw hysteresis is larger than that, ours wouldn't do that much because you'd always be exceeding the margin anyway.

Also, fwiw, the hysteresis is applied before pointer acceleration, the deltas fed into acceleration have the hysteresis applied to them already. If that affects the acceleration it'd be easy to figure out - simply printf the accelerated coordinates (src/filter.c) for a recorded event sequence and compare them with/witout hysteresis.

IIRC the T450 has the same touchpad as the gen4, the below may matter. Though it wouldn't explain why it works with the hysteresis disabled. 
http://who-t.blogspot.com.au/2016/09/libinput-and-lenovo-t450-and-t460.html

I have a t450 but I'm moving house atm and it's in a box already. Should be able to test it next week. I don't remember it being that awful though and I had been using that device for testing for a while.

Confirmed the new branch headed at fd96be761e538ef53ef67ef49c6b37407a948492 is great (always seems responsive, no obvious delay).

Tested on both X1 Carbon gen 4 and 5 using Ubuntu 17.10 (Gnome Shell 3.26.1). Ship it :)

I never needed any logging. It was a night and day difference just watching the cursor move in gdm and gnome-shell.

Thanks for the tests, much appreciated. Patchset is on the list:

https://lists.freedesktop.org/archives/wayland-devel/2017-October/035587.html

Created attachment 135200 [details]
Still can't draw small circles using the conditional hysteresis branch

I'm still not seeing any improvement with this branch. I've verified that's it's being installed properly:

$ ls  /usr/lib/libin*
ls: cannot access '/usr/lib/libin*': No such file or directory

 ls -la /usr/lib/x86_64-linux-gnu/libinput*
lrwxrwxrwx 1 root root     19 Oct 31 21:27 /usr/lib/x86_64-linux-gnu/libinput.so -> libinput.so.10.13.0                                                                             
lrwxrwxrwx 1 root root     19 Oct 31 21:09 /usr/lib/x86_64-linux-gnu/libinput.so.10 -> libinput.so.10.13.0                                                                          
-rwxrwxr-x 1 root root 731328 Oct 31 21:09 /usr/lib/x86_64-linux-gnu/libinput.so.10.13.0

Still, hysteresis doesn't seem to turn off like it probably should. I still can't draw small circles. I'm attaching an evemu recording.

(And yes, the branch was up-to-date: the latest commit was fd96be761e538ef53ef67ef49c6b37407a948492)

With your recording:

$ sudo ./build/libinput-debug-events --verbose
[...]
-event21  DEVICE_ADDED     SynPS/2 Synaptics TouchPad        seat0 default group21 cap:pg  size 106x98mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on
event21 - hysteresis disabled
event21 - pressure: begin touch
event21 - thumb state: THUMB_STATE_MAYBE → THUMB_STATE_NO
event21 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA
 event21  POINTER_MOTION    +2.44s	 -0.22/ -0.12
 event21  POINTER_MOTION    +2.45s	 -0.38/  0.21
 event21  POINTER_MOTION    +2.49s	 -0.45/ -0.25
 event21  POINTER_MOTION    +2.50s	 -0.98/ -1.81
 event21  POINTER_MOTION    +2.51s	 -1.07/ -2.36

So the hysteresis is disabled before the first motion event is sent, right after putting the finger down.

But it still doesn't feel right. When using the branch, I still can't draw tiny circles with small finger movements the way I can when I disable hysteresis by simply commenting out tp_motion_hysteresis(tp, t); in src/evdev-mt-touchpad.c. With that change, it feels perfect.

I'm attaching an evemu recording of me successfully drawing small circles with tiny finger movements when using libinput what that single change.

Never mind, I forgot to remove Synaptics that time.

Comparing your branch with master where I've permanently turned off  hysteresis hysteresis, they are the same. So I approve this patch; it does make a difference. The precision with very small movements is still not as good as it was with Synaptics, but we can track with with another bug. Feel free to mark this as RESOLVED whenever the patch is merged to master.

Nate: For extra precision, maybe try the "flat" pointer acceleration profile if you can find a way to enable it:
  https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html
Interesting for future experimentation, but now off-topic for this bug.

pushed to master, thanks for testing.

commit 50daa7b30fd1e13545944540a0ad3794bbf2ef09
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Oct 26 13:56:44 2017 +1000

    touchpad: automatically disable the hysteresis where not required

Nice work. I am pleasantly surprised to see we have a solution that will work for other arbitrary touchpad models too.

+1

I recently applied this hysteresis autodisable patch (https://github.com/wayland-project/libinput/commit/50daa7b30fd1e13545944540a0ad3794bbf2ef09) on my T25 and it worked brilliantly, so I applied it on my wife's T440p and experienced wobble for a second after the finger(s) stopped moving. After that second, the wobble stops. This was apparently good enough for libinput to disable its hysteresis, but it makes two-finger scrolling very annoying.

Fortunately I fixed this by upgrading the touchpad firmware: https://support.lenovo.com/cz/cs/downloads/ds121241 (it says L540, but it works with T440p as well). So I'm just writing this here in case anyone else happens to have an old touchpad firmware and the patch gives them wobbles.

(Anyway, thanks a lot for this patch. It was the final missing piece that let me switch from synaptics to libinput.)

I naively thought this fix would be in libinput 1.9.2 but it's still not in 1.9.3. The fix is only in master. I guess we're waiting for libinput 2.0 on this one...?

yeah, it'll be in 1.10, not adding that to the 1.9. branch we have enough problems there as it is

Seems Debian+Ubuntu accepted this as a patch, then reverted it because someone said it was too twitchy:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884599

Is there a right way to approach this now that will satisfy everyone, other than a configuration option?

I'll need an evemu from that device please

Created attachment 136276 [details]
evemu recordings on Dell XPS L502X

I'm the person which filed the Debian bug and was complaining about the touchpad being twitchy with the patch applied.

I've attached some evemu recordings as described in comment #45.

https://lists.freedesktop.org/archives/wayland-devel/2018-January/036475.html fixes the issue with the current code, but it doesn't fully address James' issue. That however requires a separate bug because that touchpad may need special handling, see Bug 104533

Back on the topic of this bug in particular, I have recently seen that both Dell XPS 13 and Apple Macbook airs also require this fix. Although they have really nice touchpad hardware, the hysteresis in libinput ruins it, making them unresponsive to precise movements. And drawing a circle moves the cursor in a square.

I was surprised to see that even great touchpads need the same fix. Although I haven't had the opportunity yet to test this fix on those.

which fix? the one in comment #68? then, well, yeah, that's the whole reason for this bug report to begin with.

Put another way, I haven't yet seen any touchpad that didn't need hysteresis turned off (or reduced, or redesigned). I just made that comment because I was surprised to see even the best touchpads I know of are also affected.

So in my mind this fix is just about the single most important fix we need to get into Ubuntu 18.04. It eclipses other bugs because there's little need for other fixes if the user can't move the cursor and therefore chooses not to use the desktop at all. That's not an exaggeration, just a fact that I am experiencing myself and want to make sure it doesn't remain so going into Ubuntu 18.04.

So when is libinput 1.10 due? :)

More good news: This fix works like magic on the Dell XPS 13. It's wonderful now.

we had turned the hysteresis off once and re-enabled it because of a whack-a-mole game with touchpads that needed it. look up the history between f6c2d4b8b5e1968411568d81b47488a655ba47a1 and 27078b2667def4ecde1f47b8258d510a576c8bb1 and you'll find how many exceptions we had to put in because too many touchpads have wobbly cursors without the hysteresis.

huh? what fix, the one from comment #77? did the XPS have pointer wobbles before?

No, the original fix from comment #68, I think. Or more precisely - libinput version 1.9.4-1 from Debian/Ubuntu does the trick (reverted in 1.9.4-2 due to James' issue unfortunately).

The XPS 13 never had wobbles, it's the opposite. Libinput refused to move the cursor at all in response to anything other than large finger movements. And drawing a circle made the cursor move in a square. So the fix for this bug in general is working a treat on the XPS 13.

I have done more hardware testing today with four different laptops and three different versions of libinput. The laptops are X1 Carbon gen 4, X1 Carbon gen 5, Dell XPS 13 (4th/5th?) and Apple Macbook Air 11 (2015). The results for all machines were the same:

libinput 1.9.4-2 (Debian/Ubuntu): Terrible, unresponsive to small movements

libinput master HEAD: Great, always

libinput master HEAD + patch from comment #77: Good, but terrible in the beginning. I have to consciously hold a finger still at first before hysteresis turns off. Then it's good.

thanks for testing, basically matches my expectations. Note that you are fine-tuned to notice this bug at the moment. The timeout is 80ms and it only needs to be triggered once during the lifetime of the libinput context (i.e. only once until you log out/reboot). I don't consider that as a massive problem, in the vast majority of use-cases it will be disabled before you even click the login button or at least shortly thereafter.

I am happy to wait and see how the patch in comment #77 goes in the wild but I'm slightly less optimistic about it only taking 80ms.

Starting on a login screen I find myself swiping the touchpad to move the cursor. So since the cursor is moving the 80ms timeout wouldn't be reached in those early seconds. Because it's always moving and not the requisite stationary for a short period. But yeah I guess it would probably happen after a while. And if you're aware of it you can trigger it immediately.

(In reply to Daniel van Vugt from comment #87)
> I am happy to wait and see how the patch in comment #77 goes in the wild but
> I'm slightly less optimistic about it only taking 80ms.

Comment in the code:
  If the finger is down for 80ms without seeing motion events,
  the firmware filters and we don't need a software hysteresis

The solution isn't perfect, but that's the best heuristic we have so far. And it beats having a config option through 3 layers of stack that users have to enable or disable manually. And then me having to handle bugs because of broken configuration files 3 years down the track.

I mostly agree, and was already aware of the 3 layers of stack issue. This is certainly worth the effort before resorting to that.

If a config option was to ever be created though, we might want to present it at the top layer as "Sensitivity" so users could understand what they're changing. Below that the hysteresis would be the inverse of the sensitivity value.

Peter, can we assume the patch from comment #77 will land?

I'm trying to get an idea of everything to backport.

commit f5a9e38c90380741adaf3ae38642d30f7564e922
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Jan 8 10:39:48 2018 +1000

    touchpad: don't disable the hysteresis unless a finger is down


I planned to do 1.10rc1 this week, but it got pushed back and I generally try to avoid releasing stuff on a Friday :) Expect the rc1 on Monday

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

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

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

after using 1.10.0 for a while  I can say that it behaves a bit differently but certainly it is not better than 1.9 , small objects and text are very difficult to select and click as the mouse still jumps when I make small movements on Lenovo P50

do you need anymore info to find the culprit?

Krasi,

Most touchpad bugs are model-specific. Please log your own new bug along with an evemu recording of you holding your finger still.

thanks, I already did a while back and it was marked as duplicate of this one.
https://bugs.freedesktop.org/show_bug.cgi?id=105022

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

https://lists.freedesktop.org/archives/wayland-devel/2018-April/038025.html

Excellent, thanks.

I had actually forgotten to report that hysteresis was breaking the X1 Carbon G5 again...

For the record, the patches in Comment 99 change things around again. First version was to disable the hysteresis after a series of events that looks like the touchpad is reliable. That didn't work, because touchpads are terrible.

Second version (current in git master) changed to enable the hysteresis if wobble is detected. That didn't work but it's unclear if that's a bug, patches 1-3 of the patchset may eliminate that issue. Nate, can you please test this?

Third version, i.e. comment #99 now simply doesn't touch the hysteresis and the wobble detection merely warns the user that something is up. We then have to add a device-specific hwdb entry to set the fuzz for the value the device needs and libinput can pick it up on the next run. I'd rather avoid this because it's reasonably insane, so it mostly depends on whether patches 1-3 are enough.

Patches 1-3 in that patch series seem to do the trick for me. I haven't had Hysteresis inappropriately turn on.

FWIW, I definitely read "aydunno" in a Homer Simpson voice.

Closing again based on comment 102, git commit is 49a8bd3ca76d11b1ec604df741f5c4fdccf0b9d3 which merges patches 1-3. Thanks for testing!

Thanks for implementing! It's working flawlessly for me.