Bug 216994
| Summary: | Goodix(27C6:0123)/i8042 keyboard not detected on Alder Lake Lenovo Yoga Slim 7 ProX 14IAH7 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | bernhard.kaindl (bernhard.kaindl) |
| Component: | Input Devices | Assignee: | drivers_input-devices |
| Status: | NEW --- | ||
| Severity: | blocking | CC: | luis.pixeltux |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| URL: | https://ask.fedoraproject.org/t/issue-with-the-keyboard-not-working-on-touch-screen-laptop/30944 | ||
| Kernel Version: | 6.1.6 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg normal boot
dmesg boot pressing the CapsLk |
||
|
Description
bernhard.kaindl@cloud.com
2023-02-03 01:09:36 UTC
I could be similar to this and maybe fixed by the same patch: https://bbs.archlinux.org/viewtopic.php?id=261108&p=2 https://patchwork.kernel.org/project/linux-input/patch/20210201160336.16008-1-anton@cpp.in/ https://wiki.archlinux.org/title/HP_Spectre_x360_(2020)#Keyboard The patch got no reaction on the linux-input list and still applies clean on Linux 6.1. Created attachment 303682 [details]
dmesg normal boot
"dmesg | grep -i 'PS/2\|multitouch\|keyboard\|i8042\|i2c\|AT Translated'"after fresh boot with "i8042.debug i8042.unmask_kbd_data" enabled.
powered up the system >> wait for the Login screen
Created attachment 303683 [details]
dmesg boot pressing the CapsLk
"dmesg | grep -i 'PS/2\|multitouch\|keyboard\|i8042\|i2c\|AT Translated'"after fresh boot with "i8042.debug i8042.unmask_kbd_data" enabled.
powered up the system >> pressing repetitively and quick the CapsLk until the LED representing the CapsLk start blinking as I press the CapsLk (this action work just after the GRUB as before booting the everything works as expected ) >> then wait for the Login screen. Sometime started working just shortly before the Login screen.
I've attached 2 files "dmesg.txt" and "dmesg CapsLk.txt", log data by using the command "dmesg | grep -i 'PS/2\|multitouch\|keyboard\|i8042\|i2c\|AT Translated'"after fresh boot with "i8042.debug i8042.unmask_kbd_data" enabled. I also tried installing different distros but had the same problem with the keyboard. The distros that have worked for me so far are Clear Linux (latest version 37xxx at that moment) and Fedora, the others crash in GRUB as mentioned by bernhard. By boot with 'i8042.dumbkbd=1' the keyboard works, but since this pretends that the controller can only read data from the keyboard and cannot check its status, it prevents the LED indicator from working, like the LED that indicates whether CapsLk is on or off. If you need further tests or data, I am willing to provide them, but just instruct me step by step because I am new and need guidelines. Update: https://discussion.fedoraproject.org/t/71036/28 I’ve created a minimal workaround, to be submitted as RFC to the atkbd maintainers for inclusion into the upstream Linux kernel: * It adds a new atkbd kernel parameter: atkbd.getid (ATM untested if it can be manually set) It is a bool and by default, it getid is enabled, and if unset it disables the GETID command! * When the DMI System Vendor is “LENOVO”, it disables the getit parameter: * Not yet checked if this is just set to be default off or forcibly off) This skips the GETID command on my Lenovo Yoga and fixes my keyboard probing: * My keyboard works without any hammering of keys during boot as otherwise required! Patch: https://src.fedoraproject.org/fork/bkaindl/rpms/kernel/blob/f38/f/linux-kernel-test.patch Build: https://copr.fedorainfracloud.org/coprs/bkaindl/kernel/build/5738122/ Hopefully the COPR build finishes successfully, then Luis and all interested Lenovo users which run Fedoara 37 or 38 can try if it works and does not cause regressions! Note: I plan to submit is as an RFC to to the kernel atkbd maintainers for inclusion in to the upstream Linux kernel, likeyly with the DMI match extended to be fine-grained for the notebooks which need it. For this fine-grained DMI matching, we need the output of dmesg|grep DMI after boot of all affected notebooks/systems! Any help to get this information would be very appreciated, please help to get this DMI info, thanks! It looks like the problem has been resolved in Linux version 6.7.9-200.fc39.x86_64 (I'm on Fedora). It's likely that the issue was fixed in a few versions prior to this one. I've been using the keyboard without any issues for about 2 months now. |