Bug 203467

Seems to be fixed by Kernel 5.21. I think it's okay to close it.

There's no such thing as kernel 5.21 (at least not before a couple years). Which kernel version fixed it exactly?

(In reply to Jean Delvare from comment #2)

> Which kernel version fixed it exactly?

Sorry for my making a typo. I was meaning 5.2.1 (https://git.archlinux.org/linux.git/tag/?h=v5.2.1-arch1) on Arch Linux. I'm not sure what it points at in Kernel repository since Arch seems to apply some patches by theirselves. Since this problem is not 100% reproducible, it's me that just realized the problem happens really rare in the recent Kernel builds.

Is there any tools, if possible, allowing me to obtain more useful information for you when the problem (occasionally) happens again?

OK, so it's better (problem happens less frequently) since kernel 5.2.1 but not completely fixed, right?

Before kernel 5.0.10, was the problem happening sometimes too, or never at all?

The most promising change in 5.0.10 to explain the different behavior is:

    Input: elan_i2c - add hardware ID for multiple Lenovo laptops

    commit 738c06d0e4562e0acf9f2c7438a22b2d5afc67aa upstream.

This commit adds ID ELAN061B (among others) to the elan_i2c driver, which is what your laptop uses. This suggests that, up to kernel 5.0.9, your touchpad was NOT handled by the elan_i2c driver. I suppose that some generic driver was used instead. You can verify this theory by checking the following symlink on 5.0.9 and then 5.0.10 (or later):

    /sys/class/input/mouse0/device/device/driver

(You may have have to adjust mouse number if you have an external mouse connected in addition.)

So I believe that this is not a regression in the elan_i2c driver. Instead, the problem would be that your laptop was originally not properly handled by the elan_i2c. There have been a number of fixes to the driver meanwhile, which could explain why a more recent kernel works for you.

You may try blacklisting the elan_i2c driver (you may have to rebuild your initrd) and see if the problem disappears completely. You'll miss the additional features provided by this driver though.

Anyway, unless you have any errors logged by the i2c-i801 driver, this does not look like an I2C bug, so I'm moving your report to the Input Devices component.

There is a high chance this is related to the interrupt associated with the device. Usually, when the interrupt is not correctly set (because there is a bug in the gpio controller), we see these semi-random issues on touchpads.

As Jean requested, it would be interesting to know which driver was used before, and also what is the actual interrupt used by elan_i2c. We will likely need to have a look at the DSDT to understand fully the problem :/

(In reply to Benjamin Tissoires from comment #5)
> OK, so it's better (problem happens less frequently) since kernel 5.2.1 but
> not completely fixed, right?
Yes, but I'm not sure the fix (if exists) lies on 5.2.1 or earlier.

> Before kernel 5.0.10, was the problem happening sometimes too, or never at
> all?
Never at all since I installed this linux distribution (it was linux 5.0.6 then).

> So I believe that this is not a regression in the elan_i2c driver.
I checked and found the touchpad was handled by:
  ../../../../../../../bus/hid/drivers/hid-multitouch/ (or /sys/bus/hid/drivers/hid-multitouch)
at 5.0.9, and is handled by:
  ../../devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-ELAN061B:00/input/input10/mouse1/ (I plugged in a mouse at that time of boot, and it's likely to be the reasons that it's mouse1 rather than mouse0)
at 5.0.10, so the assumption is very likely to be right.

I'll blacklist elan_i2c and try to trigger a reproduction. If there's any test needed, please don't hesitate to tell me.

Eh... I made a mistake at the quotation author on the last comment.

Please attach the output of:

$ cat /proc/interrupts

an a kernel where the elan_i2c driver is used (not blacklisted). As well as a tarball of the ACPI tables of your laptop (as generated by acpidump).

You may look for a BIOS update for your laptop too. Who knows...

The interrumps is present here: https://cfp.vim-cn.com/cbf1m 
where "lsmod | grep elan" gives "elan_i2c               49152  0" (showing elan_i2c driver is used).

ACPI tables are put here: https://drive.google.com/open?id=1-O-Dmr6_AnTmNy1My8MtJrrukzt2Jr5H

I'll check with vendor whether a BIOS update is available.

There's a link "Add an attachment" at the top of the bug which will let you attach the files directly to the bug report. Most developers prefer when all relevant files are attached. Just saying.

Created attachment 284275 [details]
/proc/interrupts when elan_i2c is enabled

Created attachment 284277 [details]
Result of acpidump when elan_i2c is used

Minutes ago a new type of error is displayed:

 elan_i2c i2c-ELAN061B:00: invalid report id data (d)

OK, I think I now understand:
before the commit you mentioned, your device was handled by hid-multitouch. And it was working fine. However, the Elan engineers switched the device to use elan_i2c as it has a few more capabilities than a plain hid-multitouch.

*but*, the device has some input reporting modes that are not handled by elan_i2c :/

The bad news is that kernel v5.3 will not allow you to rebind hid-multitouch on this device.

So, can you attach the output of hid-recorder[0] (as root) when you reliably reproduce the first error ("invalid report id 1"), but with hid-multitouch? You said while sliding on the touchpad, or pressing the buttons.

Even if you can not entirely reproduce it, we might be able to understand what are reports ID 1 and 0xd, and understand why they are not implemented in elan_i2c.

[0] project hid-tools: https://gitlab.freedesktop.org/libevdev/hid-tools

(In reply to Benjamin Tissoires from comment #14)
> So, can you attach the output of hid-recorder[0] (as root) when you reliably
> reproduce the first error ("invalid report id 1"), but with hid-multitouch?
> You said while sliding on the touchpad, or pressing the buttons.

This bug has never happened on hid-multitouch. It only comes up occasionally after my touchpad is handled by elan_i2c. Therefore, did you mean elan_i2c here?

(In reply to Benjamin Tissoires from comment #14)
> So, can you attach the output of hid-recorder[0] (as root) when you reliably
> reproduce the first error ("invalid report id 1"), but with hid-multitouch?
> You said while sliding on the touchpad, or pressing the buttons.

Eh.. Later today I thought you meant:
- Touchpad unavailable on elan_i2c
- Rebind touchpad device to hid-multitouch
- Record touchpad movements with hid-recorder

If what I thought is right then that's the results:

* Error from elan_i2c: elan_i2c i2c-ELAN061B:00: invalid report id data (d)

* What I did to attempt rebinding:
  - modprobe hid-multitouch
  - echo -n "i2c-ELAN061B:00" > /sys/bus/i2c/drivers/elan_i2c/unbind
  - echo i2c-ELAN061B:00 > /sys/bus/i2c/drivers/i2c_hid/bind

Recording by hid-recorder will be uploaded as attachment minutes later.

Created attachment 284431 [details]
Output of hid-recorder with hid-generic (--output)

Created attachment 284433 [details]
Output of hid-recorder with hid-generic (in-terminal)

Operation I was doing in accordance to outputs:
* 0-2s, 3-6s: Single finger sliding on touchpad
* 8-9s, 9-10s: Pressing left button on touchpad
* 12-13s, 13-14s: Pressing right button on touchpad
* 16-19s: Double finger sliding on touchpad

By rebinding steps I mentioned on Comment 16, the result of "ls -la /sys/class/input/mouse0/device/device/driver" is "../../../../../../../bus/hid/drivers/hid-generic/" rather than hid-multitouch. If you want the results of hid-recorder with hid-multitouch, please give me some tips on how to set the driver to hid-multitouch (rather than hid-generic) and I'll be more than glad to test it.

Created attachment 284443 [details]
0001-input-elan_i2c-print-debug-information-when-the-repo.patch

Thanks for the logs. And yes, that's what I meant. There is no way to retrieve the description of the reports fronm elan_i2c, so we need to bind it to i2c_hid.

In the `--output` log, there is the report descriptor, and it shows that the report ID 1 is the mouse emulation that has the touchpad is sending when configured to not be in the multitouch mode.
It's weird it sends those events when bound to elan_i2c. I'll contact Elan about that.

Meanwhile it could be interesting to debug which events are actually sent. Can you apply the patch, and watch the dmesg when the bug appears? It should hopefully provide us the report data, and *maybe*, if I am correct, we will be able to decipher those with the logs you just provided.

Created attachment 284489 [details]
elan_isr report on invalid report id data (d)

Here's the logs. It's collected on v5.2.9-arch1 [1].

On the timeline:
- 1672.9 - 1674.8: Two sliding on touchpad
- 1733.4 - 1733.5: Left clicking on button
- 1752.45 - 1752.46: Right clicking on button
- 1904.74: Single click on touchpad

1. https://git.archlinux.org/linux.git/commit/?h=v5.2.9-arch1&id=ad1ca04b888b1a530c782e437e1e3410f9be4702

sigh, every time we receive this data, we receive the exact same values, so I guess it means we can not work on this side. I wonder if the PNPID was not added in error.

We got confirmation from Elan that your touchpad should be using hid-multitouch, and that the PNPId used is incorrect in the BIOS.

It seems to be a mixup from Lenovo, but I think we should probably remove your PNPId from the list in include/linux/input/elan-i2c-ids.h

Created attachment 284855 [details]
0001-Input-elan_i2c-remove-Lenovo-Legion-Y7000-PnpID.patch

Can you test the attached patch?

It seems that elan-i2c-ids.h doesn't exist yet on my current running linux kernel [1], so I applied the patch over the current HEAD of Arch Linux kernel repository [2] and built the elan_i2c.ko. It successfully made my touchpad use hid-multitouch by default on starting up.

[1].  https://git.archlinux.org/linux.git/tag/?h=v5.2.11-arch1
[2]. https://git.archlinux.org/linux.git/commit/?id=9cf6b756cdf2cd38b8b0dac2567f7c6daf5e79d5

Fixed by removing ELAN-061B from elan-i2c-ids.h.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/input/elan-i2c-ids.h?id=0c043d70d04711fe6c380df9065fdc44192c49bf

Let's close this bug since it's fixed. Please correct me if I chose a wrong status.

Hi,

I am having similar issues with an ELAN-060F in the lenovo ideapad 120s-14iap

    [  750.442908] elan_i2c i2c-ELAN060F:00: invalid report id data (1)
    [  750.450086] elan_i2c i2c-ELAN060F:00: invalid report id data (1)
    [  750.457128] elan_i2c i2c-ELAN060F:00: invalid report id data (1)
    [  750.464062] elan_i2c i2c-ELAN060F:00: invalid report id data (1)
    [  750.470892] elan_i2c i2c-ELAN060F:00: invalid report id data (1)
    [  750.479899] elan_i2c i2c-ELAN060F:00: invalid report id data (1)


Thank you

I am having the exact same problem with a Lenovo Yoga 7 - 14ARE05. The touchpad in question is i2c-ELAN0634:00.

Blacklisting the elan_i2c driver instantly fixes the issue for me as well. Might be worth removing this model from elan-i2c-ids.h as well.