I compiled my own kernel based on 5.7.0-0.rc7.20200528gitb0c3ba31be3e.1.fc33 with fedpkg and incorporated the patch described in https://patchwork.kernel.org/patch/11259977/
This patch adds the id for my Elan touchpad: ELAN0634. This did not however make my touchpad function. Perhaps more changes are needed but I'm not knowledgeable enough about input drivers.

Just for info there is a BIOS update (DJCN17WW released 25 may 2020).

I installed BIOS update DJCN17WW. The touchpad remains nonfunctional.

The new kernel 5.7.10 includes the changes I manually made to elan-i2c-ids.h to add the ACPI ID of my touchpad. See kernel.org: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/input/elan-i2c-ids.h?h=v5.7.10

I will check if this kernel works for my system once Fedora released it, which will probably be soon.

This is a link with a fix for Ubuntu (Thinkpad 15-IIL, it have the same BIOS) https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861610/comments/66
I think it could work under Fedora with some changes to the procedure due to Grub2. Hopefully it will help you to resolve your issue.

Thanks Laurent. This fix is working for me. Instead of using the cpio archive I just pointed grub to the dsdt.aml using "acpi /dsdt.aml". Works great. Two finger scrolling is working too.

Ok, so it seems that this is an issue with the DSDT / with how Linux interprets the DSDT.

Can you please run:

sudo dnf install acpica-tools
sudo acpidump -o acpidump.lenovo-thinkbook14-iil

And attach the generated acpidump.lenovo-thinkbook14-iil file here? Then I can see if I can come up with a fix on the kernel side for this to work without needing a DSDT override.

Created attachment 1714167 [details]
The output of acpidump as requested by Hans de Goede

Ok, fixing the _STA issue seems not that hard.

With the current, non working kernel if you do:

cat /sys/bus/acpi/devices/ELAN0634:00/status

(without the DSDT override) you should get "0" as output.

I've started a kernel test-build with a patch which hopefully fixes this, this is currently building here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=51023530

Once it is done building (this takes a few hours) then please give this kernel a try, see:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
for generic instructions for installing a kernel directly from koji.

When you have booted into the new kernel, the output of:
cat /sys/bus/acpi/devices/ELAN0634:00/status

Should have changed to "15" and hopefully the touchpad will work now.

Please let me know if the test kernel fixes things, once I have positive testing feedback I will submit the patch for this upstream.

(In reply to Hans de Goede from comment #10)
> Ok, fixing the _STA issue seems not that hard.
> 
> With the current, non working kernel if you do:
> 
> cat /sys/bus/acpi/devices/ELAN0634:00/status
> 
> (without the DSDT override) you should get "0" as output.
> 
> I've started a kernel test-build with a patch which hopefully fixes this,
> this is currently building here:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=51023530
> 
> Once it is done building (this takes a few hours) then please give this
> kernel a try, see:
> https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
> for generic instructions for installing a kernel directly from koji.
> 
> When you have booted into the new kernel, the output of:
> cat /sys/bus/acpi/devices/ELAN0634:00/status
> 
> Should have changed to "15" and hopefully the touchpad will work now.
> 
> Please let me know if the test kernel fixes things, once I have positive
> testing feedback I will submit the patch for this upstream.

Hi Hans,

Your kernel works for me. Clean install of Fedora 32, installed the kernel, touchpad works.

$ cat /sys/bus/acpi/devices/ELAN0634:00/status
15

Thanks!

Kind regards,
Stephan

Thank you for testing. I've submitted the patch upstream.

Once it is accepted upstream I will probably add it as a downstream patch to Fedora's kernel. I'm a bit reluctant to add it to the upstream stable series, since although it shouldn't cause any issues I'm not 100% sure about that.

In the mean time you can keep using the kernel from my test-build.

Late to the party, but I can also confirm that this works (even two and three finger gestures). Thanks for looking into this!

I would just like to add here that I tested "[PATCH] i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()" on a custom 5.9.0-rc4 Kernel on Debian and it made the touchpad work for me. Thank you Hans de Goede!

The patch fixing this has been added to the upstream 5.8.13 kernel.

A Fedora kernel based on the 5.8.13 release is available in the regular Fedora-updates repository now, to upgrade run:

sudo dnf update 'kernel*'

After upgrading, please boot into the new kernel, test the touchpad and report here if it works or not.

I can confirm it works now on Fedora 33 with kernel 5.8.16-300.fc33.x86_64 on an Lenovo Thinkbook 15-ILL too.
Thanks for bringing this fix to upstream and Fedora!

I also finally got access to the machine in question, did a normal update of F32, which pulled in a new kernel, and after booting with that kernel the touchpad on my machine worked as well.

So what's the normal disposition that kernel people use for bugs that are fixed in the current release? "CLOSED CURRENTRELEASE"? Or something else?

If its fixed by an update we usually use ERRATA as resolution, let me close this bug that way right away :)

