Bug 1543769 - Elan1200 touchpad not well managed by hid_multitouch module
Summary: Elan1200 touchpad not well managed by hid_multitouch module
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 30
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1678720 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-09 09:31 UTC by vivien.frasca
Modified: 2022-01-24 09:49 UTC (History)
39 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-24 10:44:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
lsmod output (5.85 KB, text/plain)
2018-02-09 09:31 UTC, vivien.frasca
no flags Details
output of journalctl | grep elan (52.03 KB, application/octet-stream)
2018-02-09 09:32 UTC, vivien.frasca
no flags Details
hid-recorder (26.76 KB, text/plain)
2018-02-14 13:52 UTC, vivien.frasca
no flags Details
hid-recorder with hid-elan probed (269.34 KB, text/plain)
2018-02-15 12:58 UTC, vivien.frasca
no flags Details
hid-multitouch for-vivien record (64.33 KB, text/plain)
2018-02-21 07:57 UTC, vivien.frasca
no flags Details
DSDT-fixed-with-probe-v2.ASL (1.40 MB, text/plain)
2018-02-28 14:47 UTC, Benjamin Tissoires
no flags Details
I2C traces under Windows (271.44 KB, text/plain)
2018-02-28 14:49 UTC, Benjamin Tissoires
no flags Details
I2C initialization traces under Windows (18.33 KB, text/plain)
2018-03-20 15:32 UTC, Benjamin Tissoires
no flags Details
Dump ACPI FX503VD (1.02 MB, text/plain)
2018-03-22 13:33 UTC, vivien.frasca
no flags Details
The dmesg with the irqflags set to IRQ_TRIGGER_FALLING (15.37 KB, text/plain)
2018-03-22 14:02 UTC, vivien.frasca
no flags Details
idle log IRQ each seconds while 10 seconds (18.20 KB, text/plain)
2018-03-22 14:23 UTC, vivien.frasca
no flags Details
active log IRQ each seconds while 10 seconds (12.18 KB, text/plain)
2018-03-22 14:24 UTC, vivien.frasca
no flags Details
IRQ intel-gpio log (1.84 KB, text/plain)
2018-03-22 21:58 UTC, vivien.frasca
no flags Details
IRQ pins (9.92 KB, text/plain)
2018-03-23 12:17 UTC, vivien.frasca
no flags Details
dmesg of patch f5a26ac (71.51 KB, text/plain)
2018-03-27 11:18 UTC, vivien.frasca
no flags Details
interrupts of patch f5a26ac (3.77 KB, text/plain)
2018-03-27 11:19 UTC, vivien.frasca
no flags Details
pins of patch f5a26ac (9.91 KB, text/plain)
2018-03-27 11:19 UTC, vivien.frasca
no flags Details
dumps of changing irq type in i2c-hid.c (24.07 KB, application/x-xz)
2018-03-27 12:10 UTC, vivien.frasca
no flags Details
IRQ cat loop (Bit 29 | Bit 24) (691 bytes, application/x-gzip)
2018-03-28 12:21 UTC, vivien.frasca
no flags Details
Fix SPT-H pin numbering to follow BIOS and Windows (1.90 KB, patch)
2018-03-28 13:54 UTC, Mika Westerberg
no flags Details | Diff
/proc/interrupts (1.04 KB, application/x-gzip)
2018-03-28 14:49 UTC, vivien.frasca
no flags Details
pinctrl (9.91 KB, text/plain)
2018-03-28 15:03 UTC, vivien.frasca
no flags Details
GPIO pins and ranges (10.59 KB, text/plain)
2018-03-28 19:49 UTC, vivien.frasca
no flags Details
interrupts after suspend (3.81 KB, text/plain)
2018-03-28 20:48 UTC, vivien.frasca
no flags Details
dmesg i2c-hid init sequence failed (4.44 KB, text/plain)
2018-03-29 08:04 UTC, vivien.frasca
no flags Details
5 fingers tap trace (4.60 KB, text/plain)
2018-03-29 08:41 UTC, vivien.frasca
no flags Details
dmesg wak up after suspend (12.34 KB, text/plain)
2018-03-29 13:52 UTC, vivien.frasca
no flags Details
5 finger tap W10 traces (360.21 KB, text/plain)
2018-04-01 16:04 UTC, vivien.frasca
no flags Details
Kernel crash report after suspend (22.75 KB, application/x-xz)
2018-04-04 19:32 UTC, vivien.frasca
no flags Details
lspci (2.00 KB, text/plain)
2018-04-05 11:51 UTC, vivien.frasca
no flags Details
Hid over i2c protocol spec (555.68 KB, application/zip)
2018-09-16 11:20 UTC, Andrey Ivanov
armv7hf: review+
Details
HID-touchpad full patch (1.70 KB, patch)
2019-03-14 17:51 UTC, Vladislav
no flags Details | Diff
signal output from scope of ELAN touchpad (24.43 KB, image/png)
2019-06-13 05:07 UTC, Chris Chiu
no flags Details
mika's patch to save and restore all all gpio pins on suspend (1.36 KB, patch)
2019-07-26 17:07 UTC, Will Roberts
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 105024 0 None None None 2018-02-14 14:42:23 UTC
Github mishurov linux_elan1200_touchpad issues 3 0 None closed Support for ASUS FX503VD 2020-08-28 11:28:14 UTC
Linux Kernel 198473 0 None None None 2019-08-08 08:04:47 UTC
Linux Kernel 200663 0 None None None 2019-08-08 08:04:47 UTC
Red Hat Bugzilla 1653546 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1645042 1653546 1793549

Description vivien.frasca 2018-02-09 09:31:40 UTC
Created attachment 1393615 [details]
lsmod output

Description of problem:

The touchpad of an ASUS FX503VD laptop is not well handled by hid_multitouch kernel module. The cursor jumps and trigger randomly click events (right clicks).

The device infos :

Device:           ELAN1200:00 04F3:303E Touchpad
Kernel:           /dev/input/event11
Group:            10
Seat:             seat0, default
Size:             103x71mm
Capabilities:     pointer gesture
Tap-to-click:     disabled
Tap-and-drag:     enabled
Tap drag lock:    disabled
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   *two-finger edge 
Click methods:    *button-areas clickfinger 
Disable-w-typing: enabled
Accel profiles:   none
Rotation:         n/a


Version-Release number of selected component (if applicable):

uname -r :

4.14.16-300.fc27.x86_64


How reproducible: ...


Steps to Reproduce:

May be with evemu-play : https://gist.github.com/PapsOu/60245c4c33060e4a18f850d95c8cdf10

Additional info:

See attachements

Comment 1 vivien.frasca 2018-02-09 09:32:45 UTC
Created attachment 1393616 [details]
output of journalctl | grep elan

Comment 2 vivien.frasca 2018-02-09 09:34:45 UTC
I'm running gnome on wayland. The problem is the same with gnome on X11.

Comment 3 vivien.frasca 2018-02-12 20:22:22 UTC
Here a small log of i2c_hid.debug=1 kernel option :

parts with « input: ff » seems to fit with the cursor jumps detected.

févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 46 05 f8 04 73 94 01 00 12 44 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 3b 05 eb 04 c7 95 01 00 1b 44 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 1f 05 df 04 c5 97 01 00 1f 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 06 05 d9 04 c3 99 01 00 27 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 03 05 f3 04 0d 9b 01 00 2a 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 fe 04 21 05 93 9c 01 00 29 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 e6 04 6b 05 f9 9f 01 00 29 64 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 ed 04 95 05 ed a1 01 00 29 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 ef 04 9e 05 47 a2 01 00 29 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 f9 04 bd 05 a5 a3 01 00 27 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 fb 04 c3 05 ff a3 01 00 25 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 06 05 d6 05 cb a5 01 00 24 54 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 08 05 e1 05 29 a7 01 00 16 44 00 00
févr. 12 21:19:35 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 07 05 e9 05 d3 a7 01 00 10 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 ef 04 9e 04 25 e2 01 00 16 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 9c 04 97 04 67 e6 01 00 24 55 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 89 04 96 04 11 e7 01 00 24 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 80 04 94 04 6b e7 01 00 24 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 66 04 90 04 bf e8 01 00 27 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 59 04 8c 04 69 e9 01 00 27 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 2e 04 7e 04 53 eb 01 00 25 55 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 ff 03 6e 04 a7 ec 01 00 25 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 e8 03 65 04 51 ed 01 00 27 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 bc 03 54 04 ff ee 01 00 27 54 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 b4 03 50 04 6d ef 01 00 27 44 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 b0 03 4c 04 b3 ef 01 00 27 44 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 a6 03 46 04 7b f0 01 00 27 44 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 7b 03 38 04 eb f3 01 00 1d 44 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 79 03 37 04 95 f4 01 00 12 43 00 00
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:37 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 01 79 03 37 04 8f f5 01 00 0e 43 00 00
févr. 12 21:19:39 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:39 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:39 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 e5 03 5b 03 a5 48 01 00 1d 55 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 16 04 3b 03 81 49 01 00 1f 44 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 5a 04 0f 03 7f 4b 01 00 21 44 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 e7 04 e5 02 03 4f 01 00 21 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 06 05 dc 02 ad 4f 01 00 1f 55 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 4f 05 c9 02 ed 50 01 00 21 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 c9 05 b4 02 3b 53 01 00 1f 55 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 41 06 a1 02 9d 55 01 00 21 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 6c 06 9a 02 ab 56 01 00 21 55 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 b2 06 90 02 45 58 01 00 24 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 e9 06 8b 02 cb 59 01 00 21 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 07 07 89 02 a7 5a 01 00 21 55 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 98 07 7c 02 8f 5e 01 00 24 45 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 cd 07 79 02 cf 5f 01 00 24 44 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 da 07 79 02 1f 60 01 00 24 44 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 0e 08 78 02 73 61 01 00 24 44 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 57 08 7a 02 a3 63 01 00 21 45 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 84 08 7a 02 e3 64 01 00 21 44 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 a6 08 84 02 f1 65 01 00 21 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 bd 08 87 02 cd 66 01 00 21 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 0d 09 8a 02 3d 6a 01 00 1f 55 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 29 09 94 02 7d 6b 01 00 1d 54 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 03 67 09 bb 02 67 6d 01 00 0a 33 00 00
févr. 12 21:19:40 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 10 00 04 01 82 09 c2 02 11 6e 01 00 0a 33 00 00

Comment 4 Benjamin Tissoires 2018-02-14 13:27:17 UTC
Hi, could you attach a hid-recorder output showing the jumps? (package hid-replay, and running the command as root)

In addition to the events you showed, I also need the description of the device, so hid-recorder will give me everything.

Comment 5 vivien.frasca 2018-02-14 13:52:43 UTC
Created attachment 1395934 [details]
hid-recorder

Hi, please find the hid-recorder for the touchpad.

Comment 6 Benjamin Tissoires 2018-02-14 14:38:14 UTC
Thanks for the quick answer. Unfortunately, this seems to me that your firmware is completely buggy. The contact count field is not accurate at all (it goes to 0 from time to time), nor is the tip switch information.

There seem to be updates for your device on Asus website. It could be interesting to see if they would help here. Also, do you have similar issues on Windows (if you kept it)?

To me, it's a faulty hardware.

Comment 7 vivien.frasca 2018-02-14 14:42:24 UTC
Thanks for you quick analyse.

I've kept Windows 10 in dual boot, and the problem does not appear on this OS.

So I've excluded a hardware failure, that's why I've created this bug ticket.

Comment 8 vivien.frasca 2018-02-14 14:53:43 UTC
If I try to move fast the finger, I can see in journalctl messages about curso jumps.

Here the part of journalctl :

$ journalctl | grep jump

févr. 14 15:51:00 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:00 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:01 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:02 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:03 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:03 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details
févr. 14 15:51:03 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: (EE) event18 - (EE) ELAN1200:00 04F3:303E Touchpad: (EE) kernel bug: Touch jump detected and discarded.
févr. 14 15:51:03 FX503VD /usr/lib/gdm3/gdm-x-session[1347]: See https://wayland.freedesktop.org/libinput/doc/1.8.2/touchpad_jumping_cursor.html for details

Comment 9 Benjamin Tissoires 2018-02-14 15:28:46 UTC
Having a second look at the logs, it is as if when there are 2 fingers down, we are missing one of the two finger reports. If we receive the finger with the contact ID 0, we have a valid contact count, if not, then we are receiving a contact count of 0. This greatly confuses hid-multitouch as you can expect.

There is one thing that intrigues me. In the github repo you linked here, there is a latency feature report that is set. It could be interesting to know if setting it would help hid-multitouch.

If I understand correctly, you managed to enable the out-of-the-tree hid-elan module. When it is done, could you send out an other hid-recorder output? I'd like to see if we are getting all the reports this time.

Comment 10 vivien.frasca 2018-02-14 15:42:17 UTC
Sorry I can't test the module right now because I've installed Ubuntu 17.10 in place of fedora yesterday (in order to test if another Linux distribution would change something to the problem) and the kernel used by this distribution is 4.13, so the .

I'll reinstall fedora as soon as possible mishurov's hid-elan module cannot compile due to the timer API change in 4.14

I'll reinstall fedora tomorrow and give you a hid-record with the module probed.

Thank's a lot for your help !

Comment 11 vivien.frasca 2018-02-15 12:58:09 UTC
Created attachment 1396472 [details]
hid-recorder with hid-elan probed

I've reinstalled fedora and recorded the touchpad with mishurov's kernel module.

The pointer does not move on the screen, but the record seems to record the coordinates of the finger.

Please tell me if you need other infos.

FYI : How I probed the hid-elan module :

changed vendor and model IDs in source code of hid-elan.c (lines 22 and 23)
make
sudo insmod ./hid-elan.ko

Comment 12 Benjamin Tissoires 2018-02-16 10:43:53 UTC
Thanks for the logs. I can confirm you are using hid-elan as the device is not switched to the multitouch mode like it was with hid-multitouch.
However, as you can deduce, this doesn't help us knowing if this fixes the issue or not.

I do not know why the driver doesn't switches the input mode to INPUT_MODE_TOUCHPAD as it should. There is something wrong here that I'll need to track. I am overloaded and I might be able to have a look at it next week.

Comment 13 vivien.frasca 2018-02-16 11:09:53 UTC
Thank you very much Benjamin.

No problems for the time management, I'm using an external USB mouse, because without it, the touchpad is not usable at all.

Let me know if you want me to give you more debug output or any other tests.

Comment 14 vivien.frasca 2018-02-18 20:36:55 UTC
With recent kernel update, the problem is still present.

4.15.3-300.fc27.x86_64

Comment 15 Benjamin Tissoires 2018-02-20 15:44:57 UTC
Hi Viven.

Do you mind testing the branch for-vivien on the following repo:
https://github.com/bentiss/hid-multitouch/tree/for-vivien

On Fedora 27 with a v4.15 kernel, a simple 'make' then 'sudo rmmod hid_multitouch; sync && sudo insmod ./hid-multitouch.ko' should be enough to be running the new code.

If you successfully loaded this new kernel module, the dmesg should shout some (debug) errors like "[  +0.021724] mt_set_latency_mode setting latency mode to 0 $SOME_PATH/hid-multitouch/hid-multitouch.c:1151"

Once this is properly loaded, please re-attach a hid-recorder of the 2 fingers scrolls and jumps test cases.

Ideally, also make sure the debug messages are there on suspend/resume.

Comment 16 vivien.frasca 2018-02-20 16:09:31 UTC
Thanks Benjamin, I'll try this branch as soon as possible (probably tomorrow).

I keep you in touch.

Comment 17 vivien.frasca 2018-02-21 07:57:13 UTC
Created attachment 1398561 [details]
hid-multitouch for-vivien record

Please find the hid-record with the « for-vivien » build of hid-multitouch kernel module.

Gestures done are :

- two finger scroll (up and down or inverse)
- some circles with one finger
- a double tap
- a triple finger scroll
- quad finger scroll

If you want other gestures, feel free to ask me.

PS: With this version of module, the jumpy cursor is still present.

Comment 18 Benjamin Tissoires 2018-02-22 10:15:16 UTC
Thanks for the logs. Unfortunately, the jumps are still there because the device just sends something hard to parse as we are missing events.

I'll try to reach out to Elan, but there is one last thing I'd like to see, but it'll require a little bit of manipulations under Windows, so I won't blame you if you are not feeling doing it.

The basic thing I'd like to see is what is the Windows driver sees. If it sees the same garbage we have under linux, then it has super powers, but if the data is consistent with a multitouch device, then there is something wrong at a different level.

Enough of forewords, it all happens at https://github.com/bentiss/SimplePeripheralBusProbe

We need to edit your DSDT to introduce the probe (I can do that if you provide the files), and then we'll try to see if the logs are identical under Windows or if something else tampers with us.

Comment 19 vivien.frasca 2018-02-22 14:48:28 UTC
I'm really confused but I've installed under W10 the tools that you mentionned in the github repo, but I can't execute the first command "asl.exe /tab=DSDT". asl is not found.

I've installed VS17 and WDK (took 3 hours just for installs...).

Sould I open anew issue on your github repo for that purpose ?

