Hi there, I have recently switched my X.Org configuration to use the libinput driver by simply uninstalling the synaptics driver package. I hope I file this bug report against the correct package, though. What I want to report is the following issue which has never been a problem with the old synaptics driver: I am used to highlight longer sentences by double-clicking on the first word (in order to highlight it) and then drag the highlighting to the right across the other words in the sentence in order to extend the highlighting on them. However, since I have switched the drivers this doesn't work anymore as intended. Instead, the mouse cursor appears to be frozen once the first word has been highlighted by me double-clicking on it. Please note that I am using my touchpad here (not my mouse) and that I am highlighting the first word using the hardware buttons (not tapping) and then attempt to drag the highlighting across the other words by moving another finger across the touchpad without releasing the left hardware button. I hope this all makes sense to you. Thank you! - Fabian
$ 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
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.