Issue with the keyboard not working on touch screen laptop

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
                [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)    [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
i8042.nopnp     [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
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 file, this caught my eye:

I just hope it is not a new device with an old design on the second PS/2 port. :pray: :sweat_smile:

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:


i8042.nokbd didn’t have any effect, also not i8042.reset with i8042.kbdreset. But:

The patch works with the currend fedora development kernel which I built myself from current checkout based on 6.2.0-0-rc6. I’ve also modularized the ATKBD and PS2MOUSE to enable building the I8042 as module I for easer debugging.

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. :slight_smile:

1 Like

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.

@bkaindl I had a very similar issue with the keyboard on my Yoga 14sIHU 2021 (branded as Yoga Slim 7 Pro 14IHU5 outside Mainland China). That Anton’s patch works only once in a while on my laptop, so I took my investigation and made another patch GitHub - yescallop/atkbd-nogetid: Fixes slow keyboard initialization on some Lenovo Yoga / XiaoXinPro / IdeaPad (14", Intel) laptops. that might also solve the issue on a Yoga Slim 7 ProX. It would be great if someone can try it out and see if it works.

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!

Patch: Tree - rpms/kernel -
Build: Build 5738122 in bkaindl/kernel (in COPR, just started)

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!