Comment 20 Benjamin Tissoires 2018-02-22 14:56:16 UTC
(In reply to vivien.frasca from comment #19)
> I'm really confused but I've installed under W10 the tools that you
> mentionned in the github repo, but I can't execute the first command
> "asl.exe /tab=DSDT". asl is not found.

The WDK should ship it. In the README, I said that the tool should be under Tools\x64\ACPIVerify (so in its install path, then in this directory).
The Windows terminal is not so nice with us, and you need to be in the correct directory to be able to run the tool.

> 
> I've installed VS17 and WDK (took 3 hours just for installs...).

Oops, sorry, you don't need VS17, the compiled files are in https://github.com/bentiss/SimplePeripheralBusProbe/releases

> 
> Sould I open anew issue on your github repo for that purpose ?

Well, if you can't find it, then yes, but I am pretty sure it's there.

BTW, we should probably switch over email for the debugging, as we might polute too much the bugzilla for these kind of questions.

Comment 21 Benjamin Tissoires 2018-02-28 14:47:16 UTC
Created attachment 1401908 [details]
DSDT-fixed-with-probe-v2.ASL

Making progress here. This is the "fixed" DSDT with the probe inserted in the middle. It allows to get traces from the touchpad under Windows.

Comment 22 Benjamin Tissoires 2018-02-28 14:49:55 UTC
Created attachment 1401909 [details]
I2C traces under Windows

Traces from the touchpad under Windows.

The traces are clean. They are consistent with a regular hid-multitouch compatible touchpad, and there do not seem to be any events missing.

We do see touch releases, and when multiple fingers are on the touchpad, we see all of them.

We are currently getting the init sequence, but it seems the issue is not in the touchpad driver.

Comment 23 vivien.frasca 2018-02-28 15:17:05 UTC
Thanks a lot Benjamin for your help.

So, if the problem is not into the touchpad driver, should I open a new issue about i2c kernel module (or i2c_hid) ?

Comment 24 Benjamin Tissoires 2018-02-28 15:27:53 UTC
(In reply to vivien.frasca from comment #23)
> So, if the problem is not into the touchpad driver, should I open a new
> issue about i2c kernel module (or i2c_hid) ?

Nah, it's still a kernel issue, and it occurs I am the one who wrote the i2c-hid driver too. Let's not have multiple issues for the same bug.

Comment 25 Benjamin Tissoires 2018-03-20 15:32:39 UTC
Created attachment 1410541 [details]
I2C initialization traces under Windows

For the record, Vivien managed to get the traces from the inclusion of the HID over I2C device. There is nothing special for a i2c-hid device but some obscure feature 0xff00c4 that is set but the Windows driver.

Comment 26 Hans de Goede 2018-03-21 13:11:39 UTC
> External Bug ID: Linux Kernel 198473

Hmm, that one seems to suggest a stuck IRQ issue. Vivien are you also seeing a high CPU load from an IRQ in top / high interrupt counts in "cat /proc/interrupts" for the touchpad IRQ?

Trying to read data when there is none because we are doing something wrong wrt the interrupt might explain this.

Comment 27 vivien.frasca 2018-03-21 19:45:37 UTC
Here the line about the touchpad, and it is the top one :

            CPU0       CPU1       CPU2       CPU3
 135:     249595          0          0          0  intel-gpio  129  ELAN1200:00

See complete cat here : https://gist.github.com/PapsOu/d0ab0760b5a4b3346cfea9067f476c8a

Comment 28 Hans de Goede 2018-03-22 09:47:09 UTC
(In reply to vivien.frasca from comment #27)
> Here the line about the touchpad, and it is the top one :
> 
>             CPU0       CPU1       CPU2       CPU3
>  135:     249595          0          0          0  intel-gpio  129 
> ELAN1200:00

Ah yeah, that is bad. So we first need to fix the IRQ problem and then maybe with  some luck the rest of the problem goes away.

Can you do:

acpidump -o acpidump.ASUS-FX503VD

And then attach the generated acpidump.ASUS-FX503VD here?

Looking at the ASUS-GL503VD acpi-dump from the kernel-bugzilla the IRQ is declared as:


            Name (SBFG, ResourceTemplate ()
            {
                GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000
                    "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0000
                    }
            })

So as level, active-low.

It seems that hid-i2c devices using an active-low IRQ is normal, although drivers/input/mouse/elan_i2c_core.c, which is for older elan i2c-devices has:

        /*
         * Platform code (ACPI, DTS) should normally set up interrupt
         * for us, but in case it did not let's fall back to using falling
         * edge to be compatible with older Chromebooks.
         */
        irqflags = irq_get_trigger_type(client->irq);
        if (!irqflags)
                irqflags = IRQF_TRIGGER_FALLING;

        error = devm_request_threaded_irq(dev, client->irq, NULL, elan_isr,
                                          irqflags | IRQF_ONESHOT,
                                          client->name, data);

So maybe we should try to force the irqflags to IRQF_TRIGGER_FALLING here too.

But I think it is more likely that we are doing something wrong at the i2c-hid level which is causing the device to keep the IRQ asserted.

Benjamin, maybe the obscure feature thye Windows driver sets configures the IRQ line (from say edge to level operation)? Or maybe the device expects us to read more data then we do, can you check in the traces how much data windows reads per packet and compare that to what the Linux driver does?

Another option may be to make the device use the drivers/input/mouse/elan_i2c* code, but I think this one is a regular HID device, right Benjamin?

Comment 29 Benjamin Tissoires 2018-03-22 10:04:18 UTC
(In reply to Hans de Goede from comment #28)
> (In reply to vivien.frasca from comment #27)
> > Here the line about the touchpad, and it is the top one :
> > 
> >             CPU0       CPU1       CPU2       CPU3
> >  135:     249595          0          0          0  intel-gpio  129 
> > ELAN1200:00
> 
> Ah yeah, that is bad. So we first need to fix the IRQ problem and then maybe
> with  some luck the rest of the problem goes away.

Thanks for spotting that Hans :)

> 
> Can you do:
> 
> acpidump -o acpidump.ASUS-FX503VD
> 
> And then attach the generated acpidump.ASUS-FX503VD here?
> 
> Looking at the ASUS-GL503VD acpi-dump from the kernel-bugzilla the IRQ is
> declared as:
> 
> 
>             Name (SBFG, ResourceTemplate ()
>             {
>                 GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault,
> 0x0000
>                     "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
>                     )
>                     {   // Pin list
>                         0x0000
>                     }
>             })
> 
> So as level, active-low.
> 
> It seems that hid-i2c devices using an active-low IRQ is normal, although
> drivers/input/mouse/elan_i2c_core.c, which is for older elan i2c-devices has:
> 
>         /*
>          * Platform code (ACPI, DTS) should normally set up interrupt
>          * for us, but in case it did not let's fall back to using falling
>          * edge to be compatible with older Chromebooks.
>          */
>         irqflags = irq_get_trigger_type(client->irq);
>         if (!irqflags)
>                 irqflags = IRQF_TRIGGER_FALLING;
> 
>         error = devm_request_threaded_irq(dev, client->irq, NULL, elan_isr,
>                                           irqflags | IRQF_ONESHOT,
>                                           client->name, data);
> 
> So maybe we should try to force the irqflags to IRQF_TRIGGER_FALLING here
> too.

The thing is I remember somebody telling me that they needed to force trigger_falling in some cases, and I think it was Elan for some devices. I can't find the email where this was said.

Vivien it should be easy enough to try by editing the i2c-hid.c file in the out of the tree hid-multitouch repo I gave you earlier (I can push a quick fix for you if it's more convenient).

> 
> But I think it is more likely that we are doing something wrong at the
> i2c-hid level which is causing the device to keep the IRQ asserted.
> 
> Benjamin, maybe the obscure feature thye Windows driver sets configures the
> IRQ line (from say edge to level operation)? Or maybe the device expects us
> to read more data then we do, can you check in the traces how much data
> windows reads per packet and compare that to what the Linux driver does?

We tried setting the exact same setup Windows does, and there was still the issue.

Comparing the i2c-hid debug output from comment #3 and the ones from windows in https://bugzilla.redhat.com/attachment.cgi?id=1401909, in both case we are supposed to read 16 bytes of data, so we are behaving the same. What might be possible though is that the Windows driver changes the IRQ flag somehow instead of fixing the DSDT.

> 
> Another option may be to make the device use the
> drivers/input/mouse/elan_i2c* code, but I think this one is a regular HID
> device, right Benjamin?

It is a regular i2c_hid. IIRC some would work with elan_i2c, but I don't think this one will (gut feeling).

Comment 30 vivien.frasca 2018-03-22 13:33:48 UTC
Created attachment 1411723 [details]
Dump ACPI FX503VD

Hi Hans,

Please find the acpidump for the ASUS FX503VD.

Comment 31 vivien.frasca 2018-03-22 14:02:36 UTC
Created attachment 1411727 [details]
The dmesg with the irqflags set to IRQ_TRIGGER_FALLING

Comment 32 Hans de Goede 2018-03-22 14:12:00 UTC
Hi,

So the dmesg still shows the weird ff packets I see, so I guess the jumps are still there too?

Has the interrupt count changed, specifically is it generating less IRQs now, esp. when no finger is on the trackpad?

Regards,

Hans

Comment 33 vivien.frasca 2018-03-22 14:15:58 UTC
Yes, the jumps and « phantom clics » are still presents even with the correct change on i2c-hid.c.

Comment 34 vivien.frasca 2018-03-22 14:23:31 UTC
Created attachment 1411732 [details]
idle log IRQ each seconds while 10 seconds

for i in {1..10}; do; cat /proc/interrupts | grep "IR-IO-APIC" >> irq_log; echo "------------" >> irq_log; sleep 1; done

Comment 35 vivien.frasca 2018-03-22 14:24:33 UTC
Created attachment 1411733 [details]
active log IRQ each seconds while 10 seconds

for i in {1..10}; do; cat /proc/interrupts | grep "IR-IO-APIC" >> irq_log_moving; echo "------------" >> irq_log_moving; sleep 1; done

Comment 36 Will Roberts 2018-03-22 16:30:54 UTC
Hi all,

I'm writing to note a related issue I raised on bugzilla-kernel, which is already linked to this bug, as noted by Hans:
https://bugzilla.kernel.org/show_bug.cgi?id=198473

That bug references issues reported on ASUS GL503VD and GL503VM notebooks running Ubuntu 17.10 and Mint 18.3, not Fedora, and the Elantech device in question has ID 04F3:3090, while the issues reported here happen on a touchpad with ID 04F3:303E.  Vivien here is reporting phantom right-click events, I think, which I don't observe; rather, my touchpad generates random left-click events when tap-to-touch is enabled.  Nevertheless, I think there are some strong similarities, namely the jumpy cursor, and the overactive IRQ issue.

I wanted to draw attention to some observations on the bugzilla-kernel issue that might also be reproducible by Vivien and could be relevant:

1) It is possible to hang the touchpad, causing it to stop reporting events to libinput.  I can do this reproducibly by doing a five-finger tap.
2) The IRQ issue is visible in top as a process named irq/131-ELAN120.
3) The jumpiness of the cursor is mildly improved by increasing the priority of this IRQ process, but the touchpad is still too hard to use to count this as a workaround.

OK, that's all.  I'll watch here and on the bugzilla-kernel in case there's any new activity, and would be happy to help diagnose the problem in any way I can.

Best, Will

Comment 37 Hans de Goede 2018-03-22 19:04:34 UTC
Hi,

I was actually mostly interested in this IRQ:


            CPU0       CPU1       CPU2       CPU3
 135:     249595          0          0          0  intel-gpio  129  ELAN1200:00

But judging from the i2c-controller IRQs that one is not triggering any more when not using the trackpad, correct?

And I also guess that it does trigger continuously when not forcing the irq to falling edge?

Comment 38 vivien.frasca 2018-03-22 20:17:20 UTC
Will,

I can reproduce every points you listed before :

1) a five-finger tap freeze the device (in fact, the dmesg in debug mode is displaying the same packet line : mars 22 21:05:54 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 0b 00 01 00 00 00 00 00 00 00 00

2) The process seen in top command is named irq/135-ELAN120 and is stuck at 3.7% of CPU usage.

3) I haven't tried to nice the process, because I suppose that it will probably cause a battery drain.

I'm not a C developer (only a PHP one), but I think this high IRQ process is a consequence of something that is going wrong somewhere at kernel level. It's only a supposition, I'm probably wrong.

Comment 39 vivien.frasca 2018-03-22 21:58:55 UTC
Created attachment 1411869 [details]
IRQ intel-gpio log

Hans, the IRQ is still triggered even not using the touchpad.

Comment 40 vivien.frasca 2018-03-22 22:27:22 UTC
Will, Hans, Benjamin, do you think the IRQ could be the cause of that laggy cursor ?

Comment 41 Benjamin Tissoires 2018-03-23 08:00:34 UTC
Yes, the fact that the IRQ is continuously triggered messes up everything. We spend our time banging at the touchpad and this probably confuses the firmware in a sense, and takes a lot of CPU time for nothing.

