Description of problem: In the new update to the synaptics driver, version 1.7.6, the cursor no longer jumps slightly when you click with one finger (or especially with the side of your thumb, as reported in bug 816391). However, the cursor still jumps a huge distance from 30-80% (i.e. randomly, but quite frequently) when two fingers are down and the second finger is used to click. For example, if I am using my index finger to move the cursor, and leave my index finger down then use my thumb to click, the cursor often instantly jumps a distance of half the screen height downwards. (Occasionally it jumps half the screen height upwards.) Since the latest synaptics driver isn't configured for tap-to-click by default, this behavior is problematic, because the user frequently has to click with a second finger while having the first finger down. It's made even worse because the click event is registered *after* the cursor jumps down, not before, so you end up clicking on random stuff. I'm on a Dell XPS 15 Touch (2014 model). Version-Release number of selected component (if applicable): xorg-x11-drv-synaptics-1.7.6-2.fc20.x86_64 How reproducible: 30-80% Steps to Reproduce: 1. Move cursor with index finger; keep index finger down 2. Click near bottom of trackpad with thumb Actual results: Expected results: Additional info:
Sorry about the delay. Can you record the touchpad's events when this happens. I tried to reproduce this here on a T440 but to no avail. http://www.freedesktop.org/wiki/Evemu/ has the instructions
Created attachment 934659 [details] Synaptics evemu recordings x4 I can capture more of these if you need more examples...
No worries, thanks for looking into this. Attached four recordings above, captured with evemu. In all cases, the jump happened in the last second or so before ending the recording.
The event0 sequence has the problem of the first finger lifting in the same EV_SYN frame as the second finger coming down. The synaptics driver doesn't handle that well, it sees the ABS_X/Y jumping and before/after the EV_SYN there is one single finger down. So it simply doesn't see that there is a changeover. I've put a hack into a scratch package for now, let me know how you go with that. I haven't looked at the other files you attached, could be that it's always the same problem, could be it's different. But it's Friday evening here and I've been at work for too long :) http://koji.fedoraproject.org/koji/taskinfo?taskID=7528275
Thanks for working on this on a Friday evening :-) I tried the package you sent, but it does not fix the problem. I found a reliable easy way to duplicate this problem, by placing two fingers on the pad and then quickly alternately raising one finger while lowering the other and then vice versa.
so much for Friday evening work... I added the patch but forgot to apply it so the package you tested didn't have any changes. sorry about that. New build with the patch applied this time: http://koji.fedoraproject.org/koji/taskinfo?taskID=7549996
Created attachment 935563 [details] Latest evemu event recording No worries :-) I installed the latest driver, and it still manifests the issue. I'm attaching an evemu trace where the issue is replicated about 8x, every 2 seconds or so.
for next time, please submit the shortest recording possible. It's hard to figure out what events cause a jump in a 8500 line file... :) Identified just before the 5 second mark. E: 4.751846 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 4.761920 0003 0035 4481 # EV_ABS / ABS_MT_POSITION_X 4481 E: 4.761920 0003 0036 1839 # EV_ABS / ABS_MT_POSITION_Y 1839 E: 4.761920 0003 003a 0046 # EV_ABS / ABS_MT_PRESSURE 46 E: 4.761920 0003 0000 4481 # EV_ABS / ABS_X 4481 E: 4.761920 0003 0001 1839 # EV_ABS / ABS_Y 1839 E: 4.761920 0003 0018 0046 # EV_ABS / ABS_PRESSURE 46 E: 4.761920 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 4.772052 0003 0035 3276 # EV_ABS / ABS_MT_POSITION_X 3276 E: 4.772052 0003 0036 4121 # EV_ABS / ABS_MT_POSITION_Y 4121 E: 4.772052 0003 003a 0071 # EV_ABS / ABS_MT_PRESSURE 71 E: 4.772052 0003 0000 3276 # EV_ABS / ABS_X 3276 E: 4.772052 0003 0001 4121 # EV_ABS / ABS_Y 4121 E: 4.772052 0003 0018 0071 # EV_ABS / ABS_PRESSURE 71 E: 4.772052 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- These are two consecutive events in the same slot, which indicates that you've swapped fingers faster than the sampling rate. Hence the massive jump. Need to figure out how to deal with this
Hi, (In reply to Peter Hutterer from comment #8) > for next time, please submit the shortest recording possible. It's hard to > figure out what events cause a jump in a 8500 line file... :) > > Identified just before the 5 second mark. > > E: 4.751846 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- > E: 4.761920 0003 0035 4481 # EV_ABS / ABS_MT_POSITION_X 4481 > E: 4.761920 0003 0036 1839 # EV_ABS / ABS_MT_POSITION_Y 1839 > E: 4.761920 0003 003a 0046 # EV_ABS / ABS_MT_PRESSURE 46 > E: 4.761920 0003 0000 4481 # EV_ABS / ABS_X 4481 > E: 4.761920 0003 0001 1839 # EV_ABS / ABS_Y 1839 > E: 4.761920 0003 0018 0046 # EV_ABS / ABS_PRESSURE 46 > E: 4.761920 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- > E: 4.772052 0003 0035 3276 # EV_ABS / ABS_MT_POSITION_X 3276 > E: 4.772052 0003 0036 4121 # EV_ABS / ABS_MT_POSITION_Y 4121 > E: 4.772052 0003 003a 0071 # EV_ABS / ABS_MT_PRESSURE 71 > E: 4.772052 0003 0000 3276 # EV_ABS / ABS_X 3276 > E: 4.772052 0003 0001 4121 # EV_ABS / ABS_Y 4121 > E: 4.772052 0003 0018 0071 # EV_ABS / ABS_PRESSURE 71 > E: 4.772052 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- > > These are two consecutive events in the same slot, which indicates that > you've swapped fingers faster than the sampling rate. Hence the massive > jump. Need to figure out how to deal with this Note I sometimes see this on the T440s too. I think we should not try to be too smart here. For normal finger movement we should simply never see such a huge jump in coordinates, so my vote goes to the KISS solution which was already discussed on xorg-devel. Simply detect moves > xx% of the touchpad diagonal, and in that case treat it as a finger up in old location + finger down in new location.
Sorry for the long recording! The Chrome OS touchpad driver does not manifest this issue, I believe because its library libgestures filters for sudden large jumps among other issues. Peter, you said previously you were looking at libgestures for libinput? libgestures has a bunch of options such as "Drumroll suppression enable", "Suppress immediate tapdown", "Quick move distance thresh" etc. that seem designed to filter event issues like this. https://github.com/hugegreenbug/libgestures/blob/master/src/lookahead_filter_interpreter.cc Maybe Hans is right about not trying to be too smart though. I'm happy to test again with a simple "max instantaneous move" threshold. While I have your attention too, why is tap-to-click not enabled by default in the synaptics driver these days? It's a bit of a hassle to have to set up an Xorg config file to enable this option.
(In reply to Luke Hutchison from comment #10) > Sorry for the long recording! The Chrome OS touchpad driver does not > manifest this issue, I believe because its library libgestures filters for > sudden large jumps among other issues. Peter, you said previously you were > looking at libgestures for libinput? libgestures has a bunch of options such > as "Drumroll suppression enable", "Suppress immediate tapdown", "Quick move > distance thresh" etc. that seem designed to filter event issues like this. > > https://github.com/hugegreenbug/libgestures/blob/master/src/ > lookahead_filter_interpreter.cc > > Maybe Hans is right about not trying to be too smart though. I'm happy to > test again with a simple "max instantaneous move" threshold. yeah, build coming up in a second. > While I have your attention too, why is tap-to-click not enabled by default > in the synaptics driver these days? It's a bit of a hassle to have to set up > an Xorg config file to enable this option. explanation for libinput, synaptics has the same reasoning: http://cgit.freedesktop.org/wayland/libinput/commit/?id=2219c12c3aa45b80f235e761e87c17fb9ec70eae
xorg-x11-drv-synaptics-1.7.6-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.7.6-6.fc20
F20 has the simple patch here only, upstream patch is here: http://patchwork.freedesktop.org/patch/33519/
I confirm this fixes the issue for me when the touchpoints are far enough apart. (Personally I would make the distance a little less than 1/4 of the diagonal size of the touchpad, maybe even 1/8th, but then again I have a somewhat large touchpad on my laptop.) Thanks for your work on this, Peter!
The proper patch has a 20mm limit on devices with resolution and thus won't be affected by the angle of the movement either. The 1/4 is only the fallback for devices without resolution but looking at your recording your device will use the 20mm. Thanks for the test report, make sure you leave karma so the update gets into stable soon. I'll push it out for F21+ as well then.
Karma left, thanks!
xorg-x11-drv-synaptics-1.8.0-9.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.8.0-9.fc21
Package xorg-x11-drv-synaptics-1.7.6-6.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-synaptics-1.7.6-6.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11005/xorg-x11-drv-synaptics-1.7.6-6.fc20 then log in and leave karma (feedback).
xorg-x11-drv-synaptics-1.7.6-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
xorg-x11-drv-synaptics-1.8.0-9.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Peter, I just installed the latest Fedora 20 updates (including xorg-x11-drv-synaptics-1.7.6-6.fc20) on another laptop of the same make and model, and rebooted, and the problem is still there. Did the patch somehow not make it into the 1.7.6-6.fc20 build?
PS on the laptop with your patched version, it's still quite easy to trigger the jumping behavior, although the cursor only jumps 2-3 inches on the screen, not half the height of the screen or more, and it only happens maybe half as often, because your fingers have to be closer together to trigger it. I suggest reducing the maximum jump distance to half its current value. That still should be a big enough jump that it doesn't interfere with fast pointer movement.
sorry for the delay, I was travelling. So the problem here is that the patch is only a stopgap fix. the real fix for this is in the kernel but not ready yet (Benjamin is in CC). on devices with resolution (yours is one) the move limit is 20mm. that value is just above what's easily reached by normal movement. if we reduce this we will drop fast movements which is worse than the current cursor jumps. double-checked the spec file, patch is definitely applied when building.
Hi Peter, this is still broken on xorg-x11-drv-synaptics-1.8.1-2.fc21.x86_64. The test build you posted more or less solved the problem (albeit with a max distance threshold that I think was a little too big), but no update release since then has behaved any differently than the orginal broken driver pre-1.7.6. My laptop's touchpad is still just as maddeningly broken on the latest update as it was before I opened this bug report.
Incidentally, I just tried installing xorg-x11-drv-libinput, and it does resolve about 75% of the pointer jumping issues, but it's still quite easy to trigger the behavior (so switching to libinput is not a complete fix).
Strange, I tried a fresh Fedora install on the same machine, and the latest synaptics driver works as intended (fixing the jumping cursor unless your finger and thumb are less than a couple of cm apart). There must have been some screwy configuration on my machine or something. Sorry for the false alarm.