Bug 196619 - ELAN1200 Touchpad in Asus ultrabooks, unwanted release events
Summary: ELAN1200 Touchpad in Asus ultrabooks, unwanted release events
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-09 06:23 UTC by Alexander Mishurov
Modified: 2019-11-24 13:32 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.11
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Alexander Mishurov 2017-08-09 06:23:15 UTC
I have a problem with ELAN1200 touchpad, the touchpad is installed in some ASUS ultrabooks: UX310, UX410, UX330, UX360, may be others. In general it works as a hid-i2c device but has the idiosyncrasies. It reports several hid usages with the code 0x900c5 and one of them is height/weight of a contact decoded in 4 bytes. But it's actually isn't a problem, I can extract it in the raw event. It also some times reports fake events for the fifth contact, it's not a big problem either.

The actual problem is that when two contacts are close enough, let's say a diagonal between contact coordiantes is less than 400 units in touchpad's coordinates, touchpad automaticaly fires release events for the contacts and starts report them as one contact with the coordianates something around the means of the previous two ones. This behaviour causes random right-button two-finger taps during two finger scrolling.

I'm trying to tackle the problem in my custom driver
https://github.com/mishurov/linux_elan1200_touchpad

I have a shallow experience with kernel drivers and I need help. These are decoded reports I've printed from a userspace driver to show the occasions when I want to suppress the release events.

This is when the touchpad starts to report two fingers as one:

id 1 -        994  -        441  - 64 -  5 -  4 - 1
id 0 x 1406        y  287        c 64 w  4 h  4 t 1
id 1 -        994  -        441  - 64 -  5 -  4 - 1
id 0 x 1406        y  287        c 64 w  4 h  4 t 1
id 1 -        994  -        441  -  0 -  5 -  4 - 0
id 0 x 1406        y  287        c  0 w  4 h  4 t 0
id 1 -       1146  -        390  - 64 -  6 -  5 - 1
id 1 -       1146  -        390  - 64 -  6 -  5 - 1
id 1 -       1146  -        390  - 64 -  6 -  5 - 1
id 1 -       1146  -        390  - 64 -  6 -  5 - 1

id: id of a contact
c: confidence (encoded with a clickpad button state)
x, y: coords (x: 0 - 3200, y: 0 - 2198)
w, h: width, height (both: 0 - 15, unscaled according to the h/w ratio of a touchpad)
t: 1 for touch, 0 for release


This is the report when two fingers are being reported as one and then the distance between them becomes big enough and the touchpad starts to report them as two contacts.

id 0 x 1359        y  275        c 64 w  7 h  5 t 1
id 0 x 1360        y  274        c 64 w  7 h  5 t 1
id 0 x 1360        y  274        c 64 w  7 h  5 t 1
id 0 x 1360        y  274        c 64 w  7 h  5 t 1
id 0 x 1360        y  274        c  0 w  7 h  5 t 0
id 0 x 1200        y  411        c 64 w  5 h  5 t 1
id 1 -       1556  -        108  - 64 -  4 -  4 - 1
id 0 x 1200        y  411        c 64 w  5 h  5 t 1
id 1 -       1556  -        108  - 64 -  4 -  4 - 1
id 0 x 1200        y  411        c 64 w  5 h  5 t 1
id 1 -       1556  -        108  - 64 -  4 -  4 - 1
id 0 x 1200        y  411        c 64 w  5 h  5 t 1
id 1 -       1556  -        108  - 64 -  4 -  4 - 1


These transitions happen without actual releases of contacts but touchpad reports the releases and I want to supress them. Because it happens quite often during two-finger scrolling. A Xorg driver eventually reports either a random two-finger right-tap or a tap-and-drag gesture because of those artificial release events.

My problem is that at the moment when the touchpad reports a release I can't say with the probability of 1 whether it's an actual release or it starts splicing the contacts, I can check it only on the next touch events. But if it was an actual release then there would be no further reports and if I just suppress the release event it will be the "sticky fingers" problem.

Is there a some kind of a delayed queye in kernel to report an event one step later? I tried to use timers. Or may be there's some other solution. Or may be it should be handlend in a userspace driver.
Comment 1 Tasev Nikola 2019-01-31 11:23:30 UTC
Hi Alexander

I have the same problem on a Asus UX330 with the same ELAN1200 touchpad.
I succeed to build a custom kernel 4.20 with your custom driver
an it works really great. Thank you for that!
I did not find a way to build your xorg synaptics driver.
I'm on KDE Neon (Debian Ubuntu based)

Tank's again for your work on this problem.

Tasev Nikola
Comment 2 Alexander Mishurov 2019-01-31 12:22:54 UTC
(In reply to Tasev Nikola from comment #1)
> I did not find a way to build your xorg synaptics driver.

Nikola, you can clone or download the source code for 1.9.0 and 1.9.1 versions from there 
https://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/
apply the patch e.g. 'git apply /path/to/drop_releases.diff' and compile it './configure && make'. To generate an .so file I used './libtool --mode=install /usr/bin/install -c src/synaptics_drv.la /destination/path/'. The resulting .so file should be put where xorg's input drivers are located.

If you're going to use the xorg patch, there's no need to use the kernel driver because the patched xorg driver does the same yet in the user space.
Comment 3 Tasev Nikola 2019-01-31 13:32:53 UTC
(In reply to Alexander Mishurov from comment #2)
> (In reply to Tasev Nikola from comment #1)
> > I did not find a way to build your xorg synaptics driver.
> 
> Nikola, you can clone or download the source code for 1.9.0 and 1.9.1
> versions from there 
> https://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/
> apply the patch e.g. 'git apply /path/to/drop_releases.diff' and compile it
> './configure && make'. To generate an .so file I used './libtool
> --mode=install /usr/bin/install -c src/synaptics_drv.la /destination/path/'.
> The resulting .so file should be put where xorg's input drivers are located.
> 
> If you're going to use the xorg patch, there's no need to use the kernel
> driver because the patched xorg driver does the same yet in the user space.

Thank you, I will try to build the synaptics driver, but I have no access
to the UX330 right now (it's my daugther ultrabook). She is student an will be back at the end of march, I will test your synaptics patch then an report back.

Tasev Nikola

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