Comment 42 Hans de Goede 2018-03-23 08:25:28 UTC
(In reply to vivien.frasca from comment #39)
> Hans, the IRQ is still triggered even not using the touchpad.

Hmm, that is very strange, I think something may have gotten wrong with changing the irq-type to falling-edge.

You may be able to see the IRQ-type under:

cat /sys/kernel/debug/gpio

And/or:

cat /sys/kernel/debug/pinctrl/*/pins

Comment 43 vivien.frasca 2018-03-23 12:17:01 UTC
Created attachment 1412071 [details]
IRQ pins

I've found a strange thing.

When I am probing the modifyed module,

make && sync && sudo modprobe -r hid_multitouch i2c-hid && sudo insmod ./hid-multitouch.ko && sudo modprobe i2c_hid debug=1 && journalctl --follow

I've got normal init debug messages.

-- Logs begin at Tue 2018-03-06 10:24:50 CET. --
mars 22 21:23:14 localhost.localdomain kernel: mt_set_switches setting surface and button switch to 1 and 1 /home/papsou/Softwares/Tools/hid-multitouch/hid-multitouch.c:1257
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: i2c_hid_set_or_send_report
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: __i2c_hid_command: cmd=05 00 35 03 06 00 05 00 05 03 00
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: i2c_hid_set_power
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: __i2c_hid_command: cmd=05 00 01 08
mars 22 21:23:14 localhost.localdomain audit[7182]: USER_END pid=7182 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
mars 22 21:23:14 localhost.localdomain sudo[7182]: pam_unix(sudo:session): session closed for user root
mars 22 21:23:14 localhost.localdomain audit[7182]: CRED_DISP pid=7182 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: i2c_hid_set_power
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: __i2c_hid_command: cmd=05 00 00 08
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: i2c_hid_set_power
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: __i2c_hid_command: cmd=05 00 01 08
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: i2c_hid_set_power
mars 22 21:23:14 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: __i2c_hid_command: cmd=05 00 00 08

When I'm doing the five-finger tap, the following line is continuously shown in journalctl --follow.

mars 22 21:24:30 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: 0b 00 01 00 00 00 00 00 00 00 00

The only way to stop this flood is to probe again the module.

But when probing again the module, the flood does not stop, but the line is not the same. Here it's the famous « ff » that is repeated continuously.

mars 22 21:24:41 localhost.localdomain kernel: i2c_hid i2c-ELAN1200:00: input: ff

I don't know if it will help you...

Hans, here informations about the irqtype:

cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 320-511, parent: platform/INT345D:00, INT345D:00:

cat /sys/kernel/debug/pinctrl/INT345D:00/pins
(see attachment)

Comment 44 Hans de Goede 2018-03-23 13:08:47 UTC
So, assuming that the 129 from:

            CPU0       CPU1       CPU2       CPU3
 135:     249595          0          0          0  intel-gpio  129  ELAN1200:00

Is the pin number (the ACPI table hides this in a GPDI variable which is set in nvram, so I cannot see this), then this pinctrl entry matches it:

pin 129 (L_BKLTEN) mode 1 0x40800500 0x00000039

And the 0x40 indicates it is level triggered, the "mode 1" part is also suspicious, if intel_gpio_irq_type was ever called this should be "GPIO".

So it seems that perhaps your patch to set the irq-type is not working, or something else is going on.

Can you attach your patch for setting the irq-type please?

Comment 45 Hans de Goede 2018-03-23 13:11:23 UTC
And maybe try an explicit irq_set_irq_type() call on i2c_dev->irq rather then passing flags when requesting the interrupt, and see if that changes the output of:

cat /sys/kernel/debug/pinctrl/INT345D:00/pins | grep "pin 129"

Comment 46 vivien.frasca 2018-03-23 14:46:54 UTC
Hans, the modifyed file is here : https://github.com/bentiss/hid-multitouch/pull/1/files

Comment 47 Hans de Goede 2018-03-23 17:42:45 UTC
(In reply to vivien.frasca from comment #46)
> Hans, the modifyed file is here :
> https://github.com/bentiss/hid-multitouch/pull/1/files

Looks reasonable, but as said try doing an explicit irq_set_irq_type() after doing the request-irq, there is some magic happening with ACPI GpioInts uner the hood, so it could be the flag to request_irq is ignored.

Comment 48 vivien.frasca 2018-03-24 22:04:45 UTC
Hans, I'm sorry but I really don't know how to change the irq mode.

I tryed adding some debug messages (see the commit https://github.com/PapsOu/hid-multitouch/commit/1ab08e4c02a8c4941f449df47ffa7e7e2d6c8091#diff-0287bcc1d87579c3d25fe65a28c83aed) but I never see them. I think the function « i2c_hid_init_irq » is never called. 

May be it is why the IRQs are triggered too much (because the IRQ strategy is not correctly set)

Comment 49 vivien.frasca 2018-03-24 22:42:17 UTC
Hans, please forget my previous message.

In fact I have done an epic fail on the way I'm probing the i2c_hid module.

Is was doing it wrong :

make && sync && sudo modprobe -r hid_multitouch i2c-hid && sudo insmod ./hid-multitouch.ko && sudo modprobe i2c_hid debug=1

But the part « sudo modprobe i2c_hid debug=1 » was probing the embedded mod, not the modified one.

So using this command prints me my debug messages...

make && sync && sudo modprobe -r hid_multitouch i2c-hid && sudo insmod ./hid-multitouch.ko && sudo insmod ./i2c_hid.ko debug=1

Well, I've tryed to set the flag to each values OF IRQF_TRIGGER_* found at https://elixir.bootlin.com/linux/latest/source/include/linux/interrupt.h#L31 without any improvement. I've noticed that IRQF_TRIGGER_PROBE was doubling the CPU usage for the process irq/135-ELAN120 (7.8% instead of 3.9%) even when not using the touchpad.

Comment 50 vivien.frasca 2018-03-25 20:33:36 UTC
Hans, Benjamin,

in function static int i2c_hid_init_irq(struct i2c_client *client) (line 801 of i2c_hid.c) i've added this line to force the IRQ type as you (Hans) suggested :

forceIrq = irq_set_irq_type(client->irq, IRQ_TYPE_DEFAULT); (see file https://github.com/PapsOu/hid-multitouch/blob/ee47a83b11f1673071507b727a0998a5d9ae343b/i2c-hid.c#L801)

I've tryed all values found here https://elixir.bootlin.com/linux/v4.0/source/include/linux/irq.h#L39 and the only value that improve the move is IRQ_TYPE_DEFAULT.

The cursor move correctly few seconds and then return to the laggy mode...sometimes it go back to the smooth mode (a normal mode).

The module seems to be very unstable and I don't know what is the event that switch the cursor move from laggy to normal or inverse...

Comment 51 Benjamin Tissoires 2018-03-26 07:12:41 UTC
(In reply to vivien.frasca from comment #50)
> in function static int i2c_hid_init_irq(struct i2c_client *client) (line 801
> of i2c_hid.c) i've added this line to force the IRQ type as you (Hans)
> suggested :
> 
> forceIrq = irq_set_irq_type(client->irq, IRQ_TYPE_DEFAULT); (see file
> https://github.com/PapsOu/hid-multitouch/blob/
> ee47a83b11f1673071507b727a0998a5d9ae343b/i2c-hid.c#L801)
> 
> I've tryed all values found here
> https://elixir.bootlin.com/linux/v4.0/source/include/linux/irq.h#L39 and the
> only value that improve the move is IRQ_TYPE_DEFAULT.

IRQ_TYPE_DEFAULT should not be used except for initialization. It will basically enable polling as it will consider the IRQ always set.

> The cursor move correctly few seconds and then return to the laggy
> mode...sometimes it go back to the smooth mode (a normal mode).

I guess it is because you are polling, and sometime you have the CPU or the FW ready to accept the storm of events, and sometimes the FW must be confused.

> 
> The module seems to be very unstable and I don't know what is the event that
> switch the cursor move from laggy to normal or inverse...

Hans asked you to set the IRQW flag to 'IRQ_TYPE_EDGE_FALLING|IRQF_ONESHOT' *after* the call to request_threaded_irq().

Could you give this a try and report?

Comment 52 Hans de Goede 2018-03-26 07:52:27 UTC
(In reply to Benjamin Tissoires from comment #51)
> Hans asked you to set the IRQW flag to 'IRQ_TYPE_EDGE_FALLING|IRQF_ONESHOT'
> *after* the call to request_threaded_irq().
> 
> Could you give this a try and report?

irq_set_irq_type() does not take IRQF values, just the type, so just:

       irq_set_irq_type(client->irq, IRQ_TYPE_EDGE_FALLING);

Also please see if this changes anything in the output of:

cat /sys/kernel/debug/pinctrl/INT345D:00/pins | grep "pin 129"

Comment 53 vivien.frasca 2018-03-26 11:32:21 UTC
Hans,Benjamin,

I've set the IRQ type after the call of request_threaded_irq() function. (see https://github.com/PapsOu/hid-multitouch/commit/7645bd3699d6bd367ebe18f6e65d214d4bf576ab)

I don't notice any improvement in the cursor move.

Here are the pins report before and after :

BEFORE : pin 129 (L_BKLTEN) mode 1 0x40800500 0x00000039
AFTER : pin 129 (L_BKLTEN) mode 1 0x42800500 0x00000039

I've tested each values of IRQ_TYPE_* without any improvements (there is still the effect as described in comment #50 but not only with IRQ_TYPE_DEFAULT. IRQ_TYPE_LEVEL_HIGH has produced the same effect with the same instability.)

Comment 54 Hans de Goede 2018-03-26 14:55:50 UTC
Hi Vivien,

This is really weird, I've send a mail to the Intel GPIO/pinctrl driver maintainers asking for help, with you and Benjamin in the Cc.

Regards,

Hans

Comment 55 vivien.frasca 2018-03-27 11:18:25 UTC
Created attachment 1413684 [details]
dmesg of patch f5a26ac

For the record,

We have tryed a kernel patch (https://github.com/torvalds/linux/commit/f5a26acf0162477af6ee4c11b4fb9cffe5d3e257.patch) on kernel 4.15.3 to see if this patch solves the touchpad issue.

Tests are failing because of a black screen apparently caused by applying this patch on kernel 4.15.3. This unexpected behavior has been spotted with official fedora kernels from 4.15.4 to current 4.15.10-300.

Please find attached the logs asked by Mika by mail.

Comment 56 vivien.frasca 2018-03-27 11:19:23 UTC
Created attachment 1413685 [details]
interrupts of patch f5a26ac

Comment 57 vivien.frasca 2018-03-27 11:19:55 UTC
Created attachment 1413689 [details]
pins of patch f5a26ac

Comment 58 Mika Westerberg 2018-03-27 11:41:39 UTC
OK, now the pin is "properly" configured:

  pin 129 (L_BKLTEN) GPIO 0x40800100 0x00000039

The above also says that the pin is configured to trigger an interrupt when the line is active low and it currently is so you get these interrupts all the time:

  135:     132638          0          0          0  intel-gpio  129  ELAN1200:00

This is pretty much looks like a configuration issue.

We could try now to change triggering from level to edge, it should at least prevent the interrupt storm. Can you do following change to drivers/hid/i2c-hid/i2c.hid.c::i2c_hid_init_irq()?

        irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
        ret = request_threaded_irq(client->irq, NULL, i2c_hid_irq,
                                   irqflags | IRQF_ONESHOT, client->name, ihid);

Comment 59 vivien.frasca 2018-03-27 12:10:19 UTC
Created attachment 1413696 [details]
dumps of changing irq type in i2c-hid.c

Mika, please find the sames logs with the i2c-hid module patched

Comment 60 Mika Westerberg 2018-03-27 12:46:31 UTC
OK, I suppose nothing changed?

Could you still try to change

  irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;

to

  irqflags = IRQF_TRIGGER_RISING;

and retry? It is possible that now the touchpad does now work at all but you should not see the interrupt storm either.

Comment 61 vivien.frasca 2018-03-27 13:06:10 UTC
Sorry, yes, there are no changes.

I'll try setting the irqf as IRQF_TRIGGER_RISING only soon.

Note that I have commented set irq_set_irq_type call done previously for testing the irq type (see https://github.com/PapsOu/hid-multitouch/commit/0327a6a50f67d71edc98b83ef5b1edbb5fa11d84).

I'll test this IRQF setting soon and I will add dumps.

« It is possible that now the touchpad does now work at all » with the black screen I'll won't be able to tell you if the touchpad works or not :-D

Comment 62 Andy Shevchenko 2018-03-27 17:27:15 UTC
If interrupt line shows interrupts independently on the flag (level vs. edge) I can come up with a theory that it's just a floating pin. Means that the ping number in the BIOS is simple wrong by some reason and actual line is different. Would be nice to have schematics of the device, though it might be harder to get than trial-and-error approach.

Comment 63 Andy Shevchenko 2018-03-27 17:28:57 UTC
(In reply to vivien.frasca from comment #61)
> I'll test this IRQF setting soon and I will add dumps.
> 
> « It is possible that now the touchpad does now work at all » with the black
> screen I'll won't be able to tell you if the touchpad works or not :-D

IIUC you may just run od -Ax -x on certain /dev/input to see the events.

Comment 64 Hans de Goede 2018-03-27 17:54:31 UTC
For a quick test to just check that the touchpad is still generating input events you can do:

sudo dnf install evemu

evemu-record

<select input node for touchpad>
<move finger over touchpad>

I wonder if what we're seeing as interrupts is not just noise on the long lines to the touchpad and if maybe we need something similar to:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/intel?id=9291c65b01d1c67ebd56644cb19317ad665c44b3
for the sunrisepoint gpio controller?

Mika, can you check if the sunrisepoint gpio controller has a glitch filter and maybe create a patch to test if this helps?

Comment 65 Andy Shevchenko 2018-03-27 18:25:15 UTC
(In reply to Hans de Goede from comment #64)
> I wonder if what we're seeing as interrupts is not just noise on the long
> lines to the touchpad and if maybe we need something similar to:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> drivers/pinctrl/intel?id=9291c65b01d1c67ebd56644cb19317ad665c44b3
> for the sunrisepoint gpio controller?
> 
> Mika, can you check if the sunrisepoint gpio controller has a glitch filter
> and maybe create a patch to test if this helps?

Can you try to set bits 24 and 29 in PADCFG0 ?

Comment 66 Hans de Goede 2018-03-28 07:43:30 UTC
Vivien,

(In reply to Andy Shevchenko from comment #65)
> Can you try to set bits 24 and 29 in PADCFG0 ?

To do this, edit:

drivers/pinctrl/intel/pinctrl-intel.c

And in the intel_gpio_irq_type() function, under the:

        value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);

Line (line 980 in my copy) add:

        value |= BIT(29) | BIT(24);

And see if that makes the IRQ trigger less often.

Regards,

Hans

Comment 67 vivien.frasca 2018-03-28 11:32:58 UTC
Hans, Andy,

I've changed the value assignment in pinctrl-intel.c

 918 static int intel_gpio_irq_type(struct irq_data *d, unsigned type)
 919 {
[...]
 947         value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);
>948     value |= BIT(29) | BIT(24);
 949
 950         if ((type & IRQ_TYPE_EDGE_BOTH) == IRQ_TYPE_EDGE_BOTH) {
 951                 value |= PADCFG0_RXEVCFG_EDGE_BOTH << PADCFG0_RXEVCFG_SHIFT;
 952         } else if (type & IRQ_TYPE_EDGE_FALLING) {
 953                 value |= PADCFG0_RXEVCFG_EDGE << PADCFG0_RXEVCFG_SHIFT;
 954                 value |= PADCFG0_RXINV;
 955         } else if (type & IRQ_TYPE_EDGE_RISING) {
 956                 value |= PADCFG0_RXEVCFG_EDGE << PADCFG0_RXEVCFG_SHIFT;
 957         } else if (type & IRQ_TYPE_LEVEL_MASK) {
 958                 if (type & IRQ_TYPE_LEVEL_LOW)
 959                         value |= PADCFG0_RXINV;
 960         } else {
 961                 value |= PADCFG0_RXEVCFG_DISABLED << PADCFG0_RXEVCFG_SHIFT;
 962         }

The elan1200 irq process was at 7.4% of CPU usage.

Should I remove the previous patches ? Should I reset my tests done with Benjamin on hid-multitouch and i2c_hid modules before trying any changed requested here ?

About the black screen, I've noticed just now that the screen is not turned off, actually it is its brightness that is set to a value near 0 (I can see the GDM user list (only the contrasted user icons that are as visible as finger prints on the screen))

Comment 68 vivien.frasca 2018-03-28 12:21:21 UTC
Created attachment 1414160 [details]
IRQ cat loop (Bit 29 | Bit 24)

Comment 69 Hans de Goede 2018-03-28 13:07:50 UTC
(In reply to vivien.frasca from comment #67)
> About the black screen, I've noticed just now that the screen is not turned
> off, actually it is its brightness that is set to a value near 0 (I can see
> the GDM user list (only the contrasted user icons that are as visible as
> finger prints on the screen))

Hmm and the pin is called L_BKLTEN aka backlight-enable. So I guess that the pin is being used as it name says and is controlling your backlight, which explains why the patch to actually put it in GPIO mode makes the screen go dark.

So we are either misinterpreting the index the GPIO ACPI resource wrongly; or the ACPI table is buggy.

Looking closer at the ACPI table I think our pin-numbering in
projects/linux/drivers/pinctrl/intel/pinctrl-sunrisepoint.c is wrong and that is the issue.

The ACPI table has:

            Name (SBFG, ResourceTemplate ()
            {
                GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000
                    "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0000
                    }
            })

and:

            CreateWordField (SBFG, 0x17, INT1)

and:

                INT1 = GNUM (GPDI)

and:

        Method (GNUM, 1, NotSerialized)
        {
            Local0 = GNMB (Arg0)
            Local1 = GGRP (Arg0)
            Return ((Local0 + (Local1 * 0x18)))
        }

Note GPDI comes from somewhere else, so we don't know what it is by just looking at the ACPI table, but since we get 129, we can deduce this back to gpio-group 5 (aka GPP_F) pin 9.

Looking at drivers/pinctrl/intel/pinctrl-sunrisepoint.c, it has:

#define SPT_COMMUNITY(b, s, e)                          \
        {                                               \
                .barno = (b),                           \
                .padown_offset = SPT_PAD_OWN,           \
                .padcfglock_offset = SPT_PADCFGLOCK,    \
                .hostown_offset = SPT_HOSTSW_OWN,       \
                .ie_offset = SPT_GPI_IE,                \
                .gpp_size = 24,                         \
                .gpp_num_padown_regs = 4,               \
                .pin_base = (s),                        \
                .npins = ((e) - (s) + 1),               \
        }

So this confirms the 24 pins per group. So it seems that the ACPI code (on this laptop) expects unused pins to be skipped, looking at sptlp_pins[] all except for the last bank contain 24 pins, so there is no difference between a sparse / packed interpretation of the numbers.

But *BUT* with spth_pins[], which is the one which is used here, banks A-D are 24 pins, but bank E is only 13 pins, so starting at bank F the numbering no longer matches between a sparse / packed interpretation.

So when we decode the 129 from the ACPI table we end up at bank/group F (correct) but at pin number 20 rather then pin number 9, due to bank E skipping 11 pins.

I believe that this explains both the blackscreen issue and the interrupt storm issue.

I'm not familiar enough with the Intel pinctrl drivers to come up with a fix for this, nor am I sure that adding a hole in the pin-numbering between pin 108 and 120 (skipping 109 t/m 119) is the right thing to do for all devices out there.

Although my gut tells me that the Windows drivers likely use the same bank + pin numbering scheme for Sunrise Point LP and Sunrise Point H, so adding the hole is the right thing to do.

Mike or Andy, can you write a patch for Vivien to test this?

Comment 70 Hans de Goede 2018-03-28 13:20:05 UTC
p.s.

I also believe that not having the hole is causing issues for the intel_pad_acpi_mode() code.

E.g. pins 109-119 are wrongly thought to be part of GPP_E as intel_pinctrl_add_padgroups() will have assumed 24 pins per group.

Comment 71 Mika Westerberg 2018-03-28 13:30:30 UTC
Hans, good catch! I'll try to come up a patch soon.

Comment 72 Mika Westerberg 2018-03-28 13:54:31 UTC
Created attachment 1414193 [details]
Fix SPT-H pin numbering to follow BIOS and Windows

Here is a patch that tries to take these gaps into account. We actually fixed similar for Cannon Lake (but there the "bank" size is 32 instead) so there is support for this in the core driver but it was never fixed for SPT-H (IIRC -LP does not require it since all the HW groups have 24 pins).

You need this commit from mainline as well:

a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups")

Comment 73 vivien.frasca 2018-03-28 14:04:15 UTC
Mika,

I'm applying this patch (https://github.com/torvalds/linux/commit/a60eac3239f01838bdd34eaac8c486c4c6e84551.patch) and I will apply yours. But, before getting ahead, should I remove all previous tests patches we've done on pinctrl-intel.c, i2c-hid.c and hid-multitouch.c ?

Thanks for your answer.

Comment 74 Mika Westerberg 2018-03-28 14:09:43 UTC
Yes, I think you don't need those anymore. It is now pretty clear where the problem is (thanks to Hans' analysis).

Comment 75 vivien.frasca 2018-03-28 14:49:10 UTC
Created attachment 1414255 [details]
/proc/interrupts

I've applyed the patch on the kernel 4.15.3 but the brightness problem is still here.

the output of /proc/interrupts has changed

the command `sudo od -Ax -x /dev/input/by-path/pci-0000:00:15.0-platform-i2c_designware.0-event-mouse` executed through ssh displays a lots of device events and seems to be smooth.

So because the screen is still dark, I can't confirm the patch solves the problem.

Comment 76 Hans de Goede 2018-03-28 14:53:58 UTC
Can you try turning the laptop off, wait 30 seconds and then turn it back on again?

The messed up GPIO settings from the previous wrong mapping may persist over a reboot.

Also check /sys/kernel/debug/pinctrl/*/pins output for pin 129, it should be back in "mode 1" again.

Comment 77 vivien.frasca 2018-03-28 15:03:29 UTC
Created attachment 1414271 [details]
pinctrl

Comment 78 vivien.frasca 2018-03-28 15:03:56 UTC
The screen is still black.

Comment 79 Mika Westerberg 2018-03-28 15:21:30 UTC
The backlight pin is still in the same mode:

pin 129 (L_BKLTEN) GPIO 0x40800100 0x00000039

Are you able to disconnect the battery, wait a while and connect it back? That should reset the pins.

Comment 80 Hans de Goede 2018-03-28 15:25:13 UTC
Hmm, so either the pin-mapping fix is incomplete, or the GPIO setting for the BKLTEN pin is persisting.

2 questions:

1) Can you boot a known good kernel (wrt backlight) and check that the backlight returns to normal then

2) Give us a list of patches you are applying on top of the known good kernel?

