fails to suspend unless I unbind a device from elants_i2c driver
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
linux-oem-5.6 (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
linux-signed-hwe-5.8 (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
systemctl suspend stopped working successfully.
The error message from journalctl -r is:
Oct 17 17:26:27 jeanna-pc kernel: PM: Device i2c-ELAN0001:00 failed to suspend: error -16
Oct 17 17:26:27 jeanna-pc kernel: PM: dpm_run_callback(): acpi_subsys_
Oct 17 17:26:27 jeanna-pc kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Oct 17 17:26:27 jeanna-pc kernel: Freezing remaining freezable tasks ... (elapsed 0.300 seconds) done.
This can be fixed with:
echo i2c-ELAN0001:00 >/sys/bus/
After this, systemctl suspend works again.
After the next reboot, this situation repeats again.
(Offtopic: As concerns the touchpad on this new Lenovo laptop, it never worked after Ubuntu installation -- with the default kernel or this one, no matter which one.)
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-
ProcVersionSign
Uname: Linux 5.6.0-1021-oem x86_64
ApportVersion: 2.20.11-0ubuntu27.9
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: ubuntu:GNOME
Date: Sat Oct 17 17:53:01 2020
InstallationDate: Installed on 2020-08-03 (74 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
XDG_RUNTIME_
LANG=ru_RU.UTF-8
SHELL=/bin/bash
SourcePackage: linux-oem-5.6
UpgradeStatus: No upgrade log present (probably fresh install)
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #8 |
In Linux Kernel Bug Tracker #207759, dirkneukirchen (dirkneukirchen-linux-kernel-bugs) wrote : | #9 |
2 users of Manjaro reported the same errors on their Lenovo Ideapad 5
manjaro forum report: https:/
Also strange that its using elants_i2c instead of elan_i2c (or generic ones)
but seems similar to https:/
Maybe its hardware design issue ?
I have no idea why "i8042.dumbkbd=1" would help - are these touchpad / elan "touchscreens" connected to I2C and PS2 and SMBus ?
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #10 |
I fixed it temporarily by changing elants_i2c from "built in" to "module". It works flawlessly now.
I would not expect a hardware issue. It looks more like the module beeing started too early. The whole I2C is dead, when running elants_i2c as a module.
In Linux Kernel Bug Tracker #207759, dirkneukirchen (dirkneukirchen-linux-kernel-bugs) wrote : | #11 |
So effectively you blacklist the module because
"The whole I2C is dead, when running elants_i2c as a module."
reads for me like elants_i2c no longer manages the touchpad.
What driver or connection is that input using now? / What dmesg looks when it finds the touchpad ?
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #12 |
Created attachment 289469
dmesg / kernel log
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #13 |
I fetched a kernel from kernel.org (5.6.14 and 5.7.0-rc7).
make menuconfig
Device Drivers -> Input device support -> Touchscreens -> Elan eKTH I2C touchscreen -->> set to m
rebuild kernel and install...
The driver is no longer loaded as built in, but as a module. This leads to a delay of ca. 3-4s. Somehow this seems to help.
The Touchpad/screen is connected via i2c1.
dl3it@IdeaPad:~$ dmesg | grep ELAN
[ 1.583560] i2c_hid i2c-ELAN0001:00: supply vdd not found, using dummy regulator
[ 1.583575] i2c_hid i2c-ELAN0001:00: supply vddl not found, using dummy regulator
[ 1.646025] input: ELAN0001:00 04F3:3140 Mouse as /devices/
[ 1.646257] input: ELAN0001:00 04F3:3140 Touchpad as /devices/
[ 1.646347] hid-generic 0018:04F3:
[ 4.456207] input: ELAN0001:00 04F3:3140 Mouse as /devices/
[ 4.456459] input: ELAN0001:00 04F3:3140 Touchpad as /devices/
[ 4.456574] hid-multitouch 0018:04F3:
dl3it@IdeaPad:~$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ELAN0001:00 04F3:3140 Mouse id=11 [slave pointer (2)]
⎜ ↳ ELAN0001:00 04F3:3140 Touchpad id=12 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ Integrated Camera: Integrated C id=9 [slave keyboard (3)]
↳ Ideapad extra buttons id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
libinput:
Device: ELAN0001:00 04F3:3140 Mouse
Kernel: /dev/input/event5
Group: 8
Seat: seat0, default
Capabilities: pointer
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: disabled
Nat.scrolling: disabled
Middle emulation: n/a
Calibration: n/a
Scroll methods: *button
Click methods: none
Disable-w-typing: n/a
Accel profiles: flat *adaptive
Rotation: n/a
Device: ELAN0001:00 04F3:3140 Touchpad
Kernel: /dev/input/event6
Group: 8
Seat: seat0, default
Size: 100x66mm
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...
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #14 |
Created attachment 289471
Xorg.0.log
In Linux Kernel Bug Tracker #207759, dirkneukirchen (dirkneukirchen-linux-kernel-bugs) wrote : | #15 |
In your working log the Touchpad is now using
i2c_hid instead of elants_i2c
So compiling a new kernel only changed hardware probing order
a simple blacklisting of elants_i2c
works according to a user on computerbase.de forum that experienced the same issue on his Ideapad 5
In Linux Kernel Bug Tracker #207759, dirkneukirchen (dirkneukirchen-linux-kernel-bugs) wrote : | #16 |
thank you for proving logs to help pinpoint the issue
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #17 |
Could you provide some more details on the blacklisting please ? I tried this first, but it didn't work. That's why I recompiled the kernel.
Btw, the elants_i2c module is still loaded automatically...
In Linux Kernel Bug Tracker #207759, niklagaming (niklagaming-linux-kernel-bugs) wrote : | #18 |
I blacklisted the elants_i2c modul with
echo "blacklist elants_i2c" | sudo tee /etc/modprobe.
This solved the problem for me.
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #19 |
blacklisting does not work for me with ubuntu kernel and fix built in elants_i2c. I switched back to "my" kernel...
In Linux Kernel Bug Tracker #207759, brunolucas (brunolucas-linux-kernel-bugs) wrote : | #20 |
I have a new laptop, Lenovo IdeaPad 5 with AMD Ryzen and I have the same problem. I've installed Ubuntu 20.04, with the 5.4 kernel or even the latest 5.7 kernel the trackpad does not work.
I've tried to the solution to blacklist the elants_i2c module, but it did not work for me.
In Linux Kernel Bug Tracker #207759, brunolucas (brunolucas-linux-kernel-bugs) wrote : | #21 |
Just tried to build kernel 5.7, as per comment #5, and it works also for me.
In Linux Kernel Bug Tracker #207759, glogow (glogow-linux-kernel-bugs) wrote : | #22 |
Thanks for all the info. I saw these error messages and assumed some larger problem. And didn't register the messages were created by the touchpad actually, since this is the touchscreen driver.
And since I managed to brick my HW, I had other things to do (https:/
Instead of a kernel rebuild, you can simply unbind the device for the built-in module. Just add some startup script doing:
modprobe i2c_hid
echo "i2c-ELAN0001:00" > /sys/bus/
echo "i2c-ELAN0001:00" > /sys/bus/
Now I'm wondering, what people with a notebook with an Elan touchscreen would do...
The elants_i2c wrongly claims the device. Either a driver bug or a wrong ACPI DSTD, which in the end the elants_i2c must work around :-(
And I already had decompiled the ACPI DSTD to have a look...
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #23 |
cool... Works great :-))
Thanks for this...
In Linux Kernel Bug Tracker #207759, glogow (glogow-linux-kernel-bugs) wrote : | #24 |
Just an addition: I added this to my /etc/rc.local, but it doesn't work more times then it does.
Currently I'm using this little script, which did work the last few boots:
echo "i2c-ELAN0001:00" > /sys/bus/
sleep 1.5
echo "i2c-ELAN0001:00" > /sys/bus/
Anything less then 1.5s didn't work most times. And I'm on Ubuntu 20.04 / kernel 5.4 FWIW. Also tested the 5.6 and 5.7 Ubuntu mainline builds, which had the same problem.
In Linux Kernel Bug Tracker #207759, dl3it (dl3it-linux-kernel-bugs) wrote : | #25 |
I created
/etc/systemd/
[Unit]
Description=Move touchscreen to correct driver
[Service]
ExecStart=
Type=oneshot
RemainAfterExit=yes
[Install]
WantedBy=
Add this to systemd environment.
It calls /etc/tsmove once at startup.
/etc/tsmove
#!/bin/bash
modprobe i2c_hid
echo "i2c-ELAN0001:00" > /sys/bus/
echo "i2c-ELAN0001:00" > /sys/bus/
Works for me perfectly; no issues on Ubuntu 20.04 and kernel 5.4.0-33.
In Linux Kernel Bug Tracker #207759, guiman2006 (guiman2006-linux-kernel-bugs) wrote : | #26 |
As expected, modifying the kernel per Comment #5 solved the touchpad issue as well (don't have touchscreen on my model).
In Linux Kernel Bug Tracker #207759, bezirg (bezirg-linux-kernel-bugs) wrote : | #27 |
I can confirm that this script did the trick on a running system:
```
#!/bin/bash
modprobe i2c_hid
echo "i2c-ELAN0001:00" > /sys/bus/
echo "i2c-ELAN0001:00" > /sys/bus/
```
What is positive is that:
1) this script fixes the `systemctl suspend`. Without this fix applied the system refused to suspend (go to sleep) with a dmesg:
```
[ 588.472945] PM: dpm_run_callback(): acpi_subsys_
[ 588.472948] PM: Device i2c-ELAN0001:00 failed to suspend: error -16
[ 588.527849] PM: Some devices failed to suspend, or early wake event detected
```
2) I have the touchscreen model of this laptop and i can confirm that the touchscreen continues to operate fine next to the working touchpad, after the script is run.
In Linux Kernel Bug Tracker #207759, jesuismartinjeremy (jesuismartinjeremy-linux-kernel-bugs) wrote : | #28 |
Doesn't seem to work for me. Issue is earlier.
I try to point at xinput and result is following :
Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech Pebble Mouse id=14 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ Integrated Camera: Integrated C id=9 [slave keyboard (3)]
↳ Ideapad extra buttons id=10 [slave keyboard (3)]
↳ Intel HID events id=11 [slave keyboard (3)]
↳ Intel HID 5 button array id=12 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
I've no Elan touchpad listed in.
My laptop is Lenonvo Ideapad 14IIL05.
Have a try to kernel update. But doensn't work much better.
Any help to fix my trackpad issue is welcome
In Linux Kernel Bug Tracker #207759, glogow (glogow-linux-kernel-bugs) wrote : | #29 |
(In reply to Osmo from comment #20)
> Doesn't seem to work for me. Issue is earlier.
...
> I've no Elan touchpad listed in.
> My laptop is Lenonvo Ideapad 14IIL05.
As far as I have read various Ideapad 14/15 related threads, the AMD (like my 15ARE05) and Intel (like your 14IIL05) have different touchpads.
My decoded DSDT contains two "ELAN" ids: ELAN901C and a ELAN0001. I didn't test, if adding that ELAN901C id to the elan_i2c driver would result in some "better" supported device, then the generic i2c_hid driver, as I don't see any missing functionality. And the i2c_hid claims the "ELAN0001" device, if the elants_i2c is build as a module. AFAIK it's common to share a common DSDT for a series of devices, and the correct parts are just activated by some smaller config ACPI data, or the like.
There is clearly something missing, because this driver rebinding is even needed in 5.7, as the elan touchscreen driver still claims the device, even if it doesn't have a touchscreen. Eventually, even the DSDT is buggy in some way, but then the driver still needs to work around it.
My Xorg.log has some EE entries for invalid values reported by the elants_i2c driver, so it should be possible for the elants_i2c to "bail out" from claiming the device in the detection, based on these values, and the later hid_i2c driver would "just work" - my assumption.
(EE) event4 - Elan Touchscreen: kernel bug: device has min == max on ABS_X
(II) event4 - Elan Touchscreen: was rejected
(II) event4 - not using input device '/dev/input/
(EE) libinput: Elan Touchscreen: Failed to create a device for /dev/input/event4
(EE) PreInit returned 2 for "Elan Touchscreen"
In Linux Kernel Bug Tracker #207759, brady.110 (brady.110-linux-kernel-bugs) wrote : | #30 |
(In reply to Jan-Marek Glogowski from comment #14)
> Thanks for all the info. I saw these error messages and assumed some larger
> problem. And didn't register the messages were created by the touchpad
> actually, since this is the touchscreen driver.
>
> And since I managed to brick my HW, I had other things to do
> (https:/
> Flex-Notebooks/
> test this now.
>
> Instead of a kernel rebuild, you can simply unbind the device for the
> built-in module. Just add some startup script doing:
>
> modprobe i2c_hid
> echo "i2c-ELAN0001:00" > /sys/bus/
> echo "i2c-ELAN0001:00" > /sys/bus/
>
> Now I'm wondering, what people with a notebook with an Elan touchscreen
> would do...
>
> The elants_i2c wrongly claims the device. Either a driver bug or a wrong
> ACPI DSTD, which in the end the elants_i2c must work around :-(
>
> And I already had decompiled the ACPI DSTD to have a look...
Thank you! This script worked for me too. Ideapad 5 AMD Ryzen 7 4500u.
In Linux Kernel Bug Tracker #207759, brady.110 (brady.110-linux-kernel-bugs) wrote : | #31 |
(In reply to dl3it from comment #17)
> I created
>
> /etc/systemd/
>
>
> [Unit]
> Description=Move touchscreen to correct driver
>
> [Service]
> ExecStart=
> Type=oneshot
> RemainAfterExit=yes
>
> [Install]
> WantedBy=
>
>
> Add this to systemd environment.
> It calls /etc/tsmove once at startup.
>
> /etc/tsmove
>
>
> #!/bin/bash
> modprobe i2c_hid
> echo "i2c-ELAN0001:00" > /sys/bus/
> echo "i2c-ELAN0001:00" > /sys/bus/
>
>
> Works for me perfectly; no issues on Ubuntu 20.04 and kernel 5.4.0-33.
I couldn't seem to get this to work.
I used this https:/
Followed all steps and rebooted. Touchpad works now :)
Kernel 5.7.5-050705-
In Linux Kernel Bug Tracker #207759, rl (rl-linux-kernel-bugs) wrote : | #32 |
(In reply to Jan-Marek Glogowski from comment #21)
> (In reply to Osmo from comment #20)
> > Doesn't seem to work for me. Issue is earlier.
> ...
> > I've no Elan touchpad listed in.
> > My laptop is Lenonvo Ideapad 14IIL05.
>
> As far as I have read various Ideapad 14/15 related threads, the AMD (like
> my 15ARE05) and Intel (like your 14IIL05) have different touchpads.
>
> My decoded DSDT contains two "ELAN" ids: ELAN901C and a ELAN0001. I didn't
> test, if adding that ELAN901C id to the elan_i2c driver would result in some
> "better" supported device, then the generic i2c_hid driver, as I don't see
> any missing functionality. And the i2c_hid claims the "ELAN0001" device, if
> the elants_i2c is build as a module. AFAIK it's common to share a common
> DSDT for a series of devices, and the correct parts are just activated by
> some smaller config ACPI data, or the like.
>
> There is clearly something missing, because this driver rebinding is even
> needed in 5.7, as the elan touchscreen driver still claims the device, even
> if it doesn't have a touchscreen. Eventually, even the DSDT is buggy in some
> way, but then the driver still needs to work around it.
>
> My Xorg.log has some EE entries for invalid values reported by the
> elants_i2c driver, so it should be possible for the elants_i2c to "bail out"
> from claiming the device in the detection, based on these values, and the
> later hid_i2c driver would "just work" - my assumption.
>
> (EE) event4 - Elan Touchscreen: kernel bug: device has min == max on ABS_X
> (II) event4 - Elan Touchscreen: was rejected
> (II) event4 - not using input device '/dev/input/
> (EE) libinput: Elan Touchscreen: Failed to create a device for
> /dev/input/event4
> (EE) PreInit returned 2 for "Elan Touchscreen"
I am also using a 14IIL05 and can confirm that there is no ELAN id shown in the output of xinput, but a MSFT0001:00 04F3:3140 Mouse and MSFT0001:00 04F3:3140 Touchpad. When using Fedora 32 with 5.7.16-200 the Touchpad is working as expected, but the Touchscreen is not working at all (no hardware defect as it works with Windows). I tried the hid-rmi patch for the kernel module as mentioned in comment #41 from https:/
xinput test shows output for the TouchPad, but nothing for the TouchScreen although it seems recognized as a mouse.
Output from Xorg.0.log shows:
MSFT0001:00 04F3:3140 Mouse: is tagged by udev as: Mouse Pointingstick
Output from lspci:
00:1f.4 SMBus: Intel Corporation Ice Lake-LP SMBus Controller (rev 30)
Subsystem: Lenovo Device 3813
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
Output from dmesg:
[ 1.397059] i2c_hid i2c-MSFT0001:00: supply vdd not found, using dummy regulator
[ 1.397076] i2c_hid i2c-MSFT0001:00: supply vddl not found, using dummy regulator
[ 1.419419] input: MSFT0001:00 04F3:3140 Mouse as /devices/
[ 1.419549] input: MSFT0001:00 04F3:3140 Touchpad as /devices/
In Linux Kernel Bug Tracker #207759, mcadoo.chen (mcadoo.chen-linux-kernel-bugs) wrote : | #33 |
Hi, I have Legion 15ARH05 with the same Touchpad 04F3:3140. Touchpad is not working either. I am curious why ideapad 15 has the same Touchpad ID and someone could solve the issue by blacklist elan-i2c but Legion 15ARH05 cannot, especially I didn't complied elan-i2c or elants-i2c. Legion 15ARH05 doesn't have touchscreen.
dmesg | grep -i 04f3
[ 2.095379] input: MSFT0001:00 04F3:3140 Mouse as /devices/
[ 2.095450] input: MSFT0001:00 04F3:3140 Touchpad as /devices/
[ 2.095506] hid-generic 0018:04F3:
[ 2.589937] input: MSFT0001:00 04F3:3140 Mouse as /devices/
[ 2.590052] input: MSFT0001:00 04F3:3140 Touchpad as /devices/
[ 2.590112] hid-multitouch 0018:04F3:
In Linux Kernel Bug Tracker #207759, lyntier (lyntier-linux-kernel-bugs) wrote : | #34 |
Ideapad Flex 5
14IIL05
i5, 256GB drive, 8GB RAM
Touchpad works out of the box, Touch*screen* does not.
$ xinput
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ MSFT0001:00 04F3:4140 Mouse id=11 [slave pointer (2)]
⎜ ↳ MSFT0001:00 04F3:4140 Touchpad id=12 [slave pointer (2)]
Shows up twice in xinput; I assume once as touchpad, once as touchscreen, but identified as mouse. Scripts above don't change anything unfortunately, although touchpad keeps working. Haven't tried compiling yet; wasn't sure how to and I doubt it'd help if the driver-changing scripts don't.
In Linux Kernel Bug Tracker #207759, donat.us (donat.us-linux-kernel-bugs) wrote : | #35 |
I have the same issue as lyntier.
xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ USB Keyboard Mouse id=14 [slave pointer (2)]
⎜ ↳ MSFT0001:00 06CB:CE2D Mouse id=16 [slave pointer (2)]
⎜ ↳ MSFT0001:00 06CB:CE2D Touchpad id=17 [slave pointer (2)]
I tried adopting the script as following:
#!/bin/bash
modprobe i2c_hid
echo "i2c-MSFT0001:00" > /sys/bus/
echo "i2c-MSFT0001:00" > /sys/bus/
but the service was not able to run due to the script failing:
systemctl status touchscreen.service
● touchscreen.service - Move touchscreen to correct driver
Loaded: loaded (/etc/systemd/
Active: failed (Result: exit-code) since Sun 2020-10-04 19:56:51 CEST; 16min ago
Process: 792 ExecStart=
Main PID: 792 (code=exited, status=1/FAILURE)
Oct 04 19:56:51 donat-flex-5 systemd[1]: Starting Move touchscreen to correct driver...
Oct 04 19:56:51 donat-flex-5 tsmove[792]: /etc/tsmove: line 3: echo: write error: No such device
Oct 04 19:56:51 donat-flex-5 tsmove[792]: /etc/tsmove: line 4: echo: write error: No such device
Oct 04 19:56:51 donat-flex-5 systemd[1]: touchscreen.
Oct 04 19:56:51 donat-flex-5 systemd[1]: touchscreen.
Oct 04 19:56:51 donat-flex-5 systemd[1]: Failed to start Move touchscreen to correct driver.
but dmesg shows that the device is already using i2c_hid:
dmesg | grep MSFT
[ 0.639245] i2c_hid i2c-MSFT0001:00: i2c-MSFT0001:00 supply vdd not found, using dummy regulator
[ 0.639261] i2c_hid i2c-MSFT0001:00: i2c-MSFT0001:00 supply vddl not found, using dummy regulator
[ 0.688182] input: MSFT0001:00 06CB:CE2D Mouse as /devices/
[ 0.688257] input: MSFT0001:00 06CB:CE2D Touchpad as /devices/
[ 0.688310] hid-generic 0018:06CB:
[ 3.164826] input: MSFT0001:00 06CB:CE2D Mouse as /devices/
[ 3.167199] input: MSFT0001:00 06CB:CE2D Touchpad as /devices/
[ 3.168205] hid-multitouch 0018:06CB:
Could anybody please help me? I've installed Linux for the first time and just got this notebook.
In Linux Kernel Bug Tracker #207759, glogow (glogow-linux-kernel-bugs) wrote : | #36 |
To all the Intel *IIL05 users: please open a new bug report and handle the problems with that touchpad / touchscreen in there. It's different HW and needs completely different fixes.
Maybe the reporter can update the title of the bug report?
----
The whole bug was originally about the *touchpad* on the AMD version of the Lenovo Ideapad 5 15 AKA *ARE05, where the *touchscreen* elants_i2c driver wrongly claims the *touchpad* device.
For the AMD version AKA *ARE05 we have a working workaround in comment 17, that fixes:
1. the touchpad
2. suspend to RAM (comment 19)
The device eventually uses a different touchscreen driver, which was never affected (see comment 19 again).
The bug: the elants_i2c driver finds the device by the ACPI id ELAN0001. It then probes the device, to detect if it's actually working. It even fails in there, but instead of giving up on it, it offers a driver interface to flash the "broken" firmware to some working state, and keeps trying to decode messages. Flashing would obviously also fail in this case, as the device is no touchscreen, but a touchpad. So the driver still claims the device and get's really "confused" by all the unknown i2c HID touchpad messages.
Maybe the elants_i2c can detect the HID state of the device and then give up?
In Linux Kernel Bug Tracker #207759, rl (rl-linux-kernel-bugs) wrote : | #37 |
(In reply to Jan-Marek Glogowski from comment #28)
> To all the Intel *IIL05 users: please open a new bug report and handle the
> problems with that touchpad / touchscreen in there. It's different HW and
> needs completely different fixes.
>
> Maybe the reporter can update the title of the bug report?
>
> ----
>
> The whole bug was originally about the *touchpad* on the AMD version of the
> Lenovo Ideapad 5 15 AKA *ARE05, where the *touchscreen* elants_i2c driver
> wrongly claims the *touchpad* device.
>
> For the AMD version AKA *ARE05 we have a working workaround in comment 17,
> that fixes:
> 1. the touchpad
> 2. suspend to RAM (comment 19)
>
> The device eventually uses a different touchscreen driver, which was never
> affected (see comment 19 again).
>
> The bug: the elants_i2c driver finds the device by the ACPI id ELAN0001. It
> then probes the device, to detect if it's actually working. It even fails in
> there, but instead of giving up on it, it offers a driver interface to flash
> the "broken" firmware to some working state, and keeps trying to decode
> messages. Flashing would obviously also fail in this case, as the device is
> no touchscreen, but a touchpad. So the driver still claims the device and
> get's really "confused" by all the unknown i2c HID touchpad messages.
>
> Maybe the elants_i2c can detect the HID state of the device and then give up?
New bug report opened: https:/
In Linux Kernel Bug Tracker #207759, mcadoo.chen (mcadoo.chen-linux-kernel-bugs) wrote : | #38 |
Here there is walkaround for AMD Laptop
https:/
Ivan Zakharyaschev (imz) wrote : | #1 |
- Dependencies.txt Edit (2.5 KiB, text/plain; charset="utf-8")
- ProcCpuinfoMinimal.txt Edit (1.5 KiB, text/plain; charset="utf-8")
Ivan Zakharyaschev (imz) wrote : | #2 |
I found the "unbind" advice in https:/
Ivan Zakharyaschev (imz) wrote : | #3 |
I've just found out that if I do (as per https:/
echo i2c-ELAN0001:00 >/sys/bus/
after this, the touchpad starts working! For the first time since I use Ubuntu on this computer.
Ivan Zakharyaschev (imz) wrote : | #4 |
The situation is the same with linux-image-
Ivan Zakharyaschev (imz) wrote : | #5 |
They also mentioned the suspend problem at https:/
Ivan Zakharyaschev (imz) wrote : | #6 |
As a solution (until the binding of this device is fixed in the linux kernel), I blacklisted this driver in the kernel command line, as described in https:/
First, find function names which look like initialization functions of this module:
# fgrep elants /boot/System.
ffffffff818f3430 t elants_
ffffffff818f40bf t elants_
ffffffff829253f5 t elants_
ffffffff82af7a30 t __initcall_
#
The last one (__initcall*) doesn't look like the one we are looking for.
Then add them to the kernel parameters in /etc/default/grub (on Ubuntu)
GRUB_CMDLINE_
and run update-grub.
In Linux Kernel Bug Tracker #207759, imz (imz-linux-kernel-bugs) wrote : | #39 |
I also experience the problem with the wrong binding of the "ELAN" touchpad device to the compiled-in driver elants_i2c -- https:/
(In reply to Jan-Marek Glogowski from comment #16)
> Currently I'm using this little script, which did work the last few boots:
>
> echo "i2c-ELAN0001:00" > /sys/bus/
> sleep 1.5
> echo "i2c-ELAN0001:00" > /sys/bus/
As a solution (until the binding of this device is fixed in the linux kernel), I blacklisted this compiled-in driver in the kernel command line, as described in https:/
First, find function names which look like initialization functions of this module:
# fgrep elants /boot/System.
ffffffff818f3430 t elants_
ffffffff818f40bf t elants_
ffffffff829253f5 t elants_
ffffffff82af7a30 t __initcall_
#
The last one (__initcall*) doesn't look like the one we are looking for.
Then add them to the kernel parameters in /etc/default/grub (on Ubuntu)
GRUB_CMDLINE_
and run update-grub.
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #40 |
Hi All,
Thank you for figuring out that the issue is the elants_i2c driver binding to the touchscreen while it should be handled by the i2c-hid driver, that helps a lot.
I've written a small patch for the elants_i2c driver to stop it from binding to i2c-hid compatible touchscreens, which should fix this. I'll attach the patch here.
I would appreciate it if one of you can build a kernel with this patch (see your distro's docs), remove your workaround and then let me know if this fixes things.
If any of you are running Fedora, let me know, then I can provide a pre-built kernel with the patch added.
Regards,
Hans
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #41 |
Created attachment 295439
[PATCH] Input: elants_i2c - Do not bind to i2c-hid compatible ACPI instantiated devices
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #42 |
I would also appreciate it if some of you can run:
sudo apcidump -o acpidump.
And then attach the generated acpidump.
For example run:
sudo apcidump -o acpidump.
And then attach the acpidump.
The reason I'm asking for this is because the fix which I wrote is somewhat simple. It should work, but there might be older touchscreens which actually need to use the Elan specific protocol implemented by elants_i2c.ko; while the ACPI-fwnode describing the touchscreen falsely contains one of the i2c-hid ACPI compatiblity-id strings. This would of course be a bug in the ACPI tables, but I have seen this before.
If it turns out this is indeed the case then some more elaborate fix may be necessary and the acpidump(s) may help with figuring that out.
In Linux Kernel Bug Tracker #207759, cliffburton11 (cliffburton11-linux-kernel-bugs) wrote : | #43 |
Since 5.12rc1 the touchpad isn't working on my ideapad 5 and I have elants_i2c blacklisted. touchpad is working fine on 5.11
In Linux Kernel Bug Tracker #207759, lukasbecker2 (lukasbecker2-linux-kernel-bugs) wrote : | #44 |
Created attachment 295575
output of sudo apcidump -o acpidump.
Output of the requested command on my ideapad, with the command:
sudo apcidump -o acpidump.
In Linux Kernel Bug Tracker #207759, benjamin.tissoires (benjamin.tissoires-linux-kernel-bugs) wrote : | #45 |
@Fibonacci: in 5.12-rc1 there was a big refactoring of i2c-hid. Do you have `CONFIG_
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #46 |
Thank you for the acpidump.
I'm still waiting on feedback on the patch which I attached here. It would be great if someone can test this and confirm that it fixes things, so that I can submit the fix upstream and we can get this fixed in the mainline kernel.
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #47 |
So the acpidump made me realize that there is an extra check which we can do inside the elants_i2c driver's probe function. We can check for the I2C-HID spec's DSM (device-
I'll attach an updated patch here, please give this new version a try.
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #48 |
Created attachment 295577
[PATCH] Input: elants_i2c - Do not bind to i2c-hid compatible ACPI instantiated devices
In Linux Kernel Bug Tracker #207759, lukasbecker2 (lukasbecker2-linux-kernel-bugs) wrote : | #49 |
Thank you, is it enough if I apply this patch to my distro kernel ? (arch linux, linux 5.11.2)
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #50 |
(In reply to lukasbecker2 from comment #41)
> Thank you, is it enough if I apply this patch to my distro kernel ? (arch
> linux, linux 5.11.2)
Yes, if you can test your distro's 5.11.2 kernel with the patch added on top, that would be great, thank you.
p.s. Don't forget to disable any workarounds which you may have put in place when testing the patched kernel.
In Linux Kernel Bug Tracker #207759, lukasbecker2 (lukasbecker2-linux-kernel-bugs) wrote : | #51 |
The touchpad works now as expected with the patch (attatchment 295577),
kernel 5.11.2 arch linux (I disabled the privious workaround, kernel param initcall_
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #52 |
(In reply to lukasbecker2 from comment #43)
> The touchpad works now as expected with the patch (attatchment 295577),
> kernel 5.11.2 arch linux (I disabled the privious workaround, kernel param
> initcall_
Great, thank you for testing. I've submitted the patch for this upstream, hopefully it will be merged into 5.12 sometime this cycle and then added to the stable kernel releases after that.
In Linux Kernel Bug Tracker #207759, lukasbecker2 (lukasbecker2-linux-kernel-bugs) wrote : | #53 |
(In reply to Hans de Goede from comment #44)
> (In reply to lukasbecker2 from comment #43)
> > The touchpad works now as expected with the patch (attatchment 295577),
> > kernel 5.11.2 arch linux (I disabled the privious workaround, kernel param
> > initcall_
>
> Great, thank you for testing. I've submitted the patch for this upstream,
> hopefully it will be merged into 5.12 sometime this cycle and then added to
> the stable kernel releases after that.
Thank you for the patch, can you provide a link to the submitted patch so I can check the status form time to time ?
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #54 |
https://<email address hidden>/T/#t
In Linux Kernel Bug Tracker #207759, lukasbecker2 (lukasbecker2-linux-kernel-bugs) wrote : | #55 |
(In reply to Hans de Goede from comment #46)
> https://<email address hidden>/T/#t
Thank you, :)
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #56 |
(In reply to Hans de Goede from comment #46)
> https://<email address hidden>/T/#t
This patch has been merged into 5.13-rc1, so this bug can be closed now.
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #57 |
The patch for this is now also available in the 5.12.6 and 5.10.39 stable kernel releases.
In Linux Kernel Bug Tracker #207759, lukasbecker2 (lukasbecker2-linux-kernel-bugs) wrote : | #58 |
Thank you :)
Launchpad Janitor (janitor) wrote : | #7 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in linux-oem-5.6 (Ubuntu): | |
status: | New → Confirmed |
In Linux Kernel Bug Tracker #207759, lovesh.bond (lovesh.bond-linux-kernel-bugs) wrote : | #59 |
(In reply to Jan-Marek Glogowski from comment #14)
> Thanks for all the info. I saw these error messages and assumed some larger
> problem. And didn't register the messages were created by the touchpad
> actually, since this is the touchscreen driver.
>
> And since I managed to brick my HW, I had other things to do
> (https:/
> Flex-Notebooks/
> test this now.
>
> Instead of a kernel rebuild, you can simply unbind the device for the
> built-in module. Just add some startup script doing:
>
> modprobe i2c_hid
> echo "i2c-ELAN0001:00" > /sys/bus/
> echo "i2c-ELAN0001:00" > /sys/bus/
>
> Now I'm wondering, what people with a notebook with an Elan touchscreen
> would do...
>
> The elants_i2c wrongly claims the device. Either a driver bug or a wrong
> ACPI DSTD, which in the end the elants_i2c must work around :-(
>
> And I already had decompiled the ACPI DSTD to have a look...
I am on Kubuntu 21.04 and I think my touchpad is ELAN1203 (based on dmesg outputs) and I have the same issue, reported issue here https:/
I tried to unbind with (using root)
echo "i2c-ELAN0001:00" > /sys/bus/
But i get the error
-bash: echo: write error: No such device
Also, I see 2 i2c_hid like modules in lsmod
$ lsmod | grep i2c_hid
i2c_hid_acpi 16384 0
i2c_hid 28672 1 i2c_hid_acpi
hid 135168 3 i2c_hid,
In Linux Kernel Bug Tracker #207759, jwrdegoede (jwrdegoede-linux-kernel-bugs) wrote : | #60 |
(In reply to Lovesh from comment #51)
> I am on Kubuntu 21.04 and I think my touchpad is ELAN1203 (based on dmesg
> outputs) and I have the same issue, reported issue here
> https:/
Looking at bug 213857 you are having an issue with the kernel not being able to configure the GPIO pin which is used for the touchpad, which is an entirely different issue.
Lets continue discussing this in bug 213857.
In Linux Kernel Bug Tracker #207759, lovesh.bond (lovesh.bond-linux-kernel-bugs) wrote : | #61 |
(In reply to Hans de Goede from comment #52)
> (In reply to Lovesh from comment #51)
> > I am on Kubuntu 21.04 and I think my touchpad is ELAN1203 (based on dmesg
> > outputs) and I have the same issue, reported issue here
> > https:/
>
> Looking at bug 213857 you are having an issue with the kernel not being able
> to configure the GPIO pin which is used for the touchpad, which is an
> entirely different issue.
>
> Lets continue discussing this in bug 213857.
Sounds good. Thank you.
Changed in linux: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
The Elantech Touchscreen is not working in Lenovo Ideapad 5 15.
[ 0.550596] elants_i2c i2c-ELAN0001:00: i2c-ELAN0001:00 supply vcc33 not found, using dummy regulator
[ 0.551836] elants_i2c i2c-ELAN0001:00: i2c-ELAN0001:00 supply vccio not found, using dummy regulator
[ 0.560932] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (77 77 77 77): -121
[ 0.562427] elants_i2c i2c-ELAN0001:00: software reset failed: -121
[ 0.595925] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (77 77 77 77): -121
[ 0.597974] elants_i2c i2c-ELAN0001:00: software reset failed: -121
[ 0.621893] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (77 77 77 77): -121
[ 0.622504] elants_i2c i2c-ELAN0001:00: software reset failed: -121
[ 0.632650] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (4d 61 69 6e): -121
[ 0.634256] elants_i2c i2c-ELAN0001:00: boot failed: -121
[ 0.699212] elants_i2c i2c-ELAN0001:00: invalid 'hello' packet: 00 00 ff ff
[ 1.630506] elants_i2c i2c-ELAN0001:00: Failed to read fw id: -121
[ 1.645508] elants_i2c i2c-ELAN0001:00: unknown packet 00 00 ff ff
When booting a test Windows10 (sorry..), it works; so a HW fault can be excluded.
When using it, it produces errors:
[ 933.159820] elants_i2c i2c-ELAN0001:00: unknown packet 0e 00 04 03
[ 933.167034] elants_i2c i2c-ELAN0001:00: unknown packet 0e 00 04 03
[ 933.172617] elants_i2c i2c-ELAN0001:00: unknown packet 0e 00 04 13
[ 933.180073] elants_i2c i2c-ELAN0001:00: unknown packet 0e 00 04 03
[ 933.185652] elants_i2c i2c-ELAN0001:00: unknown packet 0e 00 04 13
[ 933.192860] elants_i2c i2c-ELAN0001:00: unknown packet 0e 00 04 03
[ 933.198440] elants_i2c i2c-ELAN0001:00: unknown packet 0e 00 04 13
and so on...
Same beheaviour for kernel 5.4.xx and 5.6.xx