Looks like similar issue has been encounter on Lenovo i9 Yoga Slim touch screen (Link).
I read this and is relay interesting and combined with the kernel parameters (link to full list) I have a better understanding of what is happening when I add thous parameters :
kernel parameters:
...
i8042.debug [HW] Toggle i8042 debug mode
i8042.unmask_kbd_data
[HW] Enable printing of interrupt data from the KBD port
(disabled by default, and as a pre-condition
requires that i8042.debug=1 be enabled)
i8042.direct [HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
keyboard and cannot control its state
(Don't attempt to blink the leds)
i8042.noaux [HW] Don't check for auxiliary (== mouse) port
i8042.nokbd [HW] Don't check/create keyboard port
i8042.noloop [HW] Disable the AUX Loopback command while probing
for the AUX port
i8042.nomux [HW] Don't check presence of an active multiplexing
controller
i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
controllers
i8042.notimeout [HW] Ignore timeout condition signalled by controller
i8042.reset [HW] Reset the controller during init, cleanup and
suspend-to-ram transitions, only during s2r
transitions, or never reset
Format: { 1 | Y | y | 0 | N | n }
1, Y, y: always reset controller
0, N, n: don't ever reset controller
Default: only on s2r transitions on x86; most other
architectures force reset to be always executed
i8042.unlock [HW] Unlock (ignore) the keylock
i8042.kbdreset [HW] Reset device connected to KBD port
i810= [HW,DRM]
...
As far as we know the only parameter that makes a difference is i8042.dumbkbd and what it dose it’s to Pretend that controller can only read data from keyboard and cannot control its state (Don’t attempt to blink the leds).
Now, while reading the wiki.osdev.org file, this caught my eye:
I just hope it is not a new device with an old design on the second PS/2 port.
On the IBM PS/2 or AT compatible PCs, the two PS/2 ports were used for one Keyboard and one Mouse, but in theory the Keyboard could be plugged into the 2nd port for mice.
The guy who rewrote the interrupt handler to try to read the whole GETID response from the i8042 port wrote that the i8042 is just emulated by the microcontroller firmware of modern keyboards.
Since our model also detects an I2C HID keyboard, maybe the keyboard’s firmware sends the keys using the I2C HID interface when the i8042 port is not touched by the OS, the parameter for this should be:
So far, the the self-built kernel rpms with patched i8042 module works fine! I can upload/push the changes with instructions if someone needs them. Build time of the base kernel only with my flags on this notebook was 25mins with BIOS set to silent mode, so it’s not an ordeal to build.
I try it out too and in my case i8042.nokbd disables all keyboard commands (no feed back from the function key and FnLock key), only the touch screen works.
I would be interested to know how you did it. Also I wonder if this might interfere with future fedora updates. Consider that I have no experience in building my own kernel.
@yescallop
Your patch should work, but I am looking for a generic solution which can be upstreamed.
The minimum patch would be to just remove the GET_ID (ATKBD_CMD_GETID) command.
The next check would be the command to check and clear the LEDs and so on.
This should then work for all keyboards hopefully.
Or, we may need to add a quirk to the upstream Linux kernel to omit GET_ID only for the affected laptops, which may be safer.
My dmesg output shows me the DMI system vendor and board long before, so if we can get
the DMI: Line (from dmesg) from all affected models, we could match these and skip the GET_ID:
[ 0.000000] DMI: LENOVO 82TK/LNVNB161216, BIOS HMCN33WW 07/22/2022
@pixel@yescallop: I’ve created a minimal workaround - patch as described above:
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!
Hopefully the COPR build finishes successfully, then @pixel and any Lenovo user could 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!