Comment 81 vivien.frasca 2018-03-28 15:52:47 UTC
1) The backlight is ok on kernel 4.15.3-300 (the official one)

2) I've applied only those patches :
- https://github.com/torvalds/linux/commit/a60eac3239f01838bdd34eaac8c486c4c6e84551.patch
- https://bugzilla.redhat.com/attachment.cgi?id=1414193

On kernel 4.15.3 picked up on https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.15.3.tar.gz

Comment 82 Mika Westerberg 2018-03-28 16:02:55 UTC
Can you attach contents of /sys/kernel/debug/pinctrl/INT345D:00/gpio-ranges here as well with the patched kernel?

Comment 83 Hans de Goede 2018-03-28 16:05:06 UTC
So if you reboot from 4.15.3-300 into your own 4.15.3 with just those 2 patches you get the black screen issue and pin 129 shows as GPIO rather then "mode 1" in the pins file?

And if you then reboot back into the official 4.15.3-300, things are fixed again, (please also check the pin 129 setting in the pins file), correct?

So it seems that the flags are not stuck and a reboot into a working kernel is enough to get back to a working condition, correct?

Mika could it be we are doing the mapping twice here? cat /proc/interrupts now shows pin 140 rather then 129, which seems correct, but:
https://github.com/torvalds/linux/commit/a60eac3239f01838bdd34eaac8c486c4c6e84551.patch

Also does a lookup which means we are doing the translation twice, or did only the name of the irq change and not the number stored internally?

Comment 84 vivien.frasca 2018-03-28 16:16:15 UTC
- Rebooting from 4.15.3-300 to 4.15.3

Still the black screen : 

sudo cat /sys/kernel/debug/pinctrl/INT345D:00/pins | grep 129
pin 129 (L_BKLTEN) GPIO 0x40800100 0x00000039

- Rebooting from 4.15.3 to 4.15.3-300

No black screen

sudo cat /sys/kernel/debug/pinctrl/INT345D:00/pins | grep 129
pin 129 (L_BKLTEN) mode 1 0x40800500 0x00000039

Rebooting twice from 4.15.3 to 4.15.3 does not change anything.

Do you think that I should apply patches on a more recent kernel (4.15.10 for example ?)

I've built the 4.15.3 because it was the more recent kernel that is usable.

Should I build from 4.15.10 ?

Comment 85 Mika Westerberg 2018-03-28 16:22:21 UTC
Regarding mapping twice, there is one more commit which I forgot:

03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")

Vivien, could you add that as well and try again? Please include contents of /sys/kernel/debug/pinctrl/INT345D:00/gpio-ranges and /sys/kernel/debug/pinctrl/INT345D:00/pins after that.

Comment 86 vivien.frasca 2018-03-28 19:49:12 UTC
Created attachment 1414370 [details]
GPIO pins and ranges

Mika,

I'm writing from the fedora using the kernel 4.15.3 with the patches listed before.

The touchpad works well and the black screen problem is solved !

See the pins configuration attached.

So your patch seems to solve the problem.

I've noticed only one problem, described by Will in comment #36 https://bugzilla.redhat.com/show_bug.cgi?id=1543769#c36 , when taping with 5 fingers, the touchpad does not respond to any events, the command `sudo od -Ax -x /dev/input/by-path/pci-0000:00:15.0-platform-i2c_designware.0-event-mouse` prints nothing. I've spotted nothing in dmesg when it occurs.

Comment 88 vivien.frasca 2018-03-28 20:48:27 UTC
Created attachment 1414375 [details]
interrupts after suspend

Hum, after a suspend mode (triggered when closing the laptop lid), the touchpad is laggy again (I can see the irq process in top again).

The pins have changed after the suspend (see the diff bellow, see the full diff here https://gist.github.com/PapsOu/64098a07a34feb54b52e423cacd8767d/revisions):

registered pins: 192
[...]
pin 47 (SML1ALERTB) mode 1 0x44000702 0x00000047
[...]
pin 118 (SATA_DEVSLP_7) GPIO 0x80080102 0x0000002e
[...]
pin 158 (SRCCLKREQB_7) mode 1 0x44000702 0x00000056 [ACPI]
[...]
pin 183 (DDSP_HDP_2) mode 1 0x44000702 0x0000006f
[...]

See interrupts attached

Should I build the kernel with previous patches with kernel version 4.15.10 in order to check if this suspend problem have been fixed after kernel 4.15.3 ?

Comment 89 Hans de Goede 2018-03-28 20:56:17 UTC
Vivien,

Thanks for all your testing on this, things definitively seem to be going in the right direction, as for the problems after a suspend/resume, those do not seem to be GPIO setting related. All the changes seem to be in bit 1 (mask 0x00000002) of the first register, which the RX bit, if you do a third dump for some pins this bit will likely be different again.

Can you try doing a "rmmod i2c-hid && modprobe i2c-hid" after a suspend/resume and see if that makes things better?

As for the 5 finger down hangs the touchpad controller issue. "rmmod i2c-hid && modprobe i2c-hid" restores functionality after that right?

So I guess we will need a dump of the i2c packets from a 5 finger tap of death, if we can recognize that the touchpad is going to hang we can re-initialize it, if we cannot recognize this I'm not sure if there is much we can do other then to tell people to not do that.

Regards,

Hans

Comment 90 vivien.frasca 2018-03-29 08:04:01 UTC
Created attachment 1414613 [details]
dmesg i2c-hid init sequence failed

Hans,

For the two cases, probing again the original i2c module works.

Benjamin, I've tryed to probe again your modified version (for-vivien branch) but the init sequence seems to fail (see attached dmesg).

Please tell me what to do to trace the famous 5 fingers tap of the death ?

Thanks a lot.

Comment 91 Benjamin Tissoires 2018-03-29 08:14:53 UTC
Now I am confused. Vivien, could you clarify:
- suspend/resume is broken, rmmod/modprobe i2c-hid fixes the issue?
- 5 finger taps of the death can be fixed too by rmmod/modprobe i2c-hid?

the 2 failed dmesg you showed were with the modified i2c-hid? And this version had a different IRQF_* flag? if so, you can just discard those as if you are not setting the proper flags, it's normal to be confused with the firmware.

Could you confirm the above, also tell me if rmmod/modprobe hid-multitouch only fixes the various issues, and finally, could you attach a hid-recorder of the 5 finger tap of the death?

Comment 92 vivien.frasca 2018-03-29 08:41:33 UTC
Created attachment 1414642 [details]
5 fingers tap trace

Benjamin,

I've checked out the commit 878681f of my fork (after you made the init sequence).

The module is ok (I can see the event dumps in journalcrl --follow).

The problem with suspend and 5 fingers is still here.

Please find in attachment a piece of dmesg seen when doing the 5 fingers tap.

I did the tap at "mars 29 10:34:45".

Comment 93 Hans de Goede 2018-03-29 09:12:30 UTC
(In reply to vivien.frasca from comment #92)
> Please find in attachment a piece of dmesg seen when doing the 5 fingers tap.

Vivien, those weird ff packets are still there, this is with a kernel with the 3 commits you mentioned in comment 87 I assume? And despite the ff packets the touchpad now works smoothly (and the high irq count / irq cpu load is gone), right?

Benjamin, let me summarize things so far:

1) There is an IRQ mapping problem, Mika has fixed this and this seems to fix the orginal complaint of the touchpad causing jerky mouse movement as well as a high IRQ load.

2) There is a problem where the touchpad stops working after suspend/resume, doing a manual rmmod + modprobe i2c-hid fixes this.
This somewhat reminds me of: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728244  I've a feeling we may need to issue a reset command after a suspend/resume at least on some device, might be best to simply do it everywhere.

3) When tapping the touchpad with 5 fingers the firmware gets confused and a manual rmmod + modprobe i2c-hid is necessary to fix this. Looking at the trace attached in comment 92 it seems that we may be able to detect this and issue a reset.

Mika, it seems the remaining issues are something to be dealt with in the i2c-hid code, can you submit the patch fixing the Sunrise Point H gpio mapping upstream please?

Comment 94 Mika Westerberg 2018-03-29 09:18:46 UTC
Hans, sure I'll submit it later today.

Comment 95 Benjamin Tissoires 2018-03-29 09:36:04 UTC
Regarding the 5 fingers tap issue, once it has been triggered by the user, the firmware turns off the multitouch mode and reverts to mouse emulation. It's definitively a firmware issue, and it would be interesting to check if Windows has the same problem. I think under Windows you might still have the pointer moving but you should lose the dual finger scroll if it is enabled.

There is a high chance reloading hid-multitouch will fix that because it'll ask the touchpad to switch back to multitouch. This should be easily detected in the kernel, but a firmware upgrade would be better :)

Regarding the suspend/resume, I'll also need the i2c-hid debug traces after the suspend/resume. If the mouse emulation is also enabled, there is something wrong and the i2c-hid debug traces would show why.