Hi,

I have Fedora 33 with kernel 5.9.16-200.fc33.x86_64 on Lenovo Thinkbook 14-ILL. I am facing the same issue with the touchpad, it doesn't function at all. Looking at the thread above I had hoped that the latest kernel would be the solution of this issue, but unfortunately that is not the case with me.

cat /sys/bus/acpi/devices/ELAN062F\:00/status gives '0' as the output.

Can you please help me with the issue or give me some directions as to what I can try? Let me know if you need any other information from my end.

Thanks a lot!

(In reply to Angira Rastogi from comment #19)
> Hi,
> 
> I have Fedora 33 with kernel 5.9.16-200.fc33.x86_64 on Lenovo Thinkbook
> 14-ILL. I am facing the same issue with the touchpad, it doesn't function at
> all. Looking at the thread above I had hoped that the latest kernel would be
> the solution of this issue, but unfortunately that is not the case with me.
> 
> cat /sys/bus/acpi/devices/ELAN062F\:00/status gives '0' as the output.
> 
> Can you please help me with the issue or give me some directions as to what
> I can try? Let me know if you need any other information from my end.
> 
> Thanks a lot!

Ok, so I guess that there is a different issue with the DSDT on your model / with how Linux interprets the DSDT on your model.

Can you please run:

sudo dnf install acpica-tools
sudo acpidump -o acpidump.lenovo-thinkbook14-ill

And attach the generated acpidump.lenovo-thinkbook14-ill file here? Then I can see if I can come up with a fix for this.

Created attachment 1744585 [details]
Output of acpidump as requested by Hans De Goede

Thank you so much for your prompt response! Attaching the output of the acpidump command.

(In reply to Angira Rastogi from comment #21)
> Thank you so much for your prompt response! Attaching the output of the
> acpidump command.

Ok, so on this model the ACPI code is running some i2c based auto-detection from within the _REG handler for the I2C opregion for the I2C controller to which the touchscreen is connected. This is, erm, very creative use of the _REG handler. Fixing this might be interesting.

OTOH it might be that things already work and that the "cat /sys/bus/acpi/devices/ELAN062F\:00/status" output is not a problem. The DSDT actually registers 3 touchpad devices. So the status is expected to be 0 on 2 of them. Can you run the following commands and copy and paste the output here please:

cat /sys/bus/acpi/devices/SYNA2B60\:00/status
cat /sys/bus/acpi/devices/CRQ0340\:00/status
cat /sys/bus/acpi/devices/ELAN062F\:00/status
cat /sys/bus/acpi/devices/XXXX0000\:00/status

Please keep the output of each command and the command grouped together in your reply.

Can you also provide the output of: "ls -l /sys/bus/i2c/devices" please ?

Here are the outputs that you requested for :

cat /sys/bus/acpi/devices/SYNA2B60\:00/status >> Output : 0
cat /sys/bus/acpi/devices/CRQ0340\:00/status >> Output : 0
cat /sys/bus/acpi/devices/ELAN062F\:00/status >> Output : 0
cat /sys/bus/acpi/devices/XXXX0000\:00/status >> Output : 15

ls -l /sys/bus/i2c/devices
total 0
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-0 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-1 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-1
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-2 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-2
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-3 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-3
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-4 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-4
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-5 -> ../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/i2c-5
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-6 -> ../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/i2c-6
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-7 -> ../../../devices/pci0000:00/0000:00:1f.4/i2c-7
lrwxrwxrwx. 1 root root 0 Jan  5 17:24 i2c-XXXX0000:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-XXXX0000:00

Thanks!

Ok, that is a bit weird, unless I'm misreading the DSDT the XXXX0000 device having a non 0 status only happens when OSYS != 0x07DF, which in turn only happens if this check fails:

                If (_OSI ("Windows 2015"))
                {
                    OSYS = 0x07DF
                }

I guess that you are passing some special kernel commandline parameters to limit the OSYS version used by the ACPI tables? What is the output of:

cat /proc/cmdline

?

Hi,

I am not sure if I am doing anything special with the kernel.. I have two kernels installed on my machine : 
kernel-5.8.15-301.fc33.x86_64
kernel-5.9.16-200.fc33.x86_64

I booted from the higher version but the touchpad is not working on either of them. Here is the output that you asked for -

cat /proc/cmdline 
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.9.16-200.fc33.x86_64 root=UUID=0e8c22ec-0fdf-46a2-88b8-a16e1209910f ro rootflags=subvol=root rhgb quiet

Thanks!

Ok, this is weird.

Can you try adding: 'acpi_osi="Windows 2015"' to your kernel-commandline ?

Do this run the following command:

sudo grubby --update-kernel=ALL --args='acpi_osi="Windows 2015"'

And then reboot and then after rebooting please do:

dmesg > dmesg.txt

And then attach dmesg.txt here.

Also retry your touchpad (note I don't expect anything to change here really).

Created attachment 1744866 [details]
Output of dmesg as requested by Hans De Goede

I ran the suggested command and rebooted. Like you expected, the touchpad is still not working. Attaching the requested output.

Thanks.

Thank you for the dmesg. I need to think a bit about to see if I can figure out with what is going on here, so it might take a while before I get back to you.

No problem! Thank you so much for all your help.. Looking forward to hear back from you.

(In reply to Angira Rastogi from comment #30)
> No problem! Thank you so much for all your help.. Looking forward to hear
> back from you.

I wanted to let you know that this is still on my radar, but I've been swamped with other stuff. Hopefully I will get around to this next week.

Thank you so much! Indeed I am still stuck with the issue and in desperate need of a solution :D 
I appreciate all your help in this matter..

First of all once more my apologies for taking so long to get back to you on this.

I still don't fully understand why you are getting a broken XXXX0000 device instead of a hopefully working normal i2c-device for your touchpad.

But first lets confirm that that actually is the issue. I've created an ACPI DSDT override initrd with a modified DSDT for your device which drops the "OSYS == 0x07DF" check which seems to be failing, causing the broken XXXX0000 device to show up. Instead this DSDT is hardcoded to take the path which the original would take when "OSYS == 0x07DF" evaluates to true.

You can find this modified DSDT here:
https://fedorapeople.org/~jwrdegoede/initrd-thinkbook14-ill-dsdt-override.img

Note if you have installed a BIOS update since you did the acpidump which I requested then this image might be wrong, in that case please do a new acpidump and attach that here. Then I will get back to you with an updated img real quick (re-spinning it is not a lot of work). Note in case of doubt, the safe thing to do is make a new dump.

Assuming you have not done a BIOS update, here are the instructions for using the override initrd image. For now this is just modifying one kernel only, so that you can select another kernel to boot from the boot menu if things fail in a way which causes the system to not boot:

1. Save a copy of initrd-thinkbook14-ill-dsdt-override.img in /boot (save it in your home-dir and use:
   "sudo cp initrd-thinkbook14-ill-dsdt-override.img /boot" to copy it)
2. Run uname -r, note the output, e.g. 5.10.16-200.fc33.x86_64
3. Become root by running: "sudo su -" and then run the following commands:

cd /boot
mv "initramfs-$(uname -r).img" "initramfs-$(uname -r).img.orig"
cat initrd-thinkbook14-ill-dsdt-override.img "initramfs-$(uname -r).img.orig" > "initramfs-$(uname -r).img"

4. Reboot, run: "dmesg | grep DSDT" this should show output similar to this:

[    0.014051] ACPI: DSDT ACPI table found in initrd [kernel/firmware/acpi/dsdt.aml][0xc88f]
[    0.014809] ACPI: Table Upgrade: override [DSDT-ACRSYS-ACRPRDCT]
[    0.014818] ACPI: DSDT 0x000000007B042000 Physical table override, new table: 0x000000007A8B6000
[    0.014842] ACPI: DSDT 0x000000007A8B6000 00C88F (v02 ACRSYS ACRPRDCT 00000004 INTL 20190509)

(this is on an Acer device, obviously the output will be different on your Lenovo but you should have 2 lines similar to the lines with "override" in them in the output.

If you don't have the 2 lines with "override" in them, run "uname -r" again, if the output has changed a kernel update was installed, in that case redo steps 3-4.

If "uname -r" is unchanged and you don't have the 2 lines with "override" in them I likely did something wrong prepping the image, then please report back here.

Assuming you do get the 2 lines with "override" in them, please test your touchpad.

Also please run:

cat /sys/bus/acpi/devices/SYNA2B60\:00/status
cat /sys/bus/acpi/devices/CRQ0340\:00/status
cat /sys/bus/acpi/devices/ELAN062F\:00/status
cat /sys/bus/acpi/devices/XXXX0000\:00/status

And

ls -l /sys/bus/devices

again and add the output of these after the DSDT override to a comment here.

Oh, one more thing, it is a bit of a long shot in this case, but have you tried loading the BIOS default or optimal settings? 

Note if you are multibooting with Windows then this might very well remove the Fedora bootoption from the EFI boot menu. In that case you need to boot from a USB stick with a LiveCD on it and use efibootmgr to restore the Fedora boot entry.

Created attachment 1757475 [details]
Latest output of acpidump as requested by Hans De Goede

Thank you for your response! I went through it and seems quite straightforward for me to try..
However, I did a fresh acpi dump and it seems to differ from the earlier one that I provided to you, so I guess I might have installed some BIOS updates. Please find the latest dump attached in the previous message. 

Also, here are the list of kernels that are available on my system currently -
kernel-5.9.16-200.fc33.x86_64
kernel-5.10.13-200.fc33.x86_64
kernel-5.10.14-200.fc33.x86_64
I have booted from the latest one.

I only have Fedora on my system, and I'm pretty sure I have not changed any default settings in the BIOS. I did look for options related to mouse touchpad in the BIOS menu hoping to fix the issue in the beginning, but I don't think there was any.

Thanks again for all your help, let me know if you have any other queries!

I just checked and the only difference is in the dynamically generated BGRT table. The DSDT table is unchanged, so you can use the initrd image which I prepared earlier:

https://fedorapeople.org/~jwrdegoede/initrd-thinkbook14-ill-dsdt-override.img

p.s. Also it might still be worthwhile to try the load BIOS defaults thing. Sometimes some of the hidden advanced settings end up being wrong and loading the defaults also restores those to their defaults. And since you only have Fedora, the boot-order should automatically get restored by /boot/efi/EFI/boot/bootx64.efi calling /boot/efi/EFI/boot/fbx64.efi .

Hi,

So here is what all I've tried -

1) I went to my BIOS menu and restored the default settings but that didn't fix the issue.

2) I took your ACPI DSDT override initrd file and followed steps 3. and 4. from your earlier message but it doesn't seem to have worked as my touchpad is still broken.

$ dmesg | grep DSDT
[    0.016332] ACPI: DSDT ACPI table found in initrd [kernel/firmware/acpi/dsdt.aml][0x42a6d]
[    0.016378] ACPI: DSDT 0x00000000803A5000 042CEA (v02 LENOVO CFL      20170001 INTL 20160422)
[    0.620101] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC used to handle transactions
[    0.713201] ACPI: \_SB_.PCI0.LPCB.EC0_: Boot DSDT EC initialization complete

As you can see, I don't have the override lines here.. I checked the kernel version and it was also same after I rebooted, so no kernel updates.

Other outputs that you requested for are here -

cat /sys/bus/acpi/devices/SYNA2B60\:00/status --> 0
cat /sys/bus/acpi/devices/CRQ0340\:00/status  --> 0
cat /sys/bus/acpi/devices/ELAN062F\:00/status --> 0
cat /sys/bus/acpi/devices/XXXX0000\:00/status --> 15

ls -l /sys/bus/i2c/devices/
total 0
lrwxrwxrwx. 1 root root 0 Feb 19 10:57 i2c-0 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0
lrwxrwxrwx. 1 root root 0 Feb 19 10:58 i2c-1 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-1
lrwxrwxrwx. 1 root root 0 Feb 19 10:58 i2c-2 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-2
lrwxrwxrwx. 1 root root 0 Feb 19 10:58 i2c-3 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-3
lrwxrwxrwx. 1 root root 0 Feb 19 10:58 i2c-4 -> ../../../devices/pci0000:00/0000:00:02.0/i2c-4
lrwxrwxrwx. 1 root root 0 Feb 19 10:58 i2c-5 -> ../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/i2c-5
lrwxrwxrwx. 1 root root 0 Feb 19 10:58 i2c-6 -> ../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/i2c-6
lrwxrwxrwx. 1 root root 0 Feb 19 10:58 i2c-7 -> ../../../devices/pci0000:00/0000:00:1f.4/i2c-7
lrwxrwxrwx. 1 root root 0 Feb 19 10:57 i2c-XXXX0000:00 -> ../../../devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-XXXX0000:00


That's all... Thank you!

I think I know what is going on:

If you do:

dmesg | grep "kernel is locked down"

The output will likely be:

"kernel is locked down, ignoring table override"

This is caused by secureboot being enabled. If you disable secure-boot in your BIOS then the table override should work.

Angira, can you retry the DSDT overlay with secure-boot disabled please ?

I expect this to fix your touchpad not working. Once you have confirmed that, then I can dig a bit deeper to try and find out why the original DSDT is not working.

Dear Hans,

Apologies for replying so late. I got stuck with important work so didn't get a chance to try out the latest recipe your provided.

You were right, the issue is finally fixed, my mouse touchpad is working completely fine now!!!

I cannot comprehend in words how happy I am and how big of an annoying burden you have taken away from me!! Thank you is not probably enough, but unfortunately I can't do much from distance... 
So really, thank you so much for all the constant support and patience and for not giving up at any stage!


Cheers,
Angira.