Bug 101094

hmm, that's not good. the problem is that your touchpad merely gives us x/y locations and nothing else. libinput's touch thresholds can't kick in here because, well, there are no thresholds we get. I'm sorry, we can't do anything here, there is no data we could use to make this more useful.

There's no CANTFIX resolution, so I'm choosing WONTFIX instead

CC-ing benjamin in case he has any more suggestions, but...

just seeing this one again - please file a separate bug for the tap time, thanks.

(In reply to Peter Hutterer from comment #1)
> hmm, that's not good. the problem is that your touchpad merely gives us x/y
> locations and nothing else. libinput's touch thresholds can't kick in here
> because, well, there are no thresholds we get. I'm sorry, we can't do
> anything here, there is no data we could use to make this more useful.
> 
> There's no CANTFIX resolution, so I'm choosing WONTFIX instead
> 
> CC-ing benjamin in case he has any more suggestions, but...

Thank you for your answer.

Do you have any idea where this absence of PRESSURE information from the touchpad could come from ?

Is it a hardware problem (which seems weird to me since it is a very recent notebook), or is it software (kernel, driver ?)

Cheers

boot with i2c_hid.debug=1 and attach the dmesg output please, that may have some information. And I guess the output from hid-record for a short touch sequence won't hurt either.

(In reply to Peter Hutterer from comment #4)
> boot with i2c_hid.debug=1 and attach the dmesg output please, that may have
> some information. And I guess the output from hid-record for a short touch
> sequence won't hurt either.

Could you please explain in more detail what booting with i2c_hid.debug=1 consists in as well as attaching the dmesg output ?

I am quite a beginner in playing with hardware/drivers :)

no worries. booting with that argument means hit a key at the grub prompt, select the entry to boot and add a module parameter to the boot command line. See the first answer to this question:
https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter

dmesg is easiest via journal: journalctl -kb > kernel.log, then attach this here as bugzilla attachment (see the Add an attachment link)

Created attachment 131512 [details]
Kernel Log with boot option i2c_hid.debug=1

(In reply to Peter Hutterer from comment #6)
> no worries. booting with that argument means hit a key at the grub prompt,
> select the entry to boot and add a module parameter to the boot command
> line. See the first answer to this question:
> https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter
> 
> dmesg is easiest via journal: journalctl -kb > kernel.log, then attach this
> here as bugzilla attachment (see the Add an attachment link)

Thank you for your answer, I have just attached the kernel log.

Cheers

Thanks for the log. However, it doesn't contain the debug information :)

No big deal, it's actually easier/better to just provide a hid-recording of the touchpad. Grab hid-replay from http://bentiss.github.io/hid-replay-docs/ and follow the instructions for compiling from the sources if you are not running Fedora.

Then provide a hid-recorder output of the touchscreen (run this as root).

(In reply to Benjamin Tissoires from comment #9)
> Thanks for the log. However, it doesn't contain the debug information :)
> 
> No big deal, it's actually easier/better to just provide a hid-recording of
> the touchpad. Grab hid-replay from http://bentiss.github.io/hid-replay-docs/
> and follow the instructions for compiling from the sources if you are not
> running Fedora.
> 
> Then provide a hid-recorder output of the touchscreen (run this as root).

Thanks for the reply, and sorry for the log which doesn't contain debug information, I guess I am definitely a beginner in this field :)

You will find attached the hid-recording of the touchpad.

Cheers

Created attachment 131808 [details]
Hid-recording of the touchpad

Thanks for the log.

After parsing the hid-recorder output, it seems the device simply doesn't export pressure/width information, which explains why the kernel doesn't export it.

There are 4 bytes at the end of each report which are tagged as proprietary protocol and constant that might or not be somewhat close to a pressure, but give it has been explicitly marked to be discarded I wonder if this is not just some left over from a different firmware version.

Anyway, long story short: we can't do much at the kernel level, we don't have more information than what we report to user space already.

(In reply to Benjamin Tissoires from comment #12)
> Anyway, long story short: we can't do much at the kernel level, we don't
> have more information than what we report to user space already.

I have a Zenbook UX310UQ and a similar problem.

[    2.500440] input: ELAN1200:00 04F3:3022 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-ELAN1200:00/0018:04F3:3022.0001/input/input12
[    2.501905] hid-multitouch 0018:04F3:3022.0001: input,hidraw0: I2C HID v1.00 Mouse [ELAN1200:00 04F3:3022] on i2c-ELAN1200:00

It's handled by the hid-multitouch module, not by the elan_i2c. When I unload the hid-multitouch and load the elan_i2c, a kernel can't recognise it. Can it be that the hardware is actually able to work in another mode and use another protocol and it just needs some appropriate firmware?

The problem with the absence of the pressure data is that a driver on 2 finger touches and releases can't choose a right action to do: to trigger right click or two finger scroll or start locked dragging which results in random right clicks and dragging selections during scrolling.

The problem can be partially solved in a userspace driver: to make some timeout between scrolls, eg when 2 finger scrolling changes direction, to block triggering right clicks and drags during scrolling, to make more precise limits for delta in coordinates which decide whether an event is a move or a touch-release, register right click drag only with a first two finger tap and move with the one finger. I'd been implementing these features for a FreeBSD Cypress driver which worked using IntelliMouse protocol, I made a simple state machine. But the solution is far from perfect anyway.

I think that the ambiguity in actions for a two-finger event can be also resolved by recording statistics of events and using some learning algorithm to tweak probabilities, and then to keep little history of events in a driver, for example ten recent events as an input data for inference.


I have made some hacks to the synaptics driver which merely block right clicks after two finger scrolling have started and unblock after a second release event and couple of additional checks, at least it doesn't make two finger scrolls painful infesting it with random right clicks, although makes right clicks somewhat complicated. I hope that there will be some advances with drivers from the hardware manufacturers.

After several kernel and libinput updates, my touchpad still behaves unpredictibly. That is, really too sensitive, and sometimes lagging and creating unwanted events (clicks, right clicks...)

Do you have any news on the support of this elantech touchpad, whether it will be improved or not ?

(As a comparison, the touchpad works just fine on my W$ dual-booted install)

Attach another evemu recording, with data please. As said above we don't seem to have any information that we can use to differentiate between a light and a true touch so I'm not sure there's much we can do. There's still the slim chances of the touchpad talking some other protocol but I wouldn't rely on it.

There are custom solutions that can reduce the level of pain but I'm hesitant to get those into libinput proper unless there is a significant percentage of users affected by it. Adding custom solutions like this add a lot of extra cost for maintenance.

Created attachment 135555 [details]
Evemu-recording

You will find attached a new evemu recording, with latest kernel version (4.14) and libinput (1.9.1-1)

On this recording, the touchpad behaved without particular bugs.

Also, there seems to be some Asus specific issue with the Elan touchpad :
https://bugs.freedesktop.org/show_bug.cgi?id=98770