Comment 96 vivien.frasca 2018-03-29 12:17:39 UTC
(In reply to Hans de Goede from comment #93)
> (In reply to vivien.frasca from comment #92)
> > Please find in attachment a piece of dmesg seen when doing the 5 fingers tap.
> 
> Vivien, those weird ff packets are still there, this is with a kernel with
> the 3 commits you mentioned in comment 87 I assume? And despite the ff
> packets the touchpad now works smoothly (and the high irq count / irq cpu
> load is gone), right?

Yes, you're right for all points.

Benjamin, I continuously got this line when waking up from suspend :

[13693.282722] i2c_hid i2c-ELAN1200:00: input: ff

Its stop when probing again the module.

Comment 97 vivien.frasca 2018-03-29 13:52:08 UTC
Created attachment 1414777 [details]
dmesg wak up after suspend

Please find a more accurate dmesg when waking up the laptop

Comment 98 vivien.frasca 2018-03-29 20:16:16 UTC
Benjamin,

I've tested on Windows 10 the five-finger tap, and it seem that is it completely ignored by the driver. Doing a five-finger scroll triggers the same event than a four finger scroll (show desktop overview). There is no freeze, the multitouch mode is still active after the five-finger tap (I was able to scroll in a file explorer with two fingers). May be limiting the supported number of finger to 4 could avoid this freeze ?

I also noticed something strange after suspend/wake up. When closing the laptop lid after a first suspend/wake up, the LED « airplane mode » is turned on (but I still have wifi activated and working nice). Also, when closing again the lid, it does not trigger the suspend mode (the screen is turned off because I can see a black screen when quickly opening the lid).

So probing again i2c-hid reset the touchpad, but it seems that something else going wrong for the lid event, the airplane led. Is it related to the GPIO mapping that seems to be changed after a suspend/wake up ?

Comment 99 Will Roberts 2018-03-30 10:23:47 UTC
Hi Vivien,

I can confirm on my GL503VD that the lid switch works once only (i.e., the first time I close the lid, the machine suspends; when I open it again, it wakes up; thereafter, closing the lid just turns off the screen, but, once the machine is suspended, opening the lid will wake it back up).  My dmesg will have a line like this:

ACPI: button: The lid device is not compliant to SW_LID.

I mention this because I haven't installed the patches in this thread, and I've always had this behaviour, so I'm suggesting that it's unrelated to the touchpad or GPIO.  I've tried kernel options button.lid_init_state=ignore and button.lid_init_state=open, but neither of these make the problem go away.  I've got the system setup so that the power button makes the machine go to sleep, so I've just learned to push that before I shut the lid.

Also, I have the airplane mode LED on after suspend, and I suspect this is also not related to the touchpad.  There are other threads online about people with Asus machines who have the same behaviour:

https://gist.github.com/GMMan/def55b688289f52b8635f1a83c25b1b5
https://gist.github.com/maty974/a72eece781917e133514b3d322c08005

Best, Will

Comment 100 vivien.frasca 2018-04-01 16:04:42 UTC
Created attachment 1415875 [details]
5 finger tap W10 traces

Benjamin,

Please find a SPB trace log done on the Windows 10 with your probe driver.

Hope this will help.

Regards,
Vivien

Comment 101 vivien.frasca 2018-04-04 19:32:17 UTC
Created attachment 1417398 [details]
Kernel crash report after suspend

Please find attached a kernel report (not reportable by abrt because of tainted module nvidia)

I had this crash after a classic suspend/resume. Hope this report will give you enough information to find the problem related to the lost of the working touchpad.

Comment 102 Hans de Goede 2018-04-05 11:25:19 UTC
(In reply to vivien.frasca from comment #101)
> Created attachment 1417398 [details]
> Kernel crash report after suspend
> 
> Please find attached a kernel report (not reportable by abrt because of
> tainted module nvidia)
> 
> I had this crash after a classic suspend/resume. Hope this report will give
> you enough information to find the problem related to the lost of the
> working touchpad.

It looks like you're running from an external USB disk and the disk got disconnected during suspend/resume. This problem should go away if you actually install Linux on the internal disk.

Note running from an external disk should work, including suspend/resume, but unfortunately as you've noticed this is not always reliable.

Comment 103 vivien.frasca 2018-04-05 11:51:10 UTC
Created attachment 1417653 [details]
lspci

Hans,

Thanks for your analyze. But the fedora root is not on an external device, it is on a PCIe (M2 format) SSD (I've added it few weeks ago).

So is it another problem, may be related to power management ?

Comment 104 Hans de Goede 2018-04-05 11:59:53 UTC
The errors are about sda8, which is on the regular HD (still internal), the weird thing is the following happens on resume:

[ 6771.075902] sd 2:0:0:0: [sda] Starting disk
[ 6771.740332] Buffer I/O error on device sda8, logical block 23146664
[ 6771.740336] Buffer I/O error on device sda8, logical block 23146665
[ 6771.740338] Buffer I/O error on device sda8, logical block 23146666
[ 6771.740339] Buffer I/O error on device sda8, logical block 23146667
[ 6771.740340] Buffer I/O error on device sda8, logical block 23146668
[ 6771.740341] Buffer I/O error on device sda8, logical block 23146669
[ 6771.740342] Buffer I/O error on device sda8, logical block 23146670
[ 6771.740344] Buffer I/O error on device sda8, logical block 23146671
[ 6771.740345] Buffer I/O error on device sda8, logical block 23146672
[ 6771.740346] Buffer I/O error on device sda8, logical block 23146673
[ 6771.759574] EXT4-fs error (device sda8): ext4_wait_block_bitmap:504: comm sin
[ 6771.759581] Buffer I/O error on dev sda8, logical block 0, lost sync page wri
[ 6771.759583] EXT4-fs error (device sda8) in ext4_free_blocks:4973: IO failure
[ 6771.759584] EXT4-fs (sda8): previous I/O error to superblock detected
[ 6771.759586] Buffer I/O error on dev sda8, logical block 0, lost sync page wri
<snip>
[ 6772.939554] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 6773.025938] ata3.00: configured for UDMA/133

So the kernel is trying to use the disk before it is brought back up. Anyways this is completely unrelated to this bug, please send an email about this to:
Tejun Heo <tj>

With me and:
linux-ide.org

In the Cc. You may want to use my excerpt from your dmesg above in the email and include a link to the oops attachment here.

Comment 105 Dan Christian 2018-04-25 20:44:57 UTC
What's the status on this?
Is suspend/resume working?
Did it get merged into fedora or upstream?

Comment 106 vivien.frasca 2018-04-25 21:34:30 UTC
Hello Dan.

The gpio problem is still present with 4.15.17 because the patch has not been merged yet (I still have the black screen). And it brokes keyboard on some Chromebook so the patch won't be merged until another fix is made for the keyboard problem on Chromebooks.

Comment 107 Dan Christian 2018-05-12 16:44:07 UTC
Is there anything that can get this moving again?  It looked so close, but then stalled.  I've got a laptop that needs this fix.

Comment 108 Hans de Goede 2018-05-12 17:42:07 UTC
(In reply to Dan Christian from comment #107)
> Is there anything that can get this moving again?  It looked so close, but
> then stalled.  I've got a laptop that needs this fix.

The fixes are in Torvald's master branch now, this koji build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1080723

Has them included, see here for some generic instructions on how to install a kernel from koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=1080723

As this is an official build you should not need to disable secureboot, that is only for scratch/test builds.

Comment 109 zvober 2018-05-18 11:00:57 UTC
Hi all,
in the first place sorry if I'm eventually asking for help within the wrong community; in that case please advise who I should contact regarding finally potential solution for a long standing ELAN touchpad problem that people have while running any Linux distro on their Asus G752 laptops.

Compared to other Linux distros, Fedora 28 Atomic Workstation completely kills "ELAN1203:00 04F3:3043" touchpad too. After one year and a half, the good news is that one user reported that the Anaconda pre-installation setup of Fedora 28 Atomic Workstation fully activates "ELAN1203:00 04F3:3043" touchpad!
I couldn't find the live image, so consequently without booting up the USB into the live session I was not able to try diagnostic commands. But I can confirm that the Anaconda pre-installation setup of Fedora 28.1.1 Atomic Workstation fully activates "ELAN1203:00 04F3:3043" touchpad, even with multitouch and tap-to-click.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1653456

Very thanks for any help/idea/suggestion.

Comment 110 Hans de Goede 2018-05-18 13:02:31 UTC
Hi,

(In reply to zvober from comment #109)
> Hi all,
> in the first place sorry if I'm eventually asking for help within the wrong
> community; in that case please advise who I should contact regarding finally
> potential solution for a long standing ELAN touchpad problem that people
> have while running any Linux distro on their Asus G752 laptops.
> 
> Compared to other Linux distros, Fedora 28 Atomic Workstation completely
> kills "ELAN1203:00 04F3:3043" touchpad too. After one year and a half, the
> good news is that one user reported that the Anaconda pre-installation setup
> of Fedora 28 Atomic Workstation fully activates "ELAN1203:00 04F3:3043"
> touchpad!
> I couldn't find the live image, so consequently without booting up the USB
> into the live session I was not able to try diagnostic commands. But I can
> confirm that the Anaconda pre-installation setup of Fedora 28.1.1 Atomic
> Workstation fully activates "ELAN1203:00 04F3:3043" touchpad, even with
> multitouch and tap-to-click.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1653456
> 
> Very thanks for any help/idea/suggestion.

Fedora Atomic uses the same kernel and other relevant bits for your touchscreen as the regular Fedora. You could try using the normal Fedora 28 live media:
https://getfedora.org/en/workstation/download/

Other then that I'm not sure what your question is ?

Comment 111 zvober 2018-05-18 14:32:29 UTC
Hello Hans,
thank you very much for your reply.
Asus G752 laptops are equipped with a touchpad, not with the touchscreen.

Anaconda pre-installation setup of Fedora 28 Atomic Workstation is one and unique first time ever that "ELAN1203:00 04F3:3043" touchpad is working.
In other words, regardless of whether Asus G752 owner use any other Fedora Atomic Workstation release, normal Fedora (version 28 included) or any other Linux distribution - "ELAN1203:00 04F3:3043" touchpad is always completely dead. After the installation of the Atomic Workstation 28 it is also dead.

I'm not a technician, so correct me if I'm wrong - after one year and a half, the solution is finally here, it "just" need to be copied from pre-installation setup of Fedora 28 Atomic Workstation and pasted into every kernel/distro? Who is the someone I should kindly invite to perform the "copy-paste? operation?

Comment 112 Hans de Goede 2018-05-18 15:07:45 UTC
(In reply to zvober from comment #111)
> Hello Hans,
> thank you very much for your reply.
> Asus G752 laptops are equipped with a touchpad, not with the touchscreen.
> 
> Anaconda pre-installation setup of Fedora 28 Atomic Workstation is one and
> unique first time ever that "ELAN1203:00 04F3:3043" touchpad is working.
> In other words, regardless of whether Asus G752 owner use any other Fedora
> Atomic Workstation release, normal Fedora (version 28 included) or any other
> Linux distribution - "ELAN1203:00 04F3:3043" touchpad is always completely
> dead. After the installation of the Atomic Workstation 28 it is also dead.
> 
> I'm not a technician, so correct me if I'm wrong - after one year and a
> half, the solution is finally here, it "just" need to be copied from
> pre-installation setup of Fedora 28 Atomic Workstation and pasted into every
> kernel/distro?

If only it were so easy. The touchpad working or not really depends only on the kernel and both atomic and regular Fedora are using the same kernel.

So this seems like some timing issue where atomic changes the timing in such a way that things happen to work...

If you're willing to try to get this to work with Fedora please open a new bug against the kernel component and attach both dmesg output from the atomic anaconda installer environment, you can switch to a text console using ctrl+alt+F5 (IIRC it may be a different F key), as well as dmesg output from a regular Fedora 28 Workstation boot there.

Note for now you can use a Fedora 28 live image from USB but eventually you're going to need to install Fedora 28 so that you can test different kernels.

Comment 113 vivien.frasca 2018-05-21 11:15:59 UTC
Benjamin,

should I open a new bug about the five finger tap (that occurs too with a palm touch) ?

Thank you.

Comment 114 Vincent Crowe 2018-06-06 04:07:48 UTC
Hi, 
I have been trying to get the 3 patches back-ported so they work on Ubuntu 16.04 LTS kernel version 4.13.0 generic on Asus FX503V laptop for the company I work for. I downloaded the kernel version 4.13, apply the patches. The patches would fail with .rej file and I would manually add or remove lines. I have managed to get the source code compiled but cannot install it "dpkg -i *.deb ". What differences between the kernel 4.13.0 and the current version would prevent the patch from working on 4.13.0? 

FYI Not an expert on linux kernels

Thanks Vin

Comment 115 Evan Weiler 2018-07-04 16:41:57 UTC
Hello,

I've been experiencing something very similar to this on my Dell XPS 9575. I however have random left, right, and middle clicks (as far as I can tell). Inputs will have my clipboard pasted into them rapidly.

Here's the touchpad into from libinput list-devices

Device:           DELL080D:00 06CB:7A13 Touchpad
Kernel:           /dev/input/event19
Group:            7
Seat:             seat0, default
Size:             102x77mm
Capabilities:     pointer gesture
Tap-to-click:     disabled
Tap-and-drag:     enabled
Tap drag lock:    disabled
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   *two-finger edge 
Click methods:    *button-areas clickfinger 
Disable-w-typing: enabled
Accel profiles:   none
Rotation:         n/a

Seen on both 4.17.3-1-zen and 4.17.3-1 vanilla (on Arch Linux)
Also seen on 4.16 in void linux

The problem is pretty intermittent. Usually I can use the touchpad for a couple of minutes after boot before it goes haywire. When the clicking issues occur I also see irq/DELL080D process creep up in CPU usage.

but surprisingly watching the input with 
$ sudo evtest /dev/input/by-path/pci-0000\:00\:15.1-platform-i2c_designware.1-event-mouse 
*Appears* to me to temporarily alleviate the issue...

Was that pin fix I read above touchpad specific? Or do those have to be configured per touchpad? (I know essentially nothing about this)

Comment 116 vivien.frasca 2018-07-20 08:30:13 UTC
Hello all,

I tried with kernel 4.17.6-100.fc27.x86_64 and the touchpad works as described before (it works smoothly but, sometimes, it freeze totally for an unknown reason.)

The 5 finger tap still freeze the touchpad.

The only way to unfreeze it is to execute « # modprobe -r i2c_hid && modprobe i2c_hid » as root.

I also note that when doing a 2 finger scroll, the release is not well detected, and trying to move the cursor with a single finger move, the scroll is triggered instead of moving the cursor. To « exit » the scroll mode, I need to do another 2 finger scroll and releasing fingers.

Should I open another bugs reports (1 for the 5 finger tap freeze, another for the scroll release detection, and a last one for the random freeze) ?

Comment 117 Marc Landolt 2018-07-22 03:35:37 UTC
(In reply to Hans de Goede from comment #70)
> p.s.
> 
> I also believe that not having the hole is causing issues for the
> intel_pad_acpi_mode() code.
> 
> E.g. pins 109-119 are wrongly thought to be part of GPP_E as
> intel_pinctrl_add_padgroups() will have assumed 24 pins per group.

(In reply to Hans de Goede from comment #89)
> Vivien,
> 
> Thanks for all your testing on this, things definitively seem to be going in
> the right direction, as for the problems after a suspend/resume, those do
> not seem to be GPIO setting related. All the changes seem to be in bit 1
> (mask 0x00000002) of the first register, which the RX bit, if you do a third
> dump for some pins this bit will likely be different again.
> 
> Can you try doing a "rmmod i2c-hid && modprobe i2c-hid" after a
> suspend/resume and see if that makes things better?
> 
> As for the 5 finger down hangs the touchpad controller issue. "rmmod i2c-hid
> && modprobe i2c-hid" restores functionality after that right?
> 
> So I guess we will need a dump of the i2c packets from a 5 finger tap of
> death, if we can recognize that the touchpad is going to hang we can
> re-initialize it, if we cannot recognize this I'm not sure if there is much
> we can do other then to tell people to not do that.
> 
> Regards,
> 
> Hans

Hello Redhat

i have the issue that ASUS GL703GE ELAN1200 Touchpad does not work at all. I read this Thread and found out that my Laptop uses GPIO 225 and can not register the IRQ:

Jul 20 08:15:30 marcsPC kernel: i2c_hid i2c-ELAN1200:00: HID Descriptor: 1e 00 00 01 64 01 02 00 03 00 10 00 04 00 00 00 05 00 06 00 f3 04 90 30 04 00 00 00 00 00
Jul 20 08:15:30 marcsPC kernel: cannonlake-pinctrl INT3450:00: pin 225 cannot be used as IRQ

hopefully it is OK to post that here because it's almost the same hardware but possibly just attached to another pin on the cannonlake... but i'm not good enough in programming to debug kernel things.

With kind regards
Marc Landolt

Comment 118 Andy Shevchenko 2018-07-23 12:38:33 UTC
(In reply to Marc Landolt from comment #117)

> i have the issue that ASUS GL703GE ELAN1200 Touchpad does not work at all. I
> read this Thread and found out that my Laptop uses GPIO 225 and can not
> register the IRQ:
> 
> Jul 20 08:15:30 marcsPC kernel: i2c_hid i2c-ELAN1200:00: HID Descriptor: 1e
> 00 00 01 64 01 02 00 03 00 10 00 04 00 00 00 05 00 06 00 f3 04 90 30 04 00
> 00 00 00 00
> Jul 20 08:15:30 marcsPC kernel: cannonlake-pinctrl INT3450:00: pin 225
> cannot be used as IRQ
> 
> hopefully it is OK to post that here because it's almost the same hardware
> but possibly just attached to another pin on the cannonlake... but i'm not
> good enough in programming to debug kernel things.

Can you consider to follow some advice in
https://bugzilla.kernel.org/show_bug.cgi?id=199911
?

Comment 119 Justin M. Forbes 2018-07-23 15:33:37 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 120 Marc Landolt 2018-07-25 16:28:11 UTC
@Andy Shevckenko: i tried the link and compiled a modified kernel with 4.18_RC6 and 4.17.2 but it did not work, the errors went away but the touchpad still does not work

@Justin M Forbes: I tried Fedora 28 with kernel 4.17.7-200-fc28 but the touchpad still does not work

Comment 121 vivien.frasca 2018-07-29 19:56:32 UTC
Hi all.

So I've tried the kernel 4.17.9-100.fc27.x86_64 without any changes.

There are still these problems :

- The 5 finger tap freeze the touchpad
- Closing the laptop lid trigger correctly the hibernate only the first time. After the wake up, the mouse pointer is slow as described in the firsts comments of this bug report.

The only way to unfreeze the touchpad is to probe again the module i2c_hid : sudo modprobe -r i2c_hid && sudo modprobe i2c_hid

Does anybody need any extra information ? Should I do anything again (hid record, pins report ?)

Comment 122 Marc Landolt 2018-07-30 01:24:27 UTC
(In reply to vivien.frasca from comment #121)
> Hi all.
> 
> So I've tried the kernel 4.17.9-100.fc27.x86_64 without any changes.
> 
> There are still these problems :
> 
> - The 5 finger tap freeze the touchpad
> - Closing the laptop lid trigger correctly the hibernate only the first
> time. After the wake up, the mouse pointer is slow as described in the
> firsts comments of this bug report.
> 
> The only way to unfreeze the touchpad is to probe again the module i2c_hid :
> sudo modprobe -r i2c_hid && sudo modprobe i2c_hid
> 
> Does anybody need any extra information ? Should I do anything again (hid
> record, pins report ?)

Hi vivien

i opened a bug at Kernel.org for this problem, i have a different device but the same problems: https://bugzilla.kernel.org/show_bug.cgi?id=200663

since only a rmmod&&insmod helps it should be a kernel problem, so kernel.org, i also added hid-record logs that maybe helps finding the problem.

marc

Comment 123 Andrey Ivanov 2018-09-04 19:38:33 UTC
(In reply to Benjamin Tissoires from comment #15)
> Hi Viven.
> 
> Do you mind testing the branch for-vivien on the following repo:
> https://github.com/bentiss/hid-multitouch/tree/for-vivien
> 
> On Fedora 27 with a v4.15 kernel, a simple 'make' then 'sudo rmmod
> hid_multitouch; sync && sudo insmod ./hid-multitouch.ko' should be enough to
> be running the new code.
> 
> If you successfully loaded this new kernel module, the dmesg should shout
> some (debug) errors like "[  +0.021724] mt_set_latency_mode setting latency
> mode to 0 $SOME_PATH/hid-multitouch/hid-multitouch.c:1151"
> 
> Once this is properly loaded, please re-attach a hid-recorder of the 2
> fingers scrolls and jumps test cases.
> 
> Ideally, also make sure the debug messages are there on suspend/resume.

I try to compile your driver and get error.. 

hid-multitouch.c:1534:18: ошибка: «HID_QUIRK_NO_EMPTY_INPUT» undeclared (first use in this function); did you mean «HID_QUIRK_MULTI_INPUT»?
  hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
                  ^~~~~~~~~~~~~~~~~~~~~~~~
                  HID_QUIRK_MULTI_INPUT
/home/andrey/hid-multitouch-for-vivien/hid-multitouch.c:1534:18: замечание: сообщение о каждом неописанном идентификаторе выдается один раз в каждой функции, где он встречается
____________________________________________________________
CODE:
/*
	 * This allows the driver to handle different input sensors
	 * that emits events through different reports on the same HID
	 * device.
	 */
	hdev->quirks |= HID_QUIRK_MULTI_INPUT;
	hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;

	/*
	 * Some multitouch screens do not like to be polled for input
___________________________________________________________
I open hid-multitouch.c and comment hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
and try to compile. compile succeseful. And warning log  "incomplete report 16/32635" solved. touchpad work.. i test it 2 minutes.. i will be continue..

send you news later.

Vivien, please read my comment.

Comment 124 Andrey Ivanov 2018-09-04 19:39:36 UTC
(In reply to Benjamin Tissoires from comment #15)
> Hi Viven.
> 
> Do you mind testing the branch for-vivien on the following repo:
> https://github.com/bentiss/hid-multitouch/tree/for-vivien
> 
> On Fedora 27 with a v4.15 kernel, a simple 'make' then 'sudo rmmod
> hid_multitouch; sync && sudo insmod ./hid-multitouch.ko' should be enough to
> be running the new code.
> 
> If you successfully loaded this new kernel module, the dmesg should shout
> some (debug) errors like "[  +0.021724] mt_set_latency_mode setting latency
> mode to 0 $SOME_PATH/hid-multitouch/hid-multitouch.c:1151"
> 
> Once this is properly loaded, please re-attach a hid-recorder of the 2
> fingers scrolls and jumps test cases.
> 
> Ideally, also make sure the debug messages are there on suspend/resume.

I try to compile your driver and get error.. 

hid-multitouch.c:1534:18: ошибка: «HID_QUIRK_NO_EMPTY_INPUT» undeclared (first use in this function); did you mean «HID_QUIRK_MULTI_INPUT»?
  hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
                  ^~~~~~~~~~~~~~~~~~~~~~~~
                  HID_QUIRK_MULTI_INPUT
/home/andrey/hid-multitouch-for-vivien/hid-multitouch.c:1534:18: замечание: сообщение о каждом неописанном идентификаторе выдается один раз в каждой функции, где он встречается
____________________________________________________________
CODE:
/*
	 * This allows the driver to handle different input sensors
	 * that emits events through different reports on the same HID
	 * device.
	 */
	hdev->quirks |= HID_QUIRK_MULTI_INPUT;
	hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;

	/*
	 * Some multitouch screens do not like to be polled for input
___________________________________________________________
I open hid-multitouch.c and comment hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
and try to compile. compile succeseful. And warning log  "incomplete report 16/32635" solved. touchpad work.. i test it 2 minutes.. i will be continue..

send you news later.

Vivien, please read my comment.

Comment 125 Andrey Ivanov 2018-09-04 19:42:23 UTC
(In reply to vivien.frasca from comment #116)
> Hello all,
> 
> I tried with kernel 4.17.6-100.fc27.x86_64 and the touchpad works as
> described before (it works smoothly but, sometimes, it freeze totally for an
> unknown reason.)
> 
> The 5 finger tap still freeze the touchpad.
> 
> The only way to unfreeze it is to execute « # modprobe -r i2c_hid &&
> modprobe i2c_hid » as root.
> 
> I also note that when doing a 2 finger scroll, the release is not well
> detected, and trying to move the cursor with a single finger move, the
> scroll is triggered instead of moving the cursor. To « exit » the scroll
> mode, I need to do another 2 finger scroll and releasing fingers.
> 
> Should I open another bugs reports (1 for the 5 finger tap freeze, another
> for the scroll release detection, and a last one for the random freeze) ?

(In reply to Benjamin Tissoires from comment #15)
> Hi Viven.
> 
> Do you mind testing the branch for-vivien on the following repo:
> https://github.com/bentiss/hid-multitouch/tree/for-vivien
> 
> On Fedora 27 with a v4.15 kernel, a simple 'make' then 'sudo rmmod
> hid_multitouch; sync && sudo insmod ./hid-multitouch.ko' should be enough to
> be running the new code.
> 
> If you successfully loaded this new kernel module, the dmesg should shout
> some (debug) errors like "[  +0.021724] mt_set_latency_mode setting latency
> mode to 0 $SOME_PATH/hid-multitouch/hid-multitouch.c:1151"
> 
> Once this is properly loaded, please re-attach a hid-recorder of the 2
> fingers scrolls and jumps test cases.
> 
> Ideally, also make sure the debug messages are there on suspend/resume.

I try to compile your driver and get error.. 

hid-multitouch.c:1534:18: ошибка: «HID_QUIRK_NO_EMPTY_INPUT» undeclared (first use in this function); did you mean «HID_QUIRK_MULTI_INPUT»?
  hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
                  ^~~~~~~~~~~~~~~~~~~~~~~~
                  HID_QUIRK_MULTI_INPUT
/home/andrey/hid-multitouch-for-vivien/hid-multitouch.c:1534:18: замечание: сообщение о каждом неописанном идентификаторе выдается один раз в каждой функции, где он встречается
____________________________________________________________
CODE:
/*
	 * This allows the driver to handle different input sensors
	 * that emits events through different reports on the same HID
	 * device.
	 */
	hdev->quirks |= HID_QUIRK_MULTI_INPUT;
	hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;

	/*
	 * Some multitouch screens do not like to be polled for input
___________________________________________________________
I open hid-multitouch.c and comment hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
and try to compile. compile succeseful. And warning log  "incomplete report 16/32635" solved. touchpad work.. i test it 2 minutes.. i will be continue..

send you news later.

Vivien, please read my comment.

Comment 126 Andrey Ivanov 2018-09-04 19:47:15 UTC
(In reply to vivien.frasca from comment #113)
> Benjamin,
> 
> should I open a new bug about the five finger tap (that occurs too with a
> palm touch) ?
> 
> Thank you.
Vivien, 
i use this code:  https://github.com/bentiss/hid-multitouch/tree/for-vivien
with changes:
	hdev->quirks |= HID_QUIRK_MULTI_INPUT;
	//hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
compille absolutely good, work good, solved incomplete report error. i will be continue report.

ITS FIX WORK OF TOUCHPAD IN ASUS GL703VD with ELAN 1200 (DESIGHWARE).

I will be continue test, if it will be work perfectly, please add it mainlain of kernel linux.

KERNEL VERSION:4.18.5
THANKS BENJAMIN, AND YOU, VIVIEN)

Comment 127 Vladislav 2018-09-11 17:19:57 UTC
(In reply to Andrey Ivanov from comment #126)
> (In reply to vivien.frasca from comment #113)
> > Benjamin,
> > 
> > should I open a new bug about the five finger tap (that occurs too with a
> > palm touch) ?
> > 
> > Thank you.
> Vivien, 
> i use this code:  https://github.com/bentiss/hid-multitouch/tree/for-vivien
> with changes:
> 	hdev->quirks |= HID_QUIRK_MULTI_INPUT;
> 	//hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
> compille absolutely good, work good, solved incomplete report error. i will
> be continue report.
> 
> ITS FIX WORK OF TOUCHPAD IN ASUS GL703VD with ELAN 1200 (DESIGHWARE).
> 
> I will be continue test, if it will be work perfectly, please add it
> mainlain of kernel linux.
> 
> KERNEL VERSION:4.18.5
> THANKS BENJAMIN, AND YOU, VIVIEN)

Well, i've just tried to apply this patch on ASUS-FX503VD on 4.18.6 kernel, and the problem still pop's up.

- Five finger tap freeze kills touchpad
- Two-finger scrolling lags sometimes, which causes to two-finger scroll again to let it work.

Modprobing i2c_hid still works, but this fix is ugly, because i don't know how to set a hotkey for this script, as this script needs to run as root.

The problem seems to bee dead, but I hope someone is still looking for an answer.

Comment 128 vivien.frasca 2018-09-12 07:37:16 UTC
(In reply to Vladislav from comment #127)
> (In reply to Andrey Ivanov from comment #126)
> > (In reply to vivien.frasca from comment #113)
> > > Benjamin,
> > > 
> > > should I open a new bug about the five finger tap (that occurs too with a
> > > palm touch) ?
> > > 
> > > Thank you.
> > Vivien, 
> > i use this code:  https://github.com/bentiss/hid-multitouch/tree/for-vivien
> > with changes:
> > 	hdev->quirks |= HID_QUIRK_MULTI_INPUT;
> > 	//hdev->quirks |= HID_QUIRK_NO_EMPTY_INPUT;
> > compille absolutely good, work good, solved incomplete report error. i will
> > be continue report.
> > 
> > ITS FIX WORK OF TOUCHPAD IN ASUS GL703VD with ELAN 1200 (DESIGHWARE).
> > 
> > I will be continue test, if it will be work perfectly, please add it
> > mainlain of kernel linux.
> > 
> > KERNEL VERSION:4.18.5
> > THANKS BENJAMIN, AND YOU, VIVIEN)
> 
> Well, i've just tried to apply this patch on ASUS-FX503VD on 4.18.6 kernel,
> and the problem still pop's up.
> 
> - Five finger tap freeze kills touchpad
> - Two-finger scrolling lags sometimes, which causes to two-finger scroll
> again to let it work.
> 
> Modprobing i2c_hid still works, but this fix is ugly, because i don't know
> how to set a hotkey for this script, as this script needs to run as root.
> 
> The problem seems to bee dead, but I hope someone is still looking for an
> answer.

Hello Vladislav.

This problem still occurs for me but I didn't test it recently (I usually probe again the hid module when the touchpad freeze.)

I don't have enough time now to compile a kernel again. But in few week I'll have more time to check the solution of Andrey Ivanov.

If this fix the problem I'll keep you (and all subscribers to this bug) in touch.

Comment 129 Andrey Ivanov 2018-09-16 11:20:54 UTC
Created attachment 1483683 [details]
Hid over i2c protocol spec

Comment 130 vivien.frasca 2018-09-21 12:34:32 UTC
I've tested with kernel 4.18.9 and the change made by Andrey Ivanov.

There si no significant changes.

Just one thing, when doing a 5 finger tap, the journalctl displays this message :

sept. 21 14:30:38 papsou-fx503vd kernel: i2c_hid i2c-ELAN1200:00: i2c_hid_get_input: incomplete report (16/255)

In a normal use case, this message triggers randomly :

sept. 21 14:30:38 papsou-fx503vd kernel: i2c_hid i2c-ELAN1200:00: i2c_hid_get_input: incomplete report (16/65535)

I don't know if it helps a lot... But if handling the incomplete report (16/255) to modprobe again the i2c_hid module it could « fix » or « hack » the five finger tap freeze (but sometimes, the incomplete report message is not displayed on 5 finger tap freeze).

Comment 131 Andrey Ivanov 2018-09-21 13:21:21 UTC
(In reply to vivien.frasca from comment #130)
> I've tested with kernel 4.18.9 and the change made by Andrey Ivanov.
> 
> There si no significant changes.
> 
> Just one thing, when doing a 5 finger tap, the journalctl displays this
> message :
> 
> sept. 21 14:30:38 papsou-fx503vd kernel: i2c_hid i2c-ELAN1200:00:
> i2c_hid_get_input: incomplete report (16/255)
> 
> In a normal use case, this message triggers randomly :
> 
> sept. 21 14:30:38 papsou-fx503vd kernel: i2c_hid i2c-ELAN1200:00:
> i2c_hid_get_input: incomplete report (16/65535)
> 
> I don't know if it helps a lot... But if handling the incomplete report
> (16/255) to modprobe again the i2c_hid module it could « fix » or « hack »
> the five finger tap freeze (but sometimes, the incomplete report message is
> not displayed on 5 finger tap freeze).

I re-think your testing info, and think that need to add mainlain driver magical sequence from my repo for touchpad with GL703VD brand, for your version not use if its not solve incomplete report in normal mode.
On my laptop i not have incomplete report, but touchpad freeze when 5 fingers. 

How i can to help you? I am not programmer(not developer), but i maybe can recors report data in i2c bus for reverse engineering.. if we have utilites for it..
I know asus have datasheet on this chip, because asus (vendor) develop driver on my laptop. I read about Elantech, Elantech not provide drivers, only vendors..

Comment 132 Andrey Ivanov 2018-09-21 13:25:12 UTC
(In reply to vivien.frasca from comment #130)
> I've tested with kernel 4.18.9 and the change made by Andrey Ivanov.
> 
> There si no significant changes.
> 
> Just one thing, when doing a 5 finger tap, the journalctl displays this
> message :
> 
> sept. 21 14:30:38 papsou-fx503vd kernel: i2c_hid i2c-ELAN1200:00:
> i2c_hid_get_input: incomplete report (16/255)
> 
> In a normal use case, this message triggers randomly :
> 
> sept. 21 14:30:38 papsou-fx503vd kernel: i2c_hid i2c-ELAN1200:00:
> i2c_hid_get_input: incomplete report (16/65535)
> 
> I don't know if it helps a lot... But if handling the incomplete report
> (16/255) to modprobe again the i2c_hid module it could « fix » or « hack »
> the five finger tap freeze (but sometimes, the incomplete report message is
> not displayed on 5 finger tap freeze).

If its needed, i can add history of changes.. its will be good for developers and for designing patch if its will be using my repo.. i think so..

Comment 133 Vladislav 2018-09-26 14:43:44 UTC
Hi all, sorry for the delay.

I think we really need to find some software engineer to fix this stuff.
Also i did some research, and as it seems, all the magic is going in this line of code: https://github.com/torvalds/linux/blob/6741c4bb389da103c0d79ad1961884628900bfe6/drivers/hid/i2c-hid/i2c-hid.c#L480

I will try to understand what's going on there, but i am not linux developer at all. Just a hint for some pro-developers.

Also maybe off-top question, but did someone manage to fix fn keys on fx553vd?

Comment 134 Vladislav 2018-10-09 07:50:16 UTC
Hi all again. Any solutions found?

Comment 136 Vladislav 2018-10-14 22:09:27 UTC
(In reply to Andrey Ivanov from comment #135)
> (In reply to Vladislav from comment #134)
> > Hi all again. Any solutions found?
> 
> I think nope..
> 
> But i see new patches...
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/
> drivers/hid/i2c-hid/i2c-hid.c?id=v4.19-rc7&id2=v4.19-rc6
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/
> drivers/i2c/busses/i2c-designware-master.c?id=v4.19-rc7&id2=v4.19-rc6
> 
> Can you test 4.19-r6 on your machine?

Hi, I've tried installing rc6 and rc7 versions of this kernels, but ended up with this error:

'make' -j4 NV_EXCLUDE_BUILD_MODULES='' KERNEL_UNAME=4.18.12-041812-generic modules...(bad exit status: 2)
ERROR (dkms apport): binary package for nvidia: 396.18 not found
Error! Bad return status for module build on kernel: 4.18.12-041812-generic (x86_64)
Consult /var/lib/dkms/nvidia/396.18/build/make.log for more information.
-> error.
ERROR: Failed to install the kernel module through DKMS. No kernel module was installed; please try installing again without DKMS, or check the DKMS logs for more information.
ERROR: Installation has failed.  Please see the file '/var/log/nvidia-installer.log' for details.  You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com.


Found some possible fix - http://www.hlmjr.com/index.php/2018/08/21/nvidia-drivers-390-77-vs-linux-kernel-4-18/

But I am really afraid to reinstall my nvidia drivers, they are configured well with bumblebee at this moment, so i have discharge rate of 2-3 watts.

I understand that this kernel can really help, so when i'll have enough time, i will backup my system and reinstall nvidia drivers to make this kernel work.

Anyways, can someone else with this problem try this kernel?

Comment 137 Vladislav 2018-10-17 16:20:27 UTC
Well, this kernel doesn't seem to fix the issue. I could not manage to properly install nvidia drivers, but in login screen five finger tap freeze still appears, as well as disability of fn keys (except volume keys). Now my bumblebee doesn't turn off nvidia card, and i have to configure it again...

Comment 138 Andrey Ivanov 2018-10-23 05:22:37 UTC
(In reply to Vladislav from comment #137)
> Well, this kernel doesn't seem to fix the issue. I could not manage to
> properly install nvidia drivers, but in login screen five finger tap freeze
> still appears, as well as disability of fn keys (except volume keys). Now my
> bumblebee doesn't turn off nvidia card, and i have to configure it again...

Dear Vladislav.
Released next kernel 4.19.

I see in git, added max fingers=5

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/hid/hid-elan.c?id=v4.19&id2=v4.18

And new functions for communicate via DMA (Direct Memory Access).
Can you test it?

Comment 139 Vladislav 2018-10-23 08:27:12 UTC
(In reply to Andrey Ivanov from comment #138)
> (In reply to Vladislav from comment #137)
> > Well, this kernel doesn't seem to fix the issue. I could not manage to
> > properly install nvidia drivers, but in login screen five finger tap freeze
> > still appears, as well as disability of fn keys (except volume keys). Now my
> > bumblebee doesn't turn off nvidia card, and i have to configure it again...
> 
> Dear Vladislav.
> Released next kernel 4.19.
> 
> I see in git, added max fingers=5
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/
> drivers/hid/hid-elan.c?id=v4.19&id2=v4.18
> 
> And new functions for communicate via DMA (Direct Memory Access).
> Can you test it?

Sounds impressive. I will try it this evening. Thanks.

Comment 140 Andrey Ivanov 2018-10-23 09:36:27 UTC
(In reply to Vladislav from comment #139)
> (In reply to Andrey Ivanov from comment #138)
> > (In reply to Vladislav from comment #137)
> > > Well, this kernel doesn't seem to fix the issue. I could not manage to
> > > properly install nvidia drivers, but in login screen five finger tap freeze
> > > still appears, as well as disability of fn keys (except volume keys). Now my
> > > bumblebee doesn't turn off nvidia card, and i have to configure it again...
> > 
> > Dear Vladislav.
> > Released next kernel 4.19.
> > 
> > I see in git, added max fingers=5
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/
> > drivers/hid/hid-elan.c?id=v4.19&id2=v4.18
> > 
> > And new functions for communicate via DMA (Direct Memory Access).
> > Can you test it?
> 
> Sounds impressive. I will try it this evening. Thanks.

I am will be waining your information ;) if you can, send me copy of your report to ARMv7hf

Comment 141 Vladislav 2018-10-24 11:28:52 UTC
Hi, there is some more info about new 4.19 kernel.
It seems like new DMA functions raise power consumption (i was getting ~3W, now im getting ~4.5w, and idma module consumes ~1W).
Touchpad still laggy, fn keys don't work

Comment 142 Andrey Ivanov 2018-10-24 12:15:22 UTC
(In reply to Vladislav from comment #141)
> Hi, there is some more info about new 4.19 kernel.
> It seems like new DMA functions raise power consumption (i was getting ~3W,
> now im getting ~4.5w, and idma module consumes ~1W).
> Touchpad still laggy, fn keys don't work

My touchpad absolutely not work in 4.19.0.
Sadly(((
Hardware: ASUS GL703VD-GC030

Comment 143 Marc Landolt 2018-10-24 18:56:38 UTC
(In reply to Andrey Ivanov from comment #142)
> (In reply to Vladislav from comment #141)
> > Hi, there is some more info about new 4.19 kernel.
> > It seems like new DMA functions raise power consumption (i was getting ~3W,
> > now im getting ~4.5w, and idma module consumes ~1W).
> > Touchpad still laggy, fn keys don't work
> 
> My touchpad absolutely not work in 4.19.0.
> Sadly(((
> Hardware: ASUS GL703VD-GC030

Hello Andrey

you must patch the Kernel with following 3 lines:
https://bugzilla.kernel.org/show_bug.cgi?id=200663#c16

I just tested with Kernel 4.19 on Ubuntu and the touchpad works with this workaround on Asus GL703GE, there are good chances that it has the same Hardware like GL703VD.

But the problem that the touchpad looses connection if you put 5 Fingers on it. For this problem you must rmmod hid_multitouch && insmod hid_multitouch to get it running again when it lost connection.

With kind Regards
Marc Landolt

Comment 144 Andrey Ivanov 2018-10-24 22:05:39 UTC
(In reply to Marc Landolt from comment #143)
> (In reply to Andrey Ivanov from comment #142)
> > (In reply to Vladislav from comment #141)
> > > Hi, there is some more info about new 4.19 kernel.
> > > It seems like new DMA functions raise power consumption (i was getting ~3W,
> > > now im getting ~4.5w, and idma module consumes ~1W).
> > > Touchpad still laggy, fn keys don't work
> > 
> > My touchpad absolutely not work in 4.19.0.
> > Sadly(((
> > Hardware: ASUS GL703VD-GC030
> 
> Hello Andrey
> 
> you must patch the Kernel with following 3 lines:
> https://bugzilla.kernel.org/show_bug.cgi?id=200663#c16
> 
> I just tested with Kernel 4.19 on Ubuntu and the touchpad works with this
> workaround on Asus GL703GE, there are good chances that it has the same
> Hardware like GL703VD.
> 
> But the problem that the touchpad looses connection if you put 5 Fingers on
> it. For this problem you must rmmod hid_multitouch && insmod hid_multitouch
> to get it running again when it lost connection.
> 
> With kind Regards
> Marc Landolt

You are same too have non work touchpad in vanilla-sources 4.19.0??
Tell me, what the pathches? I test pre release ubuntu 18.10, coming soon i will be test official 18.10 release. When i will be patch 4.19.0 my touchpad will be recognition by kernel? Because now, in 4.19.0 kernel absolutely dont knoww about tochpad(twi-hid loaded (twi=i2c) , hi_moltitouch loaded, i801 same too, and.. i2c_core and i2c_dev.. ehhhh

Comment 145 Andrey Ivanov 2018-10-24 22:07:56 UTC
(In reply to Marc Landolt from comment #143)
> (In reply to Andrey Ivanov from comment #142)
> > (In reply to Vladislav from comment #141)
> > > Hi, there is some more info about new 4.19 kernel.
> > > It seems like new DMA functions raise power consumption (i was getting ~3W,
> > > now im getting ~4.5w, and idma module consumes ~1W).
> > > Touchpad still laggy, fn keys don't work
> > 
> > My touchpad absolutely not work in 4.19.0.
> > Sadly(((
> > Hardware: ASUS GL703VD-GC030
> 
> Hello Andrey
> 
> you must patch the Kernel with following 3 lines:
> https://bugzilla.kernel.org/show_bug.cgi?id=200663#c16
> 
> I just tested with Kernel 4.19 on Ubuntu and the touchpad works with this
> workaround on Asus GL703GE, there are good chances that it has the same
> Hardware like GL703VD.
> 
> But the problem that the touchpad looses connection if you put 5 Fingers on
> it. For this problem you must rmmod hid_multitouch && insmod hid_multitouch
> to get it running again when it lost connection.
> 
> With kind Regards
> Marc Landolt

Now i have 4.18.6 (good work) and 4.19.0 stable work, but i2c touchpad not work and not added (in dmesg i not see lines about elan1290)

Comment 146 Andrey Ivanov 2018-12-31 13:51:15 UTC
New information.
Kernel 4.20.
Synopsys i2c elantech 1200 touchpad added but not work.
Coming soon i will publish here .config for kernel and dmesg log.
Hardware Asus GL503VD.

Comment 147 Andrey Ivanov 2018-12-31 13:52:38 UTC
Elantech1200 touchpad added mean attached in process of boot, but not work.

Comment 148 Justin M. Forbes 2019-01-29 16:14:19 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs.

Fedora 29 has now been rebased to 4.20.5-200.fc29.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 149 vivien.frasca 2019-01-30 11:11:52 UTC
This issue is still present after upgrade to kernel 4.20.4-200.fc29.x86_64.

Comment 150 vivien.frasca 2019-02-15 21:56:42 UTC
This issue is still present after upgrade to kernel 4.20.7-200.fc29.x86_64.

I still have messages like this one in demsg -w

[  581.465203] i2c_hid i2c-ELAN1200:00: i2c_hid_get_input: incomplete report (16/65535)

What kind of informations should I give to you in order to unfreeze this bug ?

Comment 151 zvober 2019-02-21 10:24:33 UTC
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1653456/comments/161

2018-12-08: 
After 2 years of waiting for the official solution, hope is lost.
Today I deleted everything in my machine and installed Windows 10. After that I installed the suspicious firmware upgrade from the Asus forum:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1653456/+attachment/4955397/+files/WinIAP_Fix%20Touchpad.zip
1. Download the Zip from the Link below
2. extract the zip into a folder where you want
3. open the "WinIAP_X64.exe"
4. select "Load Bin File" and now select the File "SB463D-1407_Fv0x06.bin" in the the same folder that you extractet
5. after the .bin file is loaded in the programm klick "Update Rom" (do nothing before the Update Process is finished)
6. when the update is finished, close the programm and restart your computer

After that, once again I deleted everything in my machine and installed Solus Budgie.
'ELAN1203:00 04F3:3043' touchpad of my Asus G752VS laptop finally works perfectly on Linux.

Comment 152 Vladislav 2019-02-23 02:08:01 UTC
GUYS DONT DO THIS FLASH PLEASE I JUST FLASHED IT AND MY TOUCHPAD IS INVERTED NOW AND WORKS BAD IN LINUX.

SOMEBODY PLEASE COPY AND SEND ME YOUR CURRENT TOUCHPAD FIRMWARE! I WILL GIVE A REWARD!

Comment 153 Vladislav 2019-02-23 02:08:22 UTC
GUYS DONT DO THIS FLASH PLEASE I JUST FLASHED IT AND MY TOUCHPAD IS INVERTED NOW AND WORKS BAD IN LINUX.

SOMEBODY PLEASE COPY AND SEND ME YOUR CURRENT TOUCHPAD FIRMWARE! I WILL GIVE A REWARD!

Comment 154 zvober 2019-02-23 15:01:47 UTC
Have you read that I installed the thing on my Asus G752VS laptop with touchpad ELAN1203:00 04F3:3043? It works perfectly in my case. I think that you made u huge mistake by installing the thing on Asus FX553VD laptop with Elan1200 touchpad!

Comment 155 Vladislav 2019-03-14 17:48:10 UTC
ATTENTION EVERYONE! MODULE FIXED!

I've contacted ELANTECH about my touchpad issue, and they sent me right WinIAP hardware, and if someone also reflashed their touchpad with a wrong firmware, send me an email, and I will send it to you.
I have firmwares for: 04F3:3090, 04F3:303E, 04F3:304E.

And they sent me a kernel patch which solved ALL ISSUES. NO FIVE FINGER TAP FREEZE and PERFECT work of touchpad. Intel suggested this patch, though it seems patch is not applied to the main kernel and I can see no merge request's for it, so I will open one, if ELAN let me do this.

Sending patch in next message.

Comment 156 Vladislav 2019-03-14 17:51:13 UTC
Created attachment 1544135 [details]
HID-touchpad full patch

This patch fixes all issues on my FX553VD laptop.

Comment 157 Vladislav 2019-03-14 18:33:43 UTC
I've just created a fork of latest linux, so it's a matter of cherry pick of this commit: https://github.com/vladik2738/linux/commit/2c8d5242dc07dc10b9b59e2ad41f394ce0b18dd9

Comment 158 Andy Shevchenko 2019-03-14 19:53:23 UTC
Thanks for the news!

It's of course not an upstreamable solution, it's just a hack, but we can learn from it. So, there are two symptoms:
- IRQ flags are not set correctly
- PM events killed touchpad (I guess the real issue here is a initializing sequence and timeouts).
Each of them should be investigated separately.

Comment 159 Benjamin Tissoires 2019-03-15 15:48:07 UTC
Yep, good news.

>  - PM events killed touchpad (I guess the real issue here is a initializing sequence and timeouts).

I am really wondering if we should not entirely disable PM events for i2c-hid touchpads when running in a Windows capable machine.
AFAICT, Windows doesn't send the PWR commands, and I think this creates more troubles than it should. I came to suspect a bunch of weird firmware bugs related to this.

After staring at the last patch for a while, I am under the impression that the i2c-designware changes are a no-op. 
pm_disabled is only set for a couple of cherry trail platforms, and I don't think you have one of these. But then, the change in i2c_dw_probe() takes the 'else' case anyway, so if it was false from start, then we should get the same code path.

Could you revert the designware changes and thus keep only the i2c-hid.c change and report if this helps?

Comment 160 Vladislav 2019-03-15 16:32:41 UTC
Okay, I will test it today's evening.

Comment 161 Hans de Goede 2019-03-15 17:37:34 UTC
(In reply to Benjamin Tissoires from comment #159)
> After staring at the last patch for a while, I am under the impression that
> the i2c-designware changes are a no-op. 
> pm_disabled is only set for a couple of cherry trail platforms, and I don't
> think you have one of these. But then, the change in i2c_dw_probe() takes
> the 'else' case anyway, so if it was false from start, then we should get
> the same code path.

The i2c-designware changes also contain a chunk to set pm_disable to true
unconditionally, so what they are basically doing is disabling runtime-pm
on the i2c-designware controller.

But I agree that it is a good idea to test things with just the i2c-hid change.

Comment 162 Vladislav 2019-03-16 11:51:41 UTC
Greetings! I've just installed kernel with only i2c-hid patched, and touchpad wokrs perfect.

So i2c-designware-master.c and i2c-designware-platdrv.c really don't need to be patched.

Comment 163 vivien.frasca 2019-03-16 12:43:56 UTC
I confirm that applying the patch only for drivers/hid/i2c-hid/i2c-hid-core.c makes the touchpad work perfectly.

Comment 164 Hans de Goede 2019-03-16 13:51:09 UTC
Ok, so I just checked the DSDT from acpidump.ASUS-FX503VD and it configures the interrupt as level-low, which the patch changes to edge-falling.

The interrupt needing to be edge, not level, explains the interrupt-storm from comment 27.

I also have an acpidump for the ASUS-GL503VD which is also mentioned in this bug and this to has a touchpad with an ACPI HID of ELAN1200 and also has the irq configured as level-low in the DSDT.

There are a lot of seemingly related problems with similar model Asus laptops, see some comments on this bug and also:
https://bugzilla.kernel.org/show_bug.cgi?id=200663

I think we need to add a quirk, probably best to base this on vid:pid as we do for other devices, to override the IRQ flags to edge-falling on this model Elan touchpad (and maybe also on some other Elan models).

Comment 165 Vladislav 2019-03-16 14:15:53 UTC
Can you please add some references to HID driver documentation so I could be able to do it? I don't know where is the main documentation.

Comment 166 Hans de Goede 2019-03-16 15:39:05 UTC
(In reply to Vladislav from comment #165)
> Can you please add some references to HID driver documentation so I could be
> able to do it? I don't know where is the main documentation.

If you look at drivers/hid/i2c-hid/i2c-hid-core.c around line 49 you will see:

/* quirks to control the device */
#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV        BIT(0)
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET        BIT(1)
#define I2C_HID_QUIRK_NO_RUNTIME_PM             BIT(2)
#define I2C_HID_QUIRK_DELAY_AFTER_SLEEP         BIT(3)

You should add a new quirk there, something like this:

#define I2C_HID_QUIRK_FORCE_TRIGGER_FALLING     BIT(4)

And then in the quirks table around line 166:

static const struct i2c_hid_quirks {
        __u16 idVendor;
        __u16 idProduct;
        __u32 quirks;
} i2c_hid_quirks[] = {
        { USB_VENDOR_ID_WEIDA, USB_DEVICE_ID_WEIDA_8752,
                I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
...
        { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
                I2C_HID_QUIRK_NO_RUNTIME_PM },
        { 0, 0 }
};

Add a new entry for your touchpad:

        { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
                I2C_HID_QUIRK_NO_RUNTIME_PM },
        { USB_VENDOR_ID_ELAN, 0x303e,
                I2C_HID_QUIRK_FORCE_TRIGGER_FALLING },
        { 0, 0 }
};

And then instead of unconditionally adding:

        irqflags = IRQF_TRIGGER_FALLING;

Around line 813, do it based on the quirk:

        if (ihid->quirks & I2C_HID_QUIRK_FORCE_TRIGGER_FALLING)
                irqflags = IRQF_TRIGGER_FALLING;

For this to work you need to move the 

        ret = i2c_hid_init_irq(client);
        if (ret < 0)
                goto err_pm;

Block around line 1121 to below the:

      ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);

Line (which is around line 1141)

Comment 167 Vladislav 2019-03-16 20:43:14 UTC
Hi. So after trying to fix those issues, I come up with a next diff:

https://nest.parrotsec.org/h0tw4t3r/linux/compare/06bac60e4df4eec3ed400e420fa7d27d67287450...36eb22cfe5e5fb49a383e0907f187cc209b56051
(Don't look at the last file, it's needed to build kernel)

What is interesting, five finger tap freeze is gone BUT touchpad movement is very laggy. Have I done something bad?

Comment 168 Vladislav 2019-03-16 20:45:37 UTC
This link goes to ParrotOS linux distribution's nest with my fork of their patched linux kernel. Though they don't patch anything related to hid or i2c so this changes are appliable to an upstream kernel.

Comment 169 Vladislav 2019-03-16 23:16:07 UTC
Oh guys, I'm sorry, my touchpad's firmware just bugged, I reflashed it and turns out that patch works good. So it has to work on other's laptops with the same touchpad too.

But why do we have to move i2c_hid_init_irq section under the i2c_hid_lookup_quirk?

Comment 170 Hans de Goede 2019-03-17 22:21:34 UTC
(In reply to Vladislav from comment #169)
> But why do we have to move i2c_hid_init_irq section under the
> i2c_hid_lookup_quirk?

Because i2c_hid_init_irq now checks for a quirk, so we must setup the quirks before we init the irq, and we cannot setup the quirk earlier, so we must init the irq later.

Comment 171 Vladislav 2019-03-17 23:31:34 UTC
So can we call this patch final now? Or do we have to do some improvements?

Comment 172 Vladislav 2019-03-19 23:08:52 UTC
I've opened a pull request, so let's discuss the patch there: https://github.com/torvalds/linux/pull/663

Comment 173 vivien.frasca 2019-03-27 19:05:15 UTC
Vladislav, have you got any news about the merging progress of your patch ?

Comment 174 Will Roberts 2019-03-29 12:55:38 UTC
Vivien, there's a thread on patchwork here:

https://patchwork.kernel.org/patch/10869095/

Comment 175 Vladislav 2019-03-31 18:22:39 UTC
Hello guys. Yes, I have some news, but they are not that good.

At this moment my patch works, but, we have to make sure that touchpad never looses edge quirk. With my patch, after a suspend touchpad starts to act as unpatched and journalctl is being flooded with the same messages, so at the moment we are working at this problem. After that I think guys will accept my patch.

Comment 176 vivien.frasca 2019-04-01 06:07:06 UTC
Hi Vladislav, I've already noticed this wrong behavior without any patch. I've opened a bug issue for this here https://bugzilla.redhat.com/show_bug.cgi?id=1645042

Maybe it is nearly related...

Comment 177 vivien.frasca 2019-05-03 14:36:28 UTC
*** Bug 1678720 has been marked as a duplicate of this bug. ***

Comment 178 Chris Chiu 2019-06-13 05:07:58 UTC
Created attachment 1580081 [details]
signal output from scope of ELAN touchpad

Comment 179 Chris Chiu 2019-06-13 05:46:21 UTC
Hi guys,
    I also have some ASUS laptops which suffer from the same problem. It always happens on the Intel powered machines which connect the GPIO to the interrupt pin of the touchpad per the test I ran on so many ASUS laptops in hand. So I tried the I2C_HID_QUIRK_BOGUS_IRQ quirk and it did help. Thanks for your great effort. For curiosity, I installed Windows 10 on the same problematic machine and tried to check the value of the PADCFG0/PADCFG1 of this particular pin for touchpad interrupt. I want to confirm whether if Windows driver also configured the same pin to be edge triggered. The reading in Windows of PADCFG0 is 0x80800102 which is the same as in Linux. And PADCFG1 is 0x000030b1 which differs from 0x000000b1 in Linux. That's not expected because the touchpad works good under Windows. So I install back to Linux on the problematic laptop with latest 5.2.0 rc kernel with reverted  then send the machine to ELAN for signal analysis. The signal does show unexpected behavior. Please refer to the https://bugzilla.redhat.com/attachment.cgi?id=1580081 for the signal of I2C data and interrupt. It shows two I2C data read has been issued for single interrupt. I then add some verbose printk to identify the timing of the irq triggered and data read. Basically, they are following the same pattern down below. 2 successful i2c read followed by 2 zero invalid read, then comes another successful read again. The interesting part is the 4 i2c read is complete within 3~4 msecs, which means each read is issued by merely ~1msec. Compared to the edge trigger case, each interrupt/read is gapped by 6~7 msec.

[   92.447996] intel_gpio_community_irq_handler enter
[   92.448687] input: 10 00 04 03 e1 06 af 01 71 56 01 00 1b 55 00 00
[   92.448787] intel_gpio_community_irq_handler enter
[   92.449428] input: 10 00 04 03 e1 06 af 01 8f 56 01 00 1b 55 00 00
[   92.449519] intel_gpio_community_irq_handler enter
No input data read.
[   92.450228] intel_gpio_community_irq_handler enter
No input data read
[   92.461398] intel_gpio_community_irq_handler enter
[   92.462013[ input: 10 00 04 03 21 0b 21 03 2d 29 01 00 15 55 00 00

So I wonder if it's possible that maybe 2 or more interrupts fired by a single low level period? I verified the intel_gpio_irq_mask,  intel_gpio_irq_ack, intel_gpio_irq_unmask sequence, nothing wrong. So it's either the interrupt not properly acked or somehow the pin controller think it's still in low level period and it needs another interrupt again.

Base on this assumption, I made a dirty hack to forcely impose a few msec debounce on the interrupt pin, it seems that the i2c_hid_get_input() can get valid data every time w/o complaints. I know the PADCFG2 is for debounce configuration, but it does not exist on most Intel machine. Is it possible do config_set to force a debounce (default 5ms) when i2c-hid request a GPIO as interrupt pin? Also require a software debounce implementation in pinctrl-intel. Just another idea for reference, yup, and it's more complicated than I2C_HID_QUIRK_BOGUS_IRQ.

Comment 180 Chris Chiu 2019-06-13 06:59:36 UTC
As to each interrupt processing sequence in pinctrl-intel.c, I do some verbose printk in irq related functions intel_gpio_irq_mask,  intel_gpio_irq_ack, intel_gpio_irq_unmask. It's quite straightforward, irq_handle, then mask interrupt, ack, wait until i2c_hid_get_input() done, unmask interrupt. Post here if anyone interested and maybe I can help to print more if necessary. 
[   91.821449] intel_gpio_community_irq_handler with pending 0x000008 enabled 0x000008
[   91.821452] intel_gpio_irq_mask_unmask mask true enter
[   91.821471] intel_gpio_irq_mask_unmask mask true gpp offset 0x000003 with padcfg 0x40810598 pending 0x000008 enabled 0x000000
[   91.821471] intel_gpio_irq_mask_unmask mask true end
[   91.821472] intel_gpio_irq_ack ack enter
[   91.821488] intel_gpio_irq_ack intr with gpp offset 0x000003 padcfg 0x40810598 pending 0x000008 enabled 0x000000
[   91.821489] intel_gpio_irq_ack ack end
[   91.821547] i2c_hid_irq before get input
[   91.929294] input: 10 00 04 01 25 04 b2 03 4b 40 01 00 13 54 00 00
[   91.929309] i2c_hid_irq after get input
[   91.929311] intel_gpio_irq_mask_unmask mask false enter
[   91.929335] intel_gpio_irq_mask_unmask mask offset 0x000003 with padcfg 0x40810598 pending 0x000008 enabled 0x000008
[   91.929335] intel_gpio_irq_mask_unmask mask false end

Comment 181 Chris Chiu 2019-06-13 07:35:06 UTC
Verified that https://github.com/torvalds/linux/commit/670784fb4ebe54434e263837390e358405031d9e has already fix this unexpected interrupt issue.

Comment 182 Benjamin Tissoires 2019-06-13 08:05:52 UTC
Thanks a lot Chris for the deep analysis.

(In reply to Chris Chiu from comment #181)
> Verified that
> https://github.com/torvalds/linux/commit/
> 670784fb4ebe54434e263837390e358405031d9e has already fix this unexpected
> interrupt issue.

Does this means that 5.2 final will be all set regarding this issue?
And could we remove I2C_HID_QUIRK_BOGUS_IRQ for the Elan products in i2c-hid then?

Comment 183 Chris Chiu 2019-06-14 02:14:32 UTC
Yes. The I2C_HID_QUIRK_BOGUS_IRQ is no longer required for the ELAN. We verified on the problematic machines we have. If anyone has the same problem, but the interrupt pin is controlled by APIC, not connected via GPIO, please let us know. At least I'm pretty sure ASUS laptops we have here has no such problem w/ the fix.

Comment 184 Vladislav 2019-06-17 21:54:42 UTC
That's amazing! Chris thank's a lot for that deep analysis! Finally we will have our asus laptop's fully working! I appreciate everybody who helped with this bug!

Thank you!

Comment 185 Will Roberts 2019-06-30 23:17:55 UTC
I'm just reporting back that, on my GL503VD machine with kernel 5.1.15, five-finger touches no longer crash the touchpad driver.

The touchpad continues to hang when the laptop is suspended, though.

dmesg has this when restoring from suspend:

[11049.357203] i8042: [2762052] d4 -> i8042 (command)
[11049.357274] i8042: [2762052] f2 -> i8042 (parameter)
[11049.377531] i8042: [2762057] fc <- i8042 (interrupt, 1, 12)
[11049.377546] i8042: [2762057] 60 -> i8042 (command)
[11049.378229] i8042: [2762057] 54 -> i8042 (parameter)
[11049.378293] i8042: [2762057] 60 -> i8042 (command)
[11049.378364] i8042: [2762057] 56 -> i8042 (parameter)
[11049.378458] i8042: [2762057] d4 -> i8042 (command)
[11049.378534] i8042: [2762057] f2 -> i8042 (parameter)
[11049.398797] i8042: [2762062] fc <- i8042 (interrupt, 1, 12)
[11049.398836] i8042: [2762062] 60 -> i8042 (command)
[11049.399292] i8042: [2762062] 54 -> i8042 (parameter)
[11049.399356] i8042: [2762062] 60 -> i8042 (command)
[11049.399482] i8042: [2762062] 56 -> i8042 (parameter)

and the irq/131-ELAN120 process shows up in top afterwards using 6.9% of CPU constantly (normally this process uses 0% of the CPU, going up to maybe 2% when there is a lot of tapping and moving on the touchpad).  Journalctl no longer fills up with error messages.  Reprobing the hid-i2c module makes the touchpad work again until the next system suspend.

I'll try to test out 5.2rc to see if that's any different.  I guess 5.2 final will also be released pretty soon.

Comment 186 Andy Shevchenko 2019-07-15 09:19:36 UTC
(In reply to Will Roberts from comment #185)
> I'm just reporting back that, on my GL503VD machine with kernel 5.1.15,
> five-finger touches no longer crash the touchpad driver.
> 
> The touchpad continues to hang when the laptop is suspended, though.
> 
> dmesg has this when restoring from suspend:
> 
> [11049.357203] i8042: [2762052] d4 -> i8042 (command)
> [11049.357274] i8042: [2762052] f2 -> i8042 (parameter)
> [11049.377531] i8042: [2762057] fc <- i8042 (interrupt, 1, 12)
> [11049.377546] i8042: [2762057] 60 -> i8042 (command)
> [11049.378229] i8042: [2762057] 54 -> i8042 (parameter)
> [11049.378293] i8042: [2762057] 60 -> i8042 (command)
> [11049.378364] i8042: [2762057] 56 -> i8042 (parameter)
> [11049.378458] i8042: [2762057] d4 -> i8042 (command)
> [11049.378534] i8042: [2762057] f2 -> i8042 (parameter)
> [11049.398797] i8042: [2762062] fc <- i8042 (interrupt, 1, 12)
> [11049.398836] i8042: [2762062] 60 -> i8042 (command)
> [11049.399292] i8042: [2762062] 54 -> i8042 (parameter)
> [11049.399356] i8042: [2762062] 60 -> i8042 (command)
> [11049.399482] i8042: [2762062] 56 -> i8042 (parameter)

I'm wondering if the touchpad restores into PS/2 mode rather than I²C.


> and the irq/131-ELAN120 process shows up in top afterwards using 6.9% of CPU
> constantly (normally this process uses 0% of the CPU, going up to maybe 2%
> when there is a lot of tapping and moving on the touchpad).  Journalctl no
> longer fills up with error messages.  Reprobing the hid-i2c module makes the
> touchpad work again until the next system suspend.

Hmm... Can you test if the patch from kernel bug tracker helps you, i.e.
https://bugzilla.kernel.org/show_bug.cgi?id=203995

Comment 187 Will Roberts 2019-07-25 14:49:59 UTC
OK, so I finally found and tested mainline 5.2.2; same problem as before, the touchpad works perfectly but stops responding after waking up from S3.  Reprobing the touchpad module gets it going again.

I'm compiling kernel 5.2.0 with Mika's patch (attachment 283515) now.  I'll report back once I've tested the touchpad behaviour.

Comment 188 Will Roberts 2019-07-26 08:39:15 UTC
Yeah, that patch did it, that's the last piece of the puzzle.  Now the touchpad works perfectly and also works after restoring from suspend.

Comment 189 Hans de Goede 2019-07-26 10:32:15 UTC
(In reply to Will Roberts from comment #188)
> Yeah, that patch did it, that's the last piece of the puzzle.  Now the
> touchpad works perfectly and also works after restoring from suspend.

Can you apply the patch (the new version ported to 5.2.2) here please? Then we will see from there.

Comment 190 Will Roberts 2019-07-26 17:07:23 UTC
Created attachment 1593771 [details]
mika's patch to save and restore all all gpio pins on suspend

This patch was taken from here: https://bugzilla.kernel.org/attachment.cgi?id=283515

Comment 191 Will Roberts 2019-07-26 17:09:52 UTC
Hi Hans, I'm not really sure what you mean.  The patch isn't mine, and for me it applies cleanly to 5.2 and 5.3rc1.  The file I've uploaded here is diffed from 5.3rc1.  Does that help?

Comment 192 Will Roberts 2019-07-26 18:13:52 UTC
vivien, I just noticed that the lid switch works on kernel 5.2.2 as well; back in comment 99 I said I thought this didn't have anything to do with GPIO etc., but quite possibly I was wrong about that.  I'm not sure what kernel version fixed the lid switch, but I am really happy that the hardware is all working now : )  The weird airplane mode LED toggling on restore from suspend has been fixed for a long time, but that never really bothered me all that much.

Benjamin, Hans, Andy, Mika, and others: thank you so much for all your help on this over the last 18 months.

Comment 193 Hans de Goede 2019-07-27 19:18:57 UTC
Will, thank you for the patch, I was afraid that when you wrote "Mika's patch" you were talking about the revert of a runtime-pm behavior modifying patch from a while ago, but now that I think more about this I think the patch some people tried to revert actually was from Rafael. Anyways reverting that patch never really was a proper solution to the issue some people were seeing, so it is great to see that it is not that patch which you are talking about.

It seems that what to do with the new patch is stilling being discussed in the upstream bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203995

So lets wait for the discussion there to be resolved.

Comment 194 Justin M. Forbes 2019-08-20 17:43:31 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.2.9-200.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Comment 195 Einer Petersen 2019-08-22 22:18:15 UTC
Upgraded to kernel-5.2.9-200.fc30.x86_64 via DNF and now touchpad does not work at all.
Rebooted to kernel-5.2.8-200.fc30.x86_64 (previous kernel) and touchpad works properly again.

----------------
[root@msi ~]# dmesg | grep -i elan
[    1.890370] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x4a5f01)
[    1.903518] psmouse serio1: elantech: Synaptics capabilities query result 0x10, 0x15, 0x0e.
[    1.915812] psmouse serio1: elantech: Elan sample query result 02, 89, 75
[    1.973356] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6
[root@msi ~]# 
-----------------

Comment 196 Vladislav 2019-08-23 10:24:22 UTC
Hi everyone, tested Mika's patch on 5.2.9 kernel on Debian, everything works fine and touchpad really restores the state from S3, except for my laptop randomly freezes after a suspend, I am trying to get the logs atm.

Comment 197 Vladislav 2019-08-23 12:43:09 UTC
Ok, been trying to reproduce it for 4 hours, suspend is working properly, I think it is not related to the driver.

Comment 198 Einer Petersen 2019-08-26 22:38:18 UTC
Ok, Here is what finally worked for me when booting kernel-5.2.9-200.fc30.x86_64

1) log into gnome DT
2) open a terminal
3) su - root OR sudo
4) echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol

Now touchpad works until I reboot ........ 

.... Ugly solution that works for the time being until someone figures out "Why I did not have to do this in kernel-5.2.8-200.fc30.x86_64" and fix kernel-5.2.9-200.fc30.x86_64 ......


Machine: MSI GS63 Stelth 8RE .... Model MS-16K5

Comment 199 Vladislav 2019-08-27 11:33:40 UTC
For some reasons on patched kernel I can't log out, system freezes. Can someone try to logout to confirm the bug?

Comment 200 Vladislav 2019-08-31 14:51:51 UTC
Okay it seems fine after some days, I think this is an issue of compiling the patch but not building a package, I will try to build one and come back with the results.

Comment 201 Einer Petersen 2019-09-09 21:20:56 UTC
Ok,

I am at kernel:
[root@msi ~]# uname -a
Linux msi.page34.net 5.2.11-200.fc30.x86_64 #1 SMP Thu Aug 29 12:43:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@msi ~]# 

And the problem still persists

And this still works to resolve ... so far ......
1) log into gnome DT
2) open a terminal
3) su - root OR sudo
4) echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol

Now touchpad works until I reboot ........ 


Anyone have any idea how to fix this so that it works properly, like it did prior to kernel kernel-5.2.9-200.fc30.x86_64?

Comment 202 Justin M. Forbes 2019-09-11 09:31:23 UTC
I believe 5.2.9 problem to be fixed with the 5.2.13 stable update. Can you please test with 5.2.13 or newer and confirm?

Comment 203 Einer Petersen 2019-09-11 16:03:06 UTC
Ok ...... 

I am at kernel:
[root@einer-hp ~]# uname -a
Linux einer-hp.page34.net 5.2.13-200.fc30.x86_64 #1 SMP Fri Sep 6 14:30:40 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@einer-hp ~]# 

Via this mornings dnf update .......

Elantech Touchpad works properly again :-)


Thank You!!!! :-)

Comment 204 Einer Petersen 2019-10-16 16:58:27 UTC
Ohhhh Fellasssss ..... it's back........

Just did a dnf update and at kernel:

 [root@msi ~]# uname -a
Linux msi.page34.net 5.3.5-200.fc30.x86_64 #1 SMP Tue Oct 8 12:41:15 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@msi ~]# 

it quit working ... again ......

Using my previous work-around still works:
1) log into gnome DT
2) open a terminal
3) su - root OR sudo
4) echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol

