Bug 200899 - Touchpad buttons not working on Asus UX360C Notebook
Summary: Touchpad buttons not working on Asus UX360C Notebook
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-22 19:04 UTC by Paul Terry
Modified: 2018-11-19 22:24 UTC (History)
6 users (show)

See Also:
Kernel Version: 4.18+
Tree: Mainline
Regression: No


Attachments
hid-recorder of left/middle/right clicks under v4.18 (16.19 KB, text/plain)
2018-08-28 07:23 UTC, Benjamin Tissoires
Details
hid-recorder of left/middle/right clicks under v4.17 (13.47 KB, text/plain)
2018-08-28 07:24 UTC, Benjamin Tissoires
Details
0001-HID-multitouch-fix-Elan-panels-with-2-input-modes-de.patch (2.71 KB, patch)
2018-09-04 08:19 UTC, Benjamin Tissoires
Details | Diff

Description Paul Terry 2018-08-22 19:04:40 UTC
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
Comment 1 Paul Terry 2018-08-22 19:17:00 UTC
by "17.4" i mean kernel version 4.17.14, apologies
Comment 2 Paul Terry 2018-08-23 20:50:26 UTC
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
Comment 3 Paul Terry 2018-08-24 17:04:46 UTC
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 ------------
Comment 4 Benjamin Tissoires 2018-08-27 15:21:28 UTC
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/
Comment 5 Paul Terry 2018-08-27 18:45:06 UTC
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,
Comment 6 Paul Terry 2018-08-27 20:00:35 UTC
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.
Comment 7 Benjamin Tissoires 2018-08-28 07:23:57 UTC
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
Comment 8 Benjamin Tissoires 2018-08-28 07:24:20 UTC
Created attachment 278155 [details]
hid-recorder of left/middle/right clicks under v4.17
Comment 9 Benjamin Tissoires 2018-08-28 07:27:11 UTC
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.
Comment 10 Paul Terry 2018-08-28 07:40:32 UTC
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? :-)
Comment 11 Benjamin Tissoires 2018-08-28 07:47:36 UTC
(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.
Comment 12 Paul Terry 2018-08-30 09:38:04 UTC
(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.
Comment 13 Paul Terry 2018-09-01 10:00:18 UTC
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
Comment 14 Benjamin Tissoires 2018-09-03 08:34:15 UTC
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.
Comment 15 Benjamin Tissoires 2018-09-04 08:19:06 UTC
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.
Comment 16 Paul Terry 2018-09-04 08:22:52 UTC
I will compile and test that ASAP - thanks for debugging! :-)
Comment 17 Benjamin Tissoires 2018-09-04 08:47:03 UTC
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.
Comment 18 Paul Terry 2018-09-04 10:20:14 UTC
Looking good!
patched on 4.19rc1 and working well!

nicely done, I owe you a beer/coffee/glass of wine!
Comment 19 Benjamin Tissoires 2018-09-04 13:35:21 UTC
patch now submitted: https://patchwork.kernel.org/patch/10587363/
Comment 20 James Ingel 2018-11-16 22:25:23 UTC
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.
Comment 21 Paul Terry 2018-11-17 13:20:13 UTC
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.
Comment 22 Peter Hutterer 2018-11-18 23:05:29 UTC
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
Comment 23 James Ingel 2018-11-19 16:44:11 UTC
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).
Comment 24 Peter Hutterer 2018-11-19 22:24:47 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.