Yes I first ran it as first and it was the same.
I made mistake, I fixed the command, please try again.
[ 2505.988266] audit: type=1100 audit(1602782636.706:119): pid=25881 uid=1000
auid=1000 ses=2 subj==unconfined msg='op=PAM:authentication grantors=pam_fai
llock,pam_permit,pam_faillock acct="kartik" exe="/usr/bin/sudo" hostname=? ad
dr=? terminal=/dev/pts/2 res=success'
[ 2505.990545] audit: type=1101 audit(1602782636.706:120): pid=25881 uid=1000
auid=1000 ses=2 subj==unconfined msg='op=PAM:accounting grantors=pam_permit,
pam_time acct="kartik" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pt
s/2 res=success'
[ 2505.991019] audit: type=1110 audit(1602782636.709:121): pid=25881 uid=0 au
id=1000 ses=2 subj==unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_
permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? termina
l=/dev/pts/2 res=success'
[ 2505.993651] audit: type=1105 audit(1602782636.709:122): pid=25881 uid=0 au
id=1000 ses=2 subj==unconfined msg='op=PAM:session_open grantors=pam_limits,p
am_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal
=/dev/pts/2 res=success'
[ 2505.996041] i2c_hid i2c-ELAN0718:00: supply vdd not found, using dummy reg
ulator
[ 2505.996066] i2c_hid i2c-ELAN0718:00: supply vddl not found, using dummy re
gulator
[ 2505.997062] audit: type=1106 audit(1602782636.712:123): pid=25881 uid=0 au
id=1000 ses=2 subj==unconfined msg='op=PAM:session_close grantors=pam_limits,
pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? termina
l=/dev/pts/2 res=success'
[ 2505.997147] audit: type=1104 audit(1602782636.712:124): pid=25881 uid=0 au
id=1000 ses=2 subj==unconfined msg='op=PAM:setcred grantors=pam_faillock,pam_
permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? termina
l=/dev/pts/2 res=success'
I’ll check it out tonight - I’m on my way and can’t be earlier
The best way to get all the information I need, is to install hw-probe, then start it and send me the link to the test result here.
pamac install hw-probe
sudo hw-probe --all --upload
This is always the best way, so that I can help as soon as possible
How can I attach links here?
Can you paste the results of cat /proc/bus/input/devices and ls -l /sys/kernel/debug/hid/* (the second command requires root permission) in live OS? And in the OS where your touchpad doesn’t work, paste the result of ls -l /sys/kernel/debug/hid/*.
Can you also upload the ACPI DSDT table somewhere and share the link with me? The ACPI DSDT can be dumped by running the following commands after installing acpica,
sudo acpidump > acpidata.out
acpixtract -sDSDT acpidata.out
iasl -d dsdt.dat
You’ll see a file dsdt.dsl which is what I need.
Here’s what I find about @EternalEntity’s laptop.
Somehow the I2C master device (HID: AMDI0010, managed by drivers/i2c/busses/i2c-designware-platdrv.c) couldn’t communicate with the touchpad which is an I2C client device. This I2C master device uses IRQ 6 but “cat /proc/interrupts” shows IRQ 6’s counter never increases.
I don’t understand why the touchpad work in live OS because I don’t know the difference between live OS and installed OS. Knowing what the difference is may provide a clue for debugging this touchpad.
Btw, there is a bug report Bug #1884981 “Lenovo IdeaPad Flex 5 Ryzen (14ARE05): Touchpad/tr...” : Bugs : Linux on AMDI0010. So maybe there’s something wrong with drivers/i2c/busses/i2c-designware-platdrv.c.
And another bug report on AMDI0010 What is i2c_designware and why does it ruin my touchpad? (Page 2) / Kernel & Hardware / Arch Linux Forums.
When a device driver probe fails, it should be logged in the kernel message buffer, but unfortunately I don’t see such messages anywhere.
This even indicates that the probe method is actually called.
I looked at your problem once.
The reason is that the touchpad is not recognized at all.
It could be, that it is deactivated on the hardware side.
Do you have a setting that could cause this to happen when using a normal mouse?
Yes, it has been called but without success. If you look at the code of drivers/hid/i2c/i2c-hid-core.c. i2c-hid won’t warn if it fails to read the HID Descriptor from the touchpad unless you set the module parameter debug=1. I’ve accessed @EternalEntity’s computer to debug this issue so I’m quite sure about what’s happening.
Even with debug=1, there are paths which cannot be distinguished. Anyways, has the reason for the failing probe been uncovered?
Actually I’ve inserted some pr_alert code into i2c-hid-core.c to find out which line of function call wasn’t unsuccessful. I‘ve also enable I2C tracing and turned on the dynamic debug feature of i2c-designware-platdrv.c to verify it.
Unfortunately I could only tell the I2C controller somehow fails to read HID Descriptor from the touchpad. As for the root cause, my best guess is due to a bug in the i2c-designware.