touchpad can move mouse but left and right buttons do not work tapping and scrolling also works libinput debug-events does not register button press rolling back to kernel version 17.4 as workaround does bring buttons back to life "xinput list" gives "ELAN1200:00 04F3:301A Touchpad" as touchpad device
by "17.4" i mean kernel version 4.17.14, apologies
4.18.4 kernel fixes left mouse button but right button still not working. libinput debug-events does not show any output on right mouse button press
snippet from evtest /dev/input/event8 upon right mouse button press. Event: time 1535130189.604195, -------------- SYN_REPORT ------------ Event: time 1535130189.611163, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 2532 Event: time 1535130189.611163, type 3 (EV_ABS), code 0 (ABS_X), value 2532 Event: time 1535130189.611163, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1476000 Event: time 1535130189.611163, -------------- SYN_REPORT ------------ Event: time 1535130189.618545, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1483000 Event: time 1535130189.618545, -------------- SYN_REPORT ------------ Event: time 1535130189.625897, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1490000 Event: time 1535130189.625897, -------------- SYN_REPORT ------------ Event: time 1535130189.632832, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1498000 Event: time 1535130189.632832, -------------- SYN_REPORT ------------ Event: time 1535130189.640335, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1504000 Event: time 1535130189.640335, -------------- SYN_REPORT ------------ Event: time 1535130189.647508, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1511000 Event: time 1535130189.647508, -------------- SYN_REPORT ------------ Event: time 1535130189.654953, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1518000 Event: time 1535130189.654953, -------------- SYN_REPORT ------------ Event: time 1535130189.661758, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1525000 Event: time 1535130189.661758, -------------- SYN_REPORT ------------ Event: time 1535130189.668951, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1532000 Event: time 1535130189.668951, -------------- SYN_REPORT ------------ Event: time 1535130189.676444, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 2034 Event: time 1535130189.676444, type 3 (EV_ABS), code 1 (ABS_Y), value 2034 Event: time 1535130189.676444, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1539000 Event: time 1535130189.676444, -------------- SYN_REPORT ------------ Event: time 1535130189.683523, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 2531 Event: time 1535130189.683523, type 3 (EV_ABS), code 0 (ABS_X), value 2531 Event: time 1535130189.683523, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1546000 Event: time 1535130189.683523, -------------- SYN_REPORT ------------ Event: time 1535130189.690431, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1553000 Event: time 1535130189.690431, -------------- SYN_REPORT ------------ Event: time 1535130189.697408, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1560000 Event: time 1535130189.697408, -------------- SYN_REPORT ------------ Event: time 1535130189.704718, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 2530 Event: time 1535130189.704718, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 2035 Event: time 1535130189.704718, type 3 (EV_ABS), code 0 (ABS_X), value 2530 Event: time 1535130189.704718, type 3 (EV_ABS), code 1 (ABS_Y), value 2035 Event: time 1535130189.704718, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1567000 Event: time 1535130189.704718, -------------- SYN_REPORT ------------ Event: time 1535130189.711527, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1 Event: time 1535130189.711527, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0 Event: time 1535130189.711527, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0 Event: time 1535130189.711527, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 1574000 Event: time 1535130189.711527, -------------- SYN_REPORT ------------
Could you attach the report descriptors and some events from the device? A simple way to do that is to use hid-record[1] as root. When you say "register buttons", according to google images, your touchpad is entirely depressible. It doesn't seem to have physical separate buttons. Correct? If I am not wrong, the left/right buttons will be emulated by libinput, not by the hardware itself. If kernel v4.18 fixed the left button, your issue is in libinput configuration. Gnome recently changed the default and you can get the right click by clicking with 2 fingers, and middle click with 3 fingers. [1] https://bentiss.github.io/hid-replay-docs/
Hi, Thanks for your response. Firstly, you're right, the whole touchpad is depressible with no physical buttons but does have a line drawn in the middle at the bottom signifying the left and right mouse button. I also think you're right with the buttons being emulated by libinput, I think this is where the issue is, as I can move the mouse point around using the bottom right of the touch pad but clicking it does nothing - and is not registered in libinput debug-events. Kernel 4.18 was the first instance of the issue, 4.18.3 brought the left and middle buttons back - but this part may be a red herring, not sure. Rolling back to 4.17.14 or below (4.17.14 is the latest 4.17 kernel for my distro), brings the touchpad back to normal operation. I also don't use Gnome, but rather xfce, as far as I am aware there have been no major changes surrounding mouse operating in xfce. I have however installed Gnome to test and the problem remains there, 2 finger tapping and 3 finger tapping also does nothing - I can't stand tapping though so this is not an option for me. Below is the output of hid-record as requested. With single right-button click. kernel 4.18.5 --------------------------------------------- https://pastebin.com/tiDMBzeZ Left, Middle then Right-button clicks. kernel 4.18.5 ---------------------------------------------------- https://pastebin.com/Ta8iaBZf Left, Middle then Right-button clicks. kernel 4.17.14 ----------------------------------------------------- https://pastebin.com/sxikA6MK Thanks again for your help, hopefully we'll get somewhere! Thanks,
in the interest of adding more information, I have now added the below to my /etx/X11/Xorg.conf.d/30-touchpad.conf file which grants me 2 fingered tap = right click. Section "InputClass" Identifier "libinput touchpad catchall" MatchIsTouchpad "on" MatchDevicePath "/dev/input/event*" Driver "libinput" Option "ClickMethod" "clickfinger" EndSection However, the right hand side of the touchpad (which now should act as a left click) still does not register any events. I have also tested in kernel 4.17.14 and with this configuration the left mouse button should, and does, cover the entire bottom area of the mouse.
Created attachment 278153 [details] hid-recorder of left/middle/right clicks under v4.18 Thanks for the logs. However, for the future, please attach them directly to the bug. A pastebin link will disappear and we will lose the logs in the near future
Created attachment 278155 [details] hid-recorder of left/middle/right clicks under v4.17
This is *weird*. In the v4.18 case, the firmware simply doesn't send the button clicks when you are in the right area of the touchpad. However, in the v4.17 case, the firmware is much nicer and send the proper buttons clicks. I need to check if there have been any changes somewhere that would influence the touchpad, but I have the feeling there is either a hardware fault (and 4.17 was just a lucky try) or something convoluted happened and messed up the events.
Ah, thanks for your reply again. Sorry for the paste in, was trying to keep things tidy. It certainly is weird, I've been active on an Arch Linux specific forum about this issue too and it seems I'm not the only one. Thought it is still this specific touchpad https://bbs.archlinux.org/viewtopic.php?id=239747 Weird, weird, weird. But hey, that's why we love computers right? :-)
(In reply to Paul Terry from comment #10) > Weird, weird, weird. But hey, that's why we love computers right? :-) I certainly would rather not have to deal with all of those issues I confess :) ELAN1200 touchpads are a pain, and I have a lot of issues with those (or the platforms attached to those touchpads) Anyway, could you try to revert 02946f4b43b11026b1a76857a33b09078b900939 on a v4.18 kernel? This is the only change IMO that would influence the firmware. Note that we can't simply revert it from v4.19 and forward as I rewrote a lot of the code in those later version. Adapting the change should be trivial to do however.
(In reply to Benjamin Tissoires from comment #11) > Anyway, could you try to revert 02946f4b43b11026b1a76857a33b09078b900939 on > a v4.18 kernel? Hi, I have just done this and I'm afraid to say it hasn't made any difference. I may have done it wrong though, I checked out the 02946f4 commit then reverted its changes - would that be right? (of course then compiling and booting from the changed kernel) Another thing I have noticed, which is probably why the left mouse button looked as if it got fixed in my earlier comments, is that with tapping switched off in mouse settings (xfce4), neither buttons work on 4.18+ but do work on 4.17-, I need to switch on tapping to get the left mouse button to work in 4.18+ - of course this probably means the left mouse button doesn't work, but the act of "clicking" it causes a tap to be inferred. I may try another distro when they move to the new kernel to see if it is distro specific.
Just as additional information I have checked out two consecutive commits which have a working and non-working mouse 7f81c8d - doesn't work 40ec260 - works
Thanks for bisecting. FYI, Mustafa found the same culprit here: https://www.spinics.net/lists/linux-input/msg57911.html So I guess I should be able to find out why now.
Created attachment 278283 [details] 0001-HID-multitouch-fix-Elan-panels-with-2-input-modes-de.patch Can you please give a try at the attached patch? This should revert the v4.17 kernel behavior.
I will compile and test that ASAP - thanks for debugging! :-)
FYI, I also added this specific behavior on my hid test suite here: https://gitlab.freedesktop.org/libevdev/hid-tools/commit/4893d23c6f6af94f68607810acb23850e21a627d This should prevent future mistakes.
Looking good! patched on 4.19rc1 and working well! nicely done, I owe you a beer/coffee/glass of wine!
patch now submitted: https://patchwork.kernel.org/patch/10587363/
Hi there! I am owner of a lenovo T480s which seem to have such an elantech input device: (extract from `cat /proc/bus/input/devices`) I: Bus=0018 Vendor=04f3 Product=0020 Version=0000 N: Name="Elan Touchpad" P: Phys= S: Sysfs=/devices/pci0000:00/0000:00:1f.4/i2c-7/7-0015/input/input23 U: Uniq= H: Handlers=mouse1 event16 B: PROP=1 B: EV=b Like OP, updating from 4.17 to 4.18 did break button support, the bottom-right of the touchpad area no longer being detected as a "right click". Having knowledge of this bug, I was waiting for my distribution to upgrade me to 4.19 (supposedly containing this fix), which just happened: (from `uname -a`) Linux box 4.19.2-300.fc29.x86_64 #1 SMP Wed Nov 14 19:05:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Unfortunately it appears that right click emulation still is in regress compared to 4.17 (with 4.19 and just like 4.18, it behaves like a left-click). Could it be that there is more to this story? My knowledge is very much lacking in this area (and in the Kernel in general), but I'd love to help if there's anything I can do.
Sorry to hear you're still suffering with this bug. I can confirm I am running kernel 4.19.2 and things are still perfectly fine for me. I'm not too familiar with HW Vendor and Product numbering, but my touchpad does show slightly differently to yours from cat /proc/bus/input/devices I: Bus=0018 Vendor=04f3 Product=301a Version=0100 N: Name="ELAN1200:00 04F3:301A Touchpad" P: Phys=i2c-ELAN1200:00 S: Sysfs=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-ELAN1200:00/0018:04F3:301A.0001/input/input13 U: Uniq= H: Handlers=event8 mouse0 B: PROP=5 B: EV=1b B: KEY=e520 10000 0 0 0 0 B: ABS=2e0800000000003 B: MSC=20 I'm not sure if perhaps you may be suffering with a different issue more specific to your hardware and/or distro. Sorry I can't be of more help, but I thought I would at least offer information from my working hardware in an attempt to help.
James, this may not be a kernel bug, you may be running into this: https://who-t.blogspot.com.au/2018/04/gnome-328-uses-clickfinger-behaviour-by.html
Hi Peter, thanks for the pointer! (no pun intended ;) I tried few of the gsettings commands from the blog you linked, it doesn't seem to do much, unfortunately. From what I understand of the clickfinger description, clicking anywhere on the touchpad with one, two or three fingers is what is supposed to emulate the left, right and middle click buttons, but with either setting, no matter how many fingers are touching the surface when I click, I only manage to send left-click events it appears. Further search took me to this other ticket you're involved in: https://gitlab.freedesktop.org/libinput/libinput/issues/177 That also looks like a good candidate for my problem (let it only be due to the common laptop model).
Right, I read over the T480s bit, sorry. That one has a different elantech touchpad than the one originally reported in this bug, despite them all being Elantech devices. So very different issue, please check the kernel patch I linked to there.