Now touchpad works until I reboot ........


So ........ could you guys fix it again and maybe make a note somewere to the effect of "Remember the fix you did for this in kernel 5.2.13-200.fc30.x86_64 #1 SMP Fri Sep 6 14:30:40 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux .... maybe you might want to make sure that when you mess with a new kernel, you remember this fix..."

Comment 205 Jim Smith 2019-10-17 05:08:07 UTC
(In reply to Einer Petersen from comment #204)
> Ohhhh Fellasssss ..... it's back........
> 
> Just did a dnf update and at kernel:
> 
>  [root@msi ~]# uname -a
> Linux msi.page34.net 5.3.5-200.fc30.x86_64 #1 SMP Tue Oct 8 12:41:15 UTC
> 2019 x86_64 x86_64 x86_64 GNU/Linux
> [root@msi ~]# 
> 
> it quit working ... again ......
> 
> Using my previous work-around still works:
> 1) log into gnome DT
> 2) open a terminal
> 3) su - root OR sudo
> 4) echo -n "elantech"> /sys/bus/serio/devices/serio1/protocol
> 
> Now touchpad works until I reboot ........
> 
> 
> So ........ could you guys fix it again and maybe make a note somewere to
> the effect of "Remember the fix you did for this in kernel
> 5.2.13-200.fc30.x86_64 #1 SMP Fri Sep 6 14:30:40 UTC 2019 x86_64 x86_64
> x86_64 GNU/Linux .... maybe you might want to make sure that when you mess
> with a new kernel, you remember this fix..."


