0

EDIT: Since I don't know from which component the problem comes from (kernel, xorg server, firmware, other?) I have added information from the xinput --list command and the /proc/bus/input/devices file. Thus I have also edited the list of tags. I believe it doesn't comes from the driver since testing different xorg drivers (synaptics, libinput, mtrack) doesn't solve the problem, plus the problem can be seen directly in the output of evtest which, according to its man page, "shows the information presented by the kernel". But maybe I am wrong?

Context

I have an ASUS P5440 on which I am trying to install Linux.

I have tested the following distributions and the problem is all the same:

  • Linux Mint 19.1 - Cinnamon (kernel 4.15.0-43-generic)
  • Ubuntu 18.10
  • Manjaro 18.0 - Cinnamon 4.0.1 (kernel: 4.19.4-1-MANJARO)
  • Manjaro Gnome 18.0.2
  • Manjaro-i3 (Manjaro Linux 18.0 Illyria, kernel: 4.19.2-1-MANJARO)

My problem seems to be the same as this question: ASUS Zenbook UX430UAR touchpad sleeps (seemingly not a USB autosuspend issue) but no answer was found.

I tried to use this other question: https://askubuntu.com/questions/1009812/asus-touchpad-not-working-properly, but in the end the problems seems to be a different one.

On the other side I managed to make some progress in tracking the origin of the problem but now I am stuck.

The problem: ASUS touchpad issues at new contact after > 1 sec (slight lag + unexpected double-click at contact):

When the feature 'Tap to click' is enabled in 'Mouse and Touchpad', each time I begin to use the touchpad after having let it unused for > 1 second, the touchpad is slow to react to my first movement (there is a sub-second lag during which the pointer seems stuck) plus it interprets the new contact as a double-click, so that when the pointer finally starts to move I end up creating a selecting frame or dragging whatever was below the pointer when I started moving it.

On the other hand, if I constantly use the touchpad without leaving it at rest for longer than 1 sec, everything works fine: the touchpad reacts instantly at all the commands and it doesn't generate unexpected double-clicks.

I have try to adjust obvious parameters such as the sensitivity, but clearly the problem doesn't come from there.

Here is the output of xinput --list for the touch pad:

$ xinput --list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ FTE1200:00 0B05:0701 Touchpad             id=11   [slave  pointer  (2)]
...

Here are the info from /proc:

$ cat /proc/bus/input/devices
...
I: Bus=0018 Vendor=0b05 Product=0701 Version=0100
N: Name="FTE1200:00 0B05:0701 Touchpad"
P: Phys=i2c-FTE1200:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-FTE1200:00/0018:0B05:0701.0001/input/input7
U: Uniq=
H: Handlers=mouse0 event6 
B: PROP=5
B: EV=1b
B: KEY=e520 10000 0 0 0 0
B: ABS=260800000000003
B: MSC=20
...

Working in Linux Mint Cinnamon and using the evtest command as suggested in a Linux Mint forum article, I have obtained the following:

Touchpad event without issue

For touchpad contacts giving no issue (i.e. when constantly using the touchpad), the evtest output has this structure:

Event: time 1547667771.554622, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 349
Event: time 1547667771.554622, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 480
Event: time 1547667771.554622, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 315
Event: time 1547667771.554622, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1547667771.554622, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1547667771.554622, type 3 (EV_ABS), code 0 (ABS_X), value 480
Event: time 1547667771.554622, type 3 (EV_ABS), code 1 (ABS_Y), value 315
Event: time 1547667771.554622, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 0
Event: time 1547667771.554622, -------------- SYN_REPORT ------------
[...]
Event: time 1547667771.850532, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 307500
Event: time 1547667771.850532, -------------- SYN_REPORT ------------
Event: time 1547667771.857897, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1547667771.857897, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1547667771.857897, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1547667771.857897, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 315000
Event: time 1547667771.857897, -------------- SYN_REPORT ------------

where the [...] indicates a long list of lines of similar sort of content.

What is important to note here is the lines with BTN_TOUCH and BTN_TOOL_FINGER : associated with the value 1 at the beginning they indicate that a contact has been made, associated with the value 0 at the end they indicate that the contact has been interrupted (when I stop using the touchpad).

Tochpad event with the issue

Now, in the case where the problem appears (that is when I contact the touchpad after > 1 sec has passed) the evtest outputs the following:

Event: time 1547667802.178649, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 353
Event: time 1547667802.178649, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 642
Event: time 1547667802.178649, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 203
Event: time 1547667802.178649, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1547667802.178649, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1547667802.178649, type 3 (EV_ABS), code 0 (ABS_X), value 642
Event: time 1547667802.178649, type 3 (EV_ABS), code 1 (ABS_Y), value 203
Event: time 1547667802.178649, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 0
Event: time 1547667802.178649, -------------- SYN_REPORT ------------
Event: time 1547667802.179359, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 7500
Event: time 1547667802.179359, -------------- SYN_REPORT ------------
Event: time 1547667802.184480, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 15000
Event: time 1547667802.184480, -------------- SYN_REPORT ------------
Event: time 1547667802.191692, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
> Event: time 1547667802.191692, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
> Event: time 1547667802.191692, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1547667802.191692, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 22500
Event: time 1547667802.191692, -------------- SYN_REPORT ------------
Event: time 1547667802.221584, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 354
Event: time 1547667802.221584, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 525
Event: time 1547667802.221584, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 275
> Event: time 1547667802.221584, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
> Event: time 1547667802.221584, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
Event: time 1547667802.221584, type 3 (EV_ABS), code 0 (ABS_X), value 525
Event: time 1547667802.221584, type 3 (EV_ABS), code 1 (ABS_Y), value 275
Event: time 1547667802.221584, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 30000
Event: time 1547667802.221584, -------------- SYN_REPORT ------------
[...]
Event: time 1547667802.661690, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 472500
Event: time 1547667802.661690, -------------- SYN_REPORT ------------
Event: time 1547667802.669047, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1547667802.669047, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1547667802.669047, type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: time 1547667802.669047, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 480000
Event: time 1547667802.669047, -------------- SYN_REPORT ------------

