Bug 99402

$ dpkg -l \*libinput\* | awk '/^ii/ {print $2" "$3}'
libinput-bin 1.5.3-1
libinput10:amd64 1.5.3-1
xserver-xorg-input-libinput 0.23.0-1

yep, right component, at least for now ;)

just to verify: you have separate physical hardware buttons? not a clickpad where you have to press the actual touchpad down?

run sudo libinput-debug-events and see what that spits out when you do that (it's independent of the gui). I suspect if the cursor stays in place you may be triggering horizontal scrolling, in which case I need to know which click method you have enabled.
https://wayland.freedesktop.org/libinput/doc/latest/clickpad_softbuttons.html

Yes, it's a touchpad and two separate hardware buttons. I am not reporting about a "clickpad" here.

This is the output of libinput-debug-events:

sudo libinput-debug-events
-event4 	DEVICE_ADDED     Power Button                      seat0 default group1 cap:k
-event8 	DEVICE_ADDED     Fujitsu FUJ02E3                   seat0 default group2 cap:k
-event9 	DEVICE_ADDED     Video Bus                         seat0 default group3 cap:k
-event2 	DEVICE_ADDED     Power Button                      seat0 default group4 cap:k
-event10	DEVICE_ADDED     FJ Camera                         seat0 default group5 cap:k
-event0 	DEVICE_ADDED     AT Translated Set 2 keyboard      seat0 default group6 cap:k
-event1 	DEVICE_ADDED     AlpsPS/2 ALPS GlidePoint          seat0 default group7 cap:pg	size 101.33/53.33mm tap(dl off) left scroll-nat scroll-2fg-edge dwt-on
 event1 	POINTER_BUTTON    +3.49s	BTN_LEFT (272) pressed, seat count: 1
 event1 	POINTER_BUTTON    +3.55s	BTN_LEFT (272) released, seat count: 0
 event1 	POINTER_BUTTON    +3.65s	BTN_LEFT (272) pressed, seat count: 1
libinput error: kernel bug: Touch jump detected and discarded.
See https://wayland.freedesktop.org/libinput/doc/1.5.3/touchpad_jumping_cursor.html for details
 event1 	POINTER_BUTTON    +6.04s	BTN_LEFT (272) released, seat count: 0

that warning shouldn't be there, something odd is going on here. Can you attach an evemu-record sequence of such an interaction that triggers the bug?

Created attachment 129004 [details]
evemu-record sequence of an interaction that triggers the bug

huh, this looks quite wrong. To confirm, please attach event sequences of the following actions (one sequence each):
* double-tap without any button press
* finger down, leave finger on touchpad and press+release button, then release finger
* tap, button click, tap

Created attachment 129033 [details]
double-tap without any button press

Created attachment 129034 [details]
finger down, leave finger on touchpad and press+release button, then release finger

Created attachment 129035 [details]
tap, button click, tap

the double-tap and the down/leave/click/release are normal, but the tap/click/tap one is strange:

E: 0.138031 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 0.138031 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
E: 0.138031 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 0.138031 0003 0018 0000      # EV_ABS / ABS_PRESSURE         0
E: 0.138031 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 0.352500 0003 0039 3333      # EV_ABS / ABS_MT_TRACKING_ID   3333
E: 0.352500 0003 0035 0000      # EV_ABS / ABS_MT_POSITION_X    0
E: 0.352500 0003 0036 0000      # EV_ABS / ABS_MT_POSITION_Y    0
E: 0.352500 0001 014a 0001      # EV_KEY / BTN_TOUCH            1
E: 0.352500 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 0.352500 0003 0000 0000      # EV_ABS / ABS_X                0
E: 0.352500 0003 0001 0000      # EV_ABS / ABS_Y                0
E: 0.352500 0001 0110 0001      # EV_KEY / BTN_LEFT             1
E: 0.352500 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 0.491364 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 0.491364 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
E: 0.491364 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 0.491364 0001 0110 0000      # EV_KEY / BTN_LEFT             0
E: 0.491364 0000 0000 0000      # ------------ SYN_REPORT (0) ----------
E: 0.656561 0003 0039 3334      # EV_ABS / ABS_MT_TRACKING_ID   3334
E: 0.656561 0003 0035 2350      # EV_ABS / ABS_MT_POSITION_X    2350
E: 0.656561 0003 0036 1399      # EV_ABS / ABS_MT_POSITION_Y    1399
E: 0.656561 0001 014a 0001      # EV_KEY / BTN_TOUCH            1
E: 0.656561 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 0.656561 0003 0000 2350      # EV_ABS / ABS_X                2350
E: 0.656561 0003 0001 1399      # EV_ABS / ABS_Y                1399
E: 0.656561 0003 0018 0030      # EV_ABS / ABS_PRESSURE         30
E: 0.656561 0000 0000 0000      # ------------ SYN_REPORT (0) ----------

Interpretation:
0.138031: finger up (from the tap)
0.352500: finger down at position 0, left button down
0.491364: finger up, left button up
0.656561: finger down at position 2350/1399

Normally, a button event should just be BTN_LEFT followed by a SYN_REPORT.

Do you always get the ABS_MT events during button events? This looks like a hardware issue (possibly a protocol issue) and would require some custom handling in libinput. Re-run evemu-record again and click the button, see if you can spot a pattern. That should help figure out what actual fix we need to put in here.

Created attachment 129079 [details]
tap, click, tap: take 2

> but the tap/click/tap one is strange:

Maybe I did something wrong, so I re-recorded this sequence

Created attachment 129080 [details]
5 clicks

> Re-run evemu-record again and click the button, see if you can spot a pattern. That should help figure out what actual fix we need to put in here.

Yes, I can spot a pattern. I have attached the output of 5 clicks of the left button and the ABS_MT_TRACKING_ID is alternating between -1 and a counter that gets increased by 1. But that's probably expected and not what you meant?

there's a long explanation of evdev here:
http://who-t.blogspot.com.au/2016/09/understanding-evdev.html

but for this bug the summary is: BTN_LEFT is your physical button, values 1/0 are press/release. ABS_MT_TRACKING_ID is a sequential number identifying a touchpoint, so a value N means "new touch starting with sequence N", a value -1 means "touch ending". The BTN_TOOL_FINGER bit has effectively the same meaning.

In your case, you can see that every time the button is pressed, you get a new touchpoint starting. When you release the button, you get the touch released. That would be normal behaviour on a clickpad but not on a touchpad with separate physical buttons.

I can't verify the coordinates because you filtered them, but in the recording above they were 0/0, effectively an invalid touch. Notably though, this doesn't happen every time, the down/leave/click sequence didn't have this issue. If the 5 clicks here were just a normal click without any finger down, then it appears to only happen whenever *no* finger is down on the touchpad.

If so, that's something we can hook onto. Can you verify please that:
* if you have a finger down on the touchpad and you click, you only get the BTN_LEFT events but no ABS_MT_TRACKING_ID or BTN_TOOL_FINGER 
* if you have no fingers down, you always get the tracking id/finger events on button press release

And finally: what's the event sequence when you press a button and hold it down, then put a finger on the touchpad and release the button, then release the finger.

(please don't gzip the attachment it requires 5 more clicks to view)

Created attachment 129112 [details]
finger down on the touchpad, 10 clicks, finger up

Created attachment 129113 [details]
press button, tap finger on touchpad, release button, release finger from touchpad

> If the 5 clicks here were just a normal click without any finger down, then it appears to only happen whenever *no* finger is down on the touchpad.

Yes, the 5 clicks were normal clicks without any finger down on the touchpad.

> * if you have a finger down on the touchpad and you click, you only get the BTN_LEFT events but no ABS_MT_TRACKING_ID or BTN_TOOL_FINGER 

Yes, I think so. I have recorded this in the event1_tap-down-10-click-tap-up sequence.

> * if you have no fingers down, you always get the tracking id/finger events on button press release

I have recorded this in the event1_10-click sequence.

> And finally: what's the event sequence when you press a button and hold it down, then put a finger on the touchpad and release the button, then release the finger.

I have recorded this in the event1_button-down-tap-down-button-up-tap-up sequence.

> (please don't gzip the attachment it requires 5 more clicks to view)

Sorry, I have misread the file size limit to be 32kB, whereas it actually is 32MB. I was a bit astonished, but then realized I could circumvent it by gzipping. ;)

Created attachment 129114 [details]
10 clicks without any finger on the touchpad

Summary from the event recordings:
* while a finger is already down, BTN_LEFT events are normal
* while no finger is down, a BTN_LEFT creates a touch at 0/0 and releases that touch on release
* a fake touch created by BTN_LEFT will jump to the coordinates of the finger when a finger is set down after the button event. the button release will not affect the touch

One more case we need to know please: what happens on finger down, button down, finger up, button up?

The good news here: this is detectable and can be worked around with a device-specific quirk. The bad news is that the code for this is going to be nasty.
Benjamin, is this something we can fix in the kernel instead?

Created attachment 129147 [details]
finger down, button down, finger up, button up

Thanks, that confirms the behaviour, putting the summary in again so we have it all in one spot:


Summary from the event recordings (v2):
* while a finger is already down, BTN_LEFT events are normal
* while no finger is down, a BTN_LEFT creates a touch at 0/0 and releases that touch on release
* a fake touch created by BTN_LEFT will jump to the coordinates of the finger when a finger is set down after the button event. the button release will not affect the touch
* when a button is down on finger up, the touch will jump to 0/0, releasing the button terminates the touchpoint

Please also confirm which kernel you are running. There is a fix in v4.9 which looks exactly what you are seeing (a831776323e7c).

So please try upgrade to a v4.9 if you are using an older kernel, and if you already are, please provide a dmesg.

I am currently using this kernel:
 uname -a
Linux dude 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux


Will upgrade to 4.9 and try again...

I have just booted this kernel

 uname -a
Linux dude 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux

and now I can confirm that everything seems to be fine and behave as expected.

Sorry, Peter, for spending two weeks of effort on an issue that has already been resolved. Thank you very much for your patience!

no problem. glad it's fixed now with kernel v4.9