Rather than using your method which only works until you reboot, there is a permanent workaround. According to https://bugzilla.redhat.com/show_bug.cgi?id=1634832 you can add the following kernel parameter.

psmouse.elantech_smbus=0

You can install the grub-customiser to make adding a parameter easier.

Comment 206 Einer Petersen 2019-10-17 14:48:06 UTC
THANK YOU Jim Smith!!!!!!  :-)

That works :-)

Next question ...... 
How do I put this into /etc/modprobe.d so that I don't have to modify the kernel command line?


Einer

Comment 207 vivien.frasca 2019-10-24 09:15:40 UTC
I consider the original problem is solved since few month. Can we close this bug ?

Comment 208 Vladislav 2019-10-24 09:49:59 UTC
(In reply to vivien.frasca from comment #207)
> I consider the original problem is solved since few month. Can we close this
> bug ?

I don't know if anyone else has small lags just as me with 5.3.6 kernel. It kinda doesn't capture it's first movements. dmesg shows some PCI errors, but I don't know if they have anything to do with the touchpad:

[  590.254925] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[  590.254932] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[  590.254933] pcieport 0000:00:1c.5: AER:   device [8086:a115] error status/mask=00001000/00002000
[  590.254934] pcieport 0000:00:1c.5: AER:    [12] Timeout               
[  590.275896] pcieport 0000:00:1c.5: AER: Corrected error received: 0000:00:1c.5
[  590.275904] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[  590.275906] pcieport 0000:00:1c.5: AER:   device [8086:a115] error status/mask=00001000/00002000
[  590.275909] pcieport 0000:00:1c.5: AER:    [12] Timeout               
[  594.430923] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: 0000:00:1c.5
[  594.430935] pcieport 0000:00:1c.5: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
[  594.430936] pcieport 0000:00:1c.5: AER:   device [8086:a115] error status/mask=00001000/00002000
[  594.430937] pcieport 0000:00:1c.5: AER:    [12] Timeout        

Is anyone else has great experience on latest kernel or has these small lag problems?

Comment 209 vivien.frasca 2019-10-24 10:08:25 UTC
@Vladislav, You probably should open a new bug for your specific problem (I don't have your king of lags).

This bug ticket is pretty huge and it should, IMHO, be a good idea to close it.

Does someone of RedHat team can close this bug as Resolved ?

Comment 210 Vladislav 2019-10-24 11:08:41 UTC
Just tested suspend on Linux manjaro 5.3.6-1-MANJARO #1 SMP PREEMPT Sat Oct 12 09:30:05 UTC 2019 x86_64 GNU/Linux, touchpad doesn't work after resume.
dmesg:

timeout flood
[ 1171.086759] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.111498] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.136638] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.161506] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.186494] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.210323] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.234887] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.259800] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.284645] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.309981] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.335490] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.361447] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.386561] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.411472] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1171.435594] i2c_designware i2c_designware.0: timeout waiting for bus ready
restarted by `sudo rmmod i2c_hid && sudo modprobe i2c_hid`, unsuccessfully
[ 1171.516336] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not found, using dummy regulator
[ 1171.516367] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vddl not found, using dummy regulator
[ 1171.540920] i2c_designware i2c_designware.0: timeout waiting for bus ready
[ 1172.719440] i2c_designware i2c_designware.0: timeout in disabling adapter
restarted again - successfully
[ 1190.659198] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not found, using dummy regulator
[ 1190.659250] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vddl not found, using dummy regulator