Note the 2 internal events (of 2 lines each), not far below the initial contact, and that I have indicated by > signs at the beginning of the respective lines: they correspond to a contact interruption (value 0) and then a contact re-establishment (value 1). It is these two internal events that triggers the initial double-click and that causes the problem.

Here is the output from an xinput --list-props command:

Device 'FTE1200:00 0B05:0701 Touchpad':
    Device Enabled (143):   1
    Coordinate Transformation Matrix (145): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    libinput Tapping Enabled (281): 1
    libinput Tapping Enabled Default (282): 0
    libinput Tapping Drag Enabled (283):    1
    libinput Tapping Drag Enabled Default (284):    1
    libinput Tapping Drag Lock Enabled (285):   0
    libinput Tapping Drag Lock Enabled Default (286):   0
    libinput Tapping Button Mapping Enabled (287):  1, 0
    libinput Tapping Button Mapping Default (288):  1, 0
    libinput Natural Scrolling Enabled (289):   0
    libinput Natural Scrolling Enabled Default (290):   0
    libinput Disable While Typing Enabled (291):    1
    libinput Disable While Typing Enabled Default (292):    1
    libinput Scroll Methods Available (293):    1, 1, 0
    libinput Scroll Method Enabled (294):   1, 0, 0
    libinput Scroll Method Enabled Default (295):   1, 0, 0
    libinput Click Methods Available (296): 1, 1
    libinput Click Method Enabled (297):    1, 0
    libinput Click Method Enabled Default (298):    1, 0
    libinput Middle Emulation Enabled (299):    0
    libinput Middle Emulation Enabled Default (300):    0
    libinput Accel Speed (301): -0.064777
    libinput Accel Speed Default (302): 0.000000
    libinput Left Handed Enabled (303): 0
    libinput Left Handed Enabled Default (304): 0
    libinput Send Events Modes Available (266): 1, 1
    libinput Send Events Mode Enabled (267):    0, 0
    libinput Send Events Mode Enabled Default (268):    0, 0
    Device Node (269):  "/dev/input/event7"
    Device Product ID (270):    2821, 1793
    libinput Drag Lock Buttons (305):   <no items>
    libinput Horizontal Scroll Enabled (306):   0

I have also tried to change the driver from libinput to synaptics using the command sudo apt install xserver-xorg-input-synaptics as suggested in the page of the Release Notes for Linux Mint 19.1 Cinnamon but the problem was still there. I have tried to change the driver for evdev as indicated in the same page, but after the install I only get libinput in the outcome of the command grep -i "Using input driver" /var/log/Xorg.0.log; removing libinput with the command sudo apt remove xserver-xorg-input-libinput let me with a non-responding touchpad. I have also tested the driver mtrack but the problem is still there.

So the questions are:

  • Is this a bug (i.e. is this a software issue) and if so at which level can it be (driver, kernel, firmware) ?
  • Can it be material (and in particular, can it be in some way related to some power management settings that put the touchpad to sleep after 1 sec) ?
  • What can I do next to track the issue ?
  • Would anyone have a solution to the problem ?
  • As it's visible in evtest, whatever is causing it happens in the interaction between the kernel driver and the firmware. Yes, it could be power management issues. The way to debug this further is to identify the kernel driver (via dmesg after boot), look at the kernel driver code, enable debugging for it etc. – dirkt Mar 16 at 22:27
  • @dirkt Thank you very much for your reply. I found those two lines in the file /var/log/kernel.log containing the term "touch": kernel: [ 4.507490] input: FTE1200:00 0B05:0701 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-FTE1200:00/0018:0B05:0701.0001/input/input9 kernel: [ 4.507574] hid-multitouch 0018:0B05:0701.0001: input,hidraw1: I2C HID v1.00 Mouse [FTE1200:00 0B05:0701] on i2c-FTE1200:00 I am not sure yet how to recognize the name of the driver there. Also, would you have some hint about how to enable debugging? – The Quark Apr 9 at 17:48
  • Ok, it's HID over I2C. Read up on both I2C and HID (too long to explain in detail here), on how the kernel handles both and exposes direct interfaces (via /dev/hidrawX and /dev/i2c-* after modprobe i2c-dev). Then you can debug the intermediate stages of the driver stack (e.g. monitor the hidraw device, see if the HID descriptor at /sys/kernel/debug/hid/<dev>/rdesc helps in any way) and hope you run across something that will narrow down the problem. Warning: If you are not familiar with any of this, you'll have to do a lot of reading. But nobody can debug that without the hardware. – dirkt Apr 10 at 16:58
  • @dirkt Ok, thanks a lot for all these details. I will look into it, but indeed I am not familiar with any of this, so I don't know how long it will take or if I will even manage to dig further... But I will try. Thanks again. – The Quark Apr 11 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.