Hi, Running Ubuntu 18.04 (dev) and libinput 1.9.4-2ubuntu1 on a Dell Precision 7510. Since the patch applied in Ubuntu ( https://bugs.launchpad.net/ubuntu/+source/libinput/+bug/1696929 ) from 1.9.4-2 version, my touchpad is jumpy. Pointing is jumpy when I need some precision (row size setting, e.g.), pointer is jumpy (very small jumps) when I keep my finger at the same place. Two-fingers scrolling is jumpy as well. Daniel van Vugt says in LP bug report : "The patch in 1.9.4-2ubuntu1 is the same as what's coming soon in libinput release 1.10. So a fix for your specific touchpad should be done upstream. Simply reverting the patch won't help you after we update to libinput 1.10, and besides most laptops seem to need that patch." https://bugs.launchpad.net/ubuntu/+source/libinput/+bug/1745816
I'll need an evemu recording of the issue please, thanks.
Note that version 1.9.4-2ubuntu1 is just 1.9.4-2 with the fix for bug 98839 added.
Created attachment 137105 [details] evemu record Dell 7510
Here is my evemu record (Dell Precision 7510). I experience the same bug running a SynPS/2 Synaptics touchpad of a HP 450 G3 laptop. Very noticeable when scrolling a Evince PDF (two fingers) on both Dell & HP.
fthx says he is also using tap-to-click. Is it possible some fast and precise tapping could trick libinput into turning off hysteresis?
no the touchpad is just terrible. it wobbles along for ages, then has one event frame that is delayed by enough to turn off the hysteresis. Looks like we need something smarter than our current approach. E: 2.892148 0003 0035 2918 # EV_ABS / ABS_MT_POSITION_X 2918 E: 2.892148 0003 0000 2918 # EV_ABS / ABS_X 2918 E: 2.892148 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +24ms E: 2.976840 0003 0035 2917 # EV_ABS / ABS_MT_POSITION_X 2917 E: 2.976840 0003 0000 2917 # EV_ABS / ABS_X 2917 E: 2.976840 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +84ms E: 2.988474 0003 0035 2918 # EV_ABS / ABS_MT_POSITION_X 2918 E: 2.988474 0003 0000 2918 # EV_ABS / ABS_X 2918 E: 2.988474 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms For the rest of the bug, please let's use the term "wobble" instead of "jump" to avoid confusion with real cursor jumps (>30 px or so)
My preferred verb for such 1-2px movements is "jitter" :)
*** Bug 104788 has been marked as a duplicate of this bug. ***
(In reply to Peter Hutterer from comment #6) > no the touchpad is just terrible. it wobbles along for ages, then has one > event frame that is delayed by enough to turn off the hysteresis. Looks like > we need something smarter than our current approach. How about reversing the approach: basically, waiting for some strokes, and if wobbling is detected, assume touchpad needs hysteresis. Otherwise disable it. I can imagine some modifications of this approach: for example, wait not a stroke, but until a person just keeps the finger still on the touchpad (e.g. tries to focus something), and then check if we see wobbling. Or, to exclude broken a broken touchpad missing a frame, use a bit more alike patterns, and see if at least one of them does wobble.
(In reply to Hi-Angel from comment #9) Hysteresis is disabled by default already. > until a person just keeps the finger still on the touchpad (e.g. > tries to focus something), and then check if we see wobbling. I think Peter probably considered that already and it sounds like that might be impossible. You can't ask the person "are you trying to keep your finger still?". You can only see what the touchpad reports, and the touchpad "wobbling" with a still finger looks the same as a non-wobbly touchpad with a wobbling finger :) From what I understand this is why the current approach does and must enable hysteresis first. And then disables it when it thinks there is no hardware "wobble". The only bug here is that the current approach is disabling hysteresis too soon by accident (only waiting for 80ms of stillness whereas it should be something like 100ms or a slightly different algorithm).
Correction: Hysteresis is *enabled* by default already.
Although to say anything is impossible is just asking to be proven wrong :) One way you could have hysteresis disabled by default is to try and tell the difference between hardware jitter and finger movement... If you see a lot of 1-2 unit movement that _cancels_itself_out_ (ie. goes up-down-up-down, or left-right-left-right) and has a small overall radius of movement then you could plausibly call that hardware jitter and decide to turn on hysteresis later.
Although the algorithm described in comment #12 is basically equivalent to always having hysteresis ON with just a smaller radius. Presently hysteresis feels like it's about 5mm, which I think might be the real bug. A math error somewhere (since it's meant to be half a millimetre).
(In reply to Daniel van Vugt from comment #10) > (In reply to Hi-Angel from comment #9) > > until a person just keeps the finger still on the touchpad (e.g. > > tries to focus something), and then check if we see wobbling. > > I think Peter probably considered that already and it sounds like that might > be impossible. You can't ask the person "are you trying to keep your finger > still?". You can only see what the touchpad reports, and the touchpad > "wobbling" with a still finger looks the same as a non-wobbly touchpad with > a wobbling finger :) libinput does have a detection code — otherwise how could it "remove" wobbling. Per my understanding it's detection of a bunch of micromovements — ones that very quick and very close. By "keeping finger still" I don't necessarily mean having it really still, I rather opposing it to a very quick stroke across the touchpad, which, I'm guessing, indeed might not wobble.
(In reply to Hi-Angel from comment #14) > libinput does have a detection code — otherwise how could it "remove" > wobbling. I think that's wrong. It doesn't detect wobbling. It _assumes_ from the beginning that the touchpad is wobbly and only turns off hysteresis later, after deciding that it's not wobbling. The wobble "removal" is the hysteresis algorithm, which is ON by default. The bug here is that the stillness detection algorithm has gone wrong and turned hysteresis OFF too early.
(In reply to Daniel van Vugt from comment #15) > (In reply to Hi-Angel from comment #14) > > > libinput does have a detection code — otherwise how could it "remove" > > wobbling. > > I think that's wrong. It doesn't detect wobbling. It _assumes_ from the > beginning that the touchpad is wobbly and only turns off hysteresis later, > after deciding that it's not wobbling. > > The wobble "removal" is the hysteresis algorithm, which is ON by default. > The bug here is that the stillness detection algorithm has gone wrong and > turned hysteresis OFF too early. Yeah, but the algorithm is the code of libinput that, basically, detects if there's any motion that gotta get cancelled :)
the algorighm is *really* simple right now - it sets a timer on the last motion event. If the timer expires without further motion events (and no finger up) we assume that there isn't any wobble. We don't even look at the motion events themselves. For small wobbles setting the fuzz on the axis would be sufficient (kernel takes care of that), but that also depends on the distance of the events. I haven't found the time to analyse this yet, stuck with other things.
(In reply to Peter Hutterer from comment #17) > the algorighm is *really* simple right now - it sets a timer on the last > motion event. If the timer expires without further motion events (and no > finger up) we assume that there isn't any wobble. We don't even look at the > motion events themselves. > > For small wobbles setting the fuzz on the axis would be sufficient (kernel > takes care of that), but that also depends on the distance of the events. I > haven't found the time to analyse this yet, stuck with other things. I've looked at hysteresis algo (i.e. evdev_hysteresis function) — I like how it's being so simple and CPU-nonintensive and yet so efficient. I think it's better to write a separate function specifically to check the presence of wobbling, but I admit the solution is unclear. I just wanted to document some points I found before going to sleep. 1. The wobbling detection in abstract vacuum is indeed easy: after a finger is down for 100ms, record all movement along X axis, then divide sum of movement to the left by sum of movement to the right. If the absolute value less-than-or-equal to 2, it wobbles. 2. This function should only be used when the finger is still, because per my experiments making a straight line with such a touchpad shows no sign of wobbling. Detecting a still finger, given a random touchpad can filter out the wobbling or not, is a question. 3. Before deciding to disable hysteresis (because the function didn't detect wobbling), this function should be run multiple times. Otherwise it's possible that upon running the check there was the frame loss which this bug is all about, thus the function would misdetect like there's no wobbling. And it can happen again and again. Then, how much should the check be ran to be sure hysteresis can be safely disabled.
I think I figured how to fix it. Let's keep hysteresis disabled from the beginning, and then every time a finger seems still, apply the simple algo from point "1" of the prev. comment. Do it 5 times in the row, and if at least one of them showed wobbling, enable hysteresis, otherwise assume FW filters. The "5 times" is to workaround possible frame losses. I think it is impossible to workaround the problem completely (well, not without paying unnecessary CPU load by peoples with good touchpads), but we can reduce the possibility of the losses' influence down to a neglectable minimum. I gonna check if I've got enough time & knowledge to try writing the code these holidays.
For walking around I've got even a better idea on the algorithm of wobbling detection per se. Let's just record 3 last motions, then if they're less than 20ms, and point different ways in a checkered manner — it does wobble, because no human can change direction 3 times that quickly.
Ok, I think I found a very nice way to encode the check with a binary array and a match for 101b pattern, and whole check now is just 3 comparisons and 4 assignments in the worst case, so we can keep it enabled not only "5 times for still finger". Question for Peter: how can I figure whether current movement is left or right? I initially was going to use the `t->point.x`, like, "if it's negative, then I probably move left" but then I figured it's probably some kind of absolute coordinates, so I'm not very sure what to use.
I'm also experiencing the wobbles on my Precision e5570 touchpad (also reported as an AlpsPS/2 ALPS Dualpoint touchpad). This is ever since libinput 1.10 was pushed into archlinux's repos. Previous versions had no wobble issues.
(In reply to Hi-Angel from comment #21) > Question for Peter: how can I figure whether current movement is left or > right? I initially was going to use the `t->point.x`, like, "if it's > negative, then I probably move left" but then I figured it's probably some > kind of absolute coordinates, so I'm not very sure what to use. FTR, I don't really know how to print `t->point.x` so I could look for myself if I can make anything useful of it. Or, rather, Idk where to look for the printed content. Probably somewhere in Xorg logs, but looking it's file descriptors under the /proc/, stdout is written to some pipe, stderr don't exist whatsoever, and Xorg.0.log is getting input from fourth fd, whatever that is. I dunno, doesn't sound like an interesting adventure, I'm going to rather wait for Peter's reply.
Ok, I sent the patchset to wayland-devel: https://lists.freedesktop.org/archives/wayland-devel/2018-February/037118.html Anyway, about the `t->point.x` — I still don't know how to see stderr prints, but I simply built'n'tested the patches on my laptop, and it works, which means "x" being exactly what I wanted it to be. Otherwise the function wouldn't enable hysteresis (unless there's a bug of course).
(In reply to Hi-Angel from comment #24) > Ok, I sent the patchset to wayland-devel: > https://lists.freedesktop.org/archives/wayland-devel/2018-February/037118. > html > > Anyway, about the `t->point.x` — I still don't know how to see stderr > prints, but I simply built'n'tested the patches on my laptop, and it works, > which means "x" being exactly what I wanted it to be. Otherwise the function > wouldn't enable hysteresis (unless there's a bug of course). Ah, I just figured that I do never match the left move in the code. It is correct in terms of the algorithm, but the side-effect is that hysteresis is enabled even if "x" is not what I expected. Speaking of which — "x" seems to never become negative. Oh well, I dunno, I'd rather ask Peter how to figure out the direction along X axis.
the xorg log shows up in the journal on most distros. but for development you should run libinput debug-events, because in your case you don't care about the exact pointer movement as such, but rather about whether pointer movement happens at all. so if you don't see POINTER_MOTION events float past when you hold your finger still, that means it's working. If you do, check the deltas. the libinput debug-gui will show the pointer motion as seen by libinput too. Both can be run in the build directory, much easier than install && restart x. Note that touchpads are *always* in absolute coordinates, the conversion to relative movement is handled in libinput. So t->point.x is the current position of the touch in device coordinates. See the mailing list for more comments.
*** Bug 105203 has been marked as a duplicate of this bug. ***
FWIW I just ran into this jitter issue after upgrading libinput from 1.8.2-1.fc27 to 1.10.0-2.fc27 (on Fedora 27). Currently working around it by rolling back to the earlier version and using 'dnf versionlock' to prevent it from getting upgraded. I also have some ideas for generally improving touchpad driver performance, but am not sure what forum to post them in, or whether there's any interest. Suggestions welcome.
fwiw, there is a github branch listed in bug 105108 that's worth testing. as for improvements: either file a bug here or an RFC (and patch if possible) to the wayland-devel lists.
(In reply to Peter Hutterer from comment #29) > fwiw, there is a github branch listed in bug 105108 that's worth testing. > > as for improvements: either file a bug here or an RFC (and patch if > possible) to the wayland-devel lists. FWIW I just tested the branch, and I do see sometimes cursor jitters. The wobbling is infrequent but have a big distance. I think it's because fuzz value both for x and y is "8", whereas ½resolution have been 24 for x, and 40 for y. So, now small wobbling is being filtered out, whereas the biggest value don't.
(In reply to Hi-Angel from comment #30) > (In reply to Peter Hutterer from comment #29) > > fwiw, there is a github branch listed in bug 105108 that's worth testing. > > > > as for improvements: either file a bug here or an RFC (and patch if > > possible) to the wayland-devel lists. > > > FWIW I just tested the branch, and I do see sometimes cursor jitters. The > wobbling is infrequent but have a big distance. > > I think it's because fuzz value both for x and y is "8", whereas > ½resolution have been 24 for x, and 40 for y. So, now small wobbling is > being filtered out, whereas the biggest value don't. Ok, I just commented out whole code section assigning fuzz values, and assigned instead ½resolution (which is x=24, y=40 for me), and although jitter disappeared, I see sometimes small cursor jumps. I think this is caused by some changes in hysteresis algo.
*** Bug 105242 has been marked as a duplicate of this bug. ***
Hi-Angel: revert the top commit of that branch (6ef587cc3de), that's the only one that has hysteresis algorithm changes. As usual, an evemu-record of the wobbles/jumps will go a long way towards explaining it.
Created attachment 137631 [details] wobble with the commit for hystersis to work across both axes (In reply to Peter Hutterer from comment #33) > Hi-Angel: revert the top commit of that branch (6ef587cc3de), that's the > only one that has hysteresis algorithm changes. > > As usual, an evemu-record of the wobbles/jumps will go a long way towards > explaining it. Indeed, reverting the last commit did fix wobbling! I did a evemu-record using the branch (including the last commit) for slowly moving a cursor along a line back and forth. I shall say, wobbling is fairly infrequent (at least as compared to no-hysteresis), but upon reverting the commit it doesn't exist whatsoever.
right, in that case what's likely is that we're hitting the issue noted in the commit message. would be useful to add some printfs to make sure though. if that's the case we'll have to throw out the idea of making the hysteresis apply across both axes at the same time. Or at least need someone with a better idea than my attempts so far.
commit 400aadd53ac00ca773533d14e231ba192f4141a9 Author: Konstantin Kharlamov <...> Date: Wed Feb 21 20:16:41 2018 +0300 touchpad: add wobbling detection I've pushed the patches for the wobble detection now, leaving out the patches that use the fuzz until we're sure about what to do with Bug 105303
FTR the fix for bug 105306 should improve the behaviour even further
My touchpad does still wooble. I tested only the Dell's one, I'll try the HP one.
(In reply to fthx from comment #38) > My touchpad does still wooble. > I tested only the Dell's one, I'll try the HP one. Do you see any output of command libinput debug-events --verbose | grep hyst for moving the cursor? Also, output of `sudo evemu-record` for trying to focus something with touchpad could be helpful.
~$ sudo libinput debug-events --verbose | grep hyst event8 - hysteresis disabled (after ~10 seconds and woobling)
E: 5.138171 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.150104 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.150104 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 5.150104 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.150104 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 5.150104 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.162990 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.162990 0003 0036 1198 # EV_ABS / ABS_MT_POSITION_Y 1198 E: 5.162990 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.162990 0003 0001 1198 # EV_ABS / ABS_Y 1198 E: 5.162990 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.186313 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.186313 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 5.186313 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.186313 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 5.186313 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +24ms E: 5.213962 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.213962 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.213962 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.213962 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.213962 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +27ms E: 5.222177 0003 0035 2153 # EV_ABS / ABS_MT_POSITION_X 2153 E: 5.222177 0003 0036 1198 # EV_ABS / ABS_MT_POSITION_Y 1198 E: 5.222177 0003 0000 2153 # EV_ABS / ABS_X 2153 E: 5.222177 0003 0001 1198 # EV_ABS / ABS_Y 1198 E: 5.222177 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +9ms E: 5.234838 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.234838 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.234838 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.246069 0003 0035 2156 # EV_ABS / ABS_MT_POSITION_X 2156 E: 5.246069 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.246069 0003 0000 2156 # EV_ABS / ABS_X 2156 E: 5.246069 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.246069 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.258278 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.258278 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.258278 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.270282 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 5.270282 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 5.270282 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.282005 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.282005 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.282005 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.294225 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.294225 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.294225 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.294225 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.294225 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.306646 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 5.306646 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 5.306646 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.318230 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.318230 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.318230 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.333424 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.333424 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.333424 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.333424 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.333424 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +15ms E: 5.342427 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.342427 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.342427 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +9ms E: 5.354787 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.354787 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.354787 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.366246 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.366246 0003 0036 1198 # EV_ABS / ABS_MT_POSITION_Y 1198 E: 5.366246 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.366246 0003 0001 1198 # EV_ABS / ABS_Y 1198 E: 5.366246 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.378037 0003 0035 2156 # EV_ABS / ABS_MT_POSITION_X 2156 E: 5.378037 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 5.378037 0003 0000 2156 # EV_ABS / ABS_X 2156 E: 5.378037 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 5.378037 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.450334 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 5.450334 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.450334 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 5.450334 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.450334 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +72ms E: 5.462058 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 5.462058 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 5.462058 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.498157 0003 0035 2156 # EV_ABS / ABS_MT_POSITION_X 2156 E: 5.498157 0003 0000 2156 # EV_ABS / ABS_X 2156 E: 5.498157 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +36ms E: 5.510170 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.510170 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.510170 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.522066 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.522066 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.522066 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.546177 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.546177 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.546177 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +24ms E: 5.558119 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.558119 0003 0036 1198 # EV_ABS / ABS_MT_POSITION_Y 1198 E: 5.558119 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.558119 0003 0001 1198 # EV_ABS / ABS_Y 1198 E: 5.558119 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.570904 0003 0035 2156 # EV_ABS / ABS_MT_POSITION_X 2156 E: 5.570904 0003 0000 2156 # EV_ABS / ABS_X 2156 E: 5.570904 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.582275 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 5.582275 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 5.582275 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.594025 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 5.594025 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.594025 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 5.594025 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.594025 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.630253 0003 0035 2155 # EV_ABS / ABS_MT_POSITION_X 2155 E: 5.630253 0003 0000 2155 # EV_ABS / ABS_X 2155 E: 5.630253 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +36ms E: 5.642106 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.642106 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 5.642106 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.642106 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 5.642106 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.654855 0003 0035 2156 # EV_ABS / ABS_MT_POSITION_X 2156 E: 5.654855 0003 0000 2156 # EV_ABS / ABS_X 2156 E: 5.654855 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.666361 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 5.666361 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 5.666361 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.702877 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 5.702877 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.702877 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 5.702877 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.702877 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +36ms E: 5.750874 0003 0035 2156 # EV_ABS / ABS_MT_POSITION_X 2156 E: 5.750874 0003 0000 2156 # EV_ABS / ABS_X 2156 E: 5.750874 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +48ms E: 5.810851 0003 0035 2154 # EV_ABS / ABS_MT_POSITION_X 2154 E: 5.810851 0003 0000 2154 # EV_ABS / ABS_X 2154 E: 5.810851 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +60ms E: 5.822236 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 5.822236 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 5.822236 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 5.822236 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 5.822236 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 5.835635 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 5.835635 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 5.835635 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +13ms E: 6.014101 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.014101 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.014101 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +179ms E: 6.026144 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.026144 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.026144 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.039207 0003 0036 1199 # EV_ABS / ABS_MT_POSITION_Y 1199 E: 6.039207 0003 0001 1199 # EV_ABS / ABS_Y 1199 E: 6.039207 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +13ms E: 6.050472 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.050472 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 6.050472 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.050472 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 6.050472 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +11ms E: 6.062302 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.062302 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.062302 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.170870 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.170870 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.170870 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +108ms E: 6.187617 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.187617 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.187617 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +17ms E: 6.230478 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.230478 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.230478 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +43ms E: 6.242378 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.242378 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.242378 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.314639 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.314639 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.314639 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +72ms E: 6.326212 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.326212 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.326212 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.350809 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.350809 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.350809 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +24ms E: 6.362430 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.362430 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.362430 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.374282 0003 0036 1201 # EV_ABS / ABS_MT_POSITION_Y 1201 E: 6.374282 0003 0001 1201 # EV_ABS / ABS_Y 1201 E: 6.374282 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.386727 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.386727 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 6.386727 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.386727 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 6.386727 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.398381 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.398381 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.398381 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.446663 0003 0036 1201 # EV_ABS / ABS_MT_POSITION_Y 1201 E: 6.446663 0003 0001 1201 # EV_ABS / ABS_Y 1201 E: 6.446663 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +48ms E: 6.458388 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 6.458388 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 6.458388 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.482549 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.482549 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.482549 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +24ms E: 6.494297 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.494297 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.494297 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +12ms E: 6.566677 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.566677 0003 0036 1201 # EV_ABS / ABS_MT_POSITION_Y 1201 E: 6.566677 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.566677 0003 0001 1201 # EV_ABS / ABS_Y 1201 E: 6.566677 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +72ms E: 6.579200 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.579200 0003 0036 1200 # EV_ABS / ABS_MT_POSITION_Y 1200 E: 6.579200 0003 0000 2157 # EV_ABS / ABS_X 2157 E: 6.579200 0003 0001 1200 # EV_ABS / ABS_Y 1200 E: 6.579200 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +13ms E: 6.638659 0003 0035 2158 # EV_ABS / ABS_MT_POSITION_X 2158 E: 6.638659 0003 0000 2158 # EV_ABS / ABS_X 2158 E: 6.638659 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +59ms E: 6.650185 0003 0035 2157 # EV_ABS / ABS_MT_POSITION_X 2157 E: 6.650185 0003 0000 2157 # EV_ABS / ABS_X 2157
(In reply to fthx from comment #40) > ~$ sudo libinput debug-events --verbose | grep hyst > > event8 - hysteresis disabled That "disabled" means you don't have the latest libinput (i.e. unreleased one, from here https://cgit.freedesktop.org/wayland/libinput/). The algorithm been changed to have it disabled by default, then to enable if wobbling detected. > (after ~10 seconds and woobling) Yeah, right, the command created, like, a distinct and clean session, that had hysteresis enabled for 10 seconds. However XServer runs another session which already have hysteresis disabled, and those two session doesn't influence each another in any way, that's why you saw cursor been wobbling even before "disabled" popped up.
I reopened it since : https://bugs.launchpad.net/ubuntu/+source/libinput/+bug/1745816/comments/12 https://bugs.launchpad.net/ubuntu/+source/libinput/+bug/1745816/comments/14
Closed as latest git do not show any cursor woobling.
*** Bug 105383 has been marked as a duplicate of this bug. ***
It should be noted that this code enables hysteresis on my ThinkPad (T25) which previously didn't require any, making the touchpad unusable again. :-( Shall I open a new bug and attach what? libinput debug-events/evemu-record?
(In reply to Tomas Janousek from comment #46) > It should be noted that this code enables hysteresis on my ThinkPad (T25) > which previously didn't require any, making the touchpad unusable again. :-( > > Shall I open a new bug and attach what? libinput debug-events/evemu-record? See also Bug 105472. For me, it turned itself off again after a little bit. If that doesn't happen for you, it's probably worth a new bug.
(In reply to Nate Graham from comment #47) > See also Bug 105472. For me, it turned itself off again after a little bit. > If that doesn't happen for you, it's probably worth a new bug. But there's no code that turns back on, at least not in 1.10.3. Maybe it does if you suspend/resume or something, not sure about that. Anyway, I managed to activate it reliably without doing small circles, so I guess I'll revert my revert temporarily and attach logs... :-/
(In reply to Tomas Janousek from comment #46) > It should be noted that this code enables hysteresis on my ThinkPad (T25) > which previously didn't require any, making the touchpad unusable again. :-( > > Shall I open a new bug and attach what? libinput debug-events/evemu-record? Tomas, that should probably be discussed in a new bug. Although I think you can probably read my bug 105675 to find the answer you want.
(In reply to Tomas Janousek from comment #46) > It should be noted that this code enables hysteresis on my ThinkPad (T25) > which previously didn't require any, making the touchpad unusable again. :-( > > Shall I open a new bug and attach what? libinput debug-events/evemu-record? Generally, it'd be interesting to see the output of "libinput debug-events --verbose" around the note about hysteresis being enabled. Unfortunately I'm a bit lost about how the code have evolved since last time I looked, and with the (old) git version I'm using (582e3c00) the note about hysteresis being enabled appears within the informational header, before I touch the touchpad, and not within the timecodes. Unless piped to grep — in which case it works differently, and only appears after touching the touchpad. So I'm personally lost a bit about how it all behaves ATM.
It hasn't actually changed that much. The only changes since your patches affect how the hysteresis works but not how it's enabled (well, and the fix from 5883ac7d98614e735e44767f3fef0e2ca03ad1ee). It's now enabled if the fuzz is nonzero and the size of the hysteresis is smaller than before. > Unless piped to grep maybe some terminal buffering issue? try running through 'unbuffer'. Anyway, Thomas, a new bug please, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.