Comment 211 Sami Sh 2020-01-21 23:07:46 UTC
the elan1200 touchpad became not found on fedora 31 5.4+ kernel.
it was working fine on 5.3 and less...

Comment 212 Andy Shevchenko 2020-05-06 11:17:47 UTC
(In reply to Vladislav from comment #210)
> Just tested suspend on Linux manjaro 5.3.6-1-MANJARO #1 SMP PREEMPT Sat Oct
> 12 09:30:05 UTC 2019 x86_64 GNU/Linux, touchpad doesn't work after resume.
> dmesg:
> 
> timeout flood
> [ 1171.086759] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.111498] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.136638] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.161506] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.186494] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.210323] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.234887] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.259800] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.284645] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.309981] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.335490] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.361447] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.386561] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.411472] i2c_designware i2c_designware.0: timeout waiting for bus ready
> [ 1171.435594] i2c_designware i2c_designware.0: timeout waiting for bus ready

Can you check if the patch helps: https://lore.kernel.org/linux-gpio/CAHp75VekvqHX_eUm88RQJQiU59hUoxUY=pP4MWsp6xn3os9bPg@mail.gmail.com/T/#t

Comment 213 NuLL3rr0r 2022-01-24 09:49:40 UTC
(In reply to Vladislav from comment #155)
> ATTENTION EVERYONE! MODULE FIXED!
> 
> I've contacted ELANTECH about my touchpad issue, and they sent me right
> WinIAP hardware, and if someone also reflashed their touchpad with a wrong
> firmware, send me an email, and I will send it to you.
> I have firmwares for: 04F3:3090, 04F3:303E, 04F3:304E.
> 
> And they sent me a kernel patch which solved ALL ISSUES. NO FIVE FINGER TAP
> FREEZE and PERFECT work of touchpad. Intel suggested this patch, though it
> seems patch is not applied to the main kernel and I can see no merge
> request's for it, so I will open one, if ELAN let me do this.
> 
> Sending patch in next message.

Could you please kindly send the firmware for ELAN1200 04F3:3090 to me as well? I have the same model and did the same exact mistake.

Thank you!


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