2

Update 2: Found below in dmesg for a single Fn key press/release (even on released this month Ubuntu 25.10):

[ +4.340795] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0). [ +0.000019] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known. [ +0.009265] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0). [ +0.000013] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.

Wonder if other people also seeing the above for Fn press/release?

Update: The question remains if laptop with Ryzen 5 7535HS has a separate from APU/CPU chip with a platform controller that emulates i8042?

If yes, how to determine the platform controller?

================================

I'm troubleshooting non-release of certain Fn+ key combinations in Lenovo laptop and need to find internal keyboard controller model/vendor/Product # (and any HW specific details) to properly report a bug.

dmesg gives below, but PNP0303:KBD0 seems to be a generic device:

[ 0.566676] i8042: PNP: PS/2 Controller [PNP0303:KBD0] at 0x60,0x64 irq 1 [ 0.566681] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [ 0.568551] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 0.587423] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2

Not talking about /dev/... device here.

Is internal keyboard controller sitting on pci or usb bus?

Any keywords for filtering lsusb/lspci output?

What PNP0303 and KBD0 mean?

The issue shows up even at evtest level (with 6.17 kernel), so I'm pretty sure its a kernel level bug.

Thank you.

Improve this question

2 Answers 2

Reset to default
3

Is internal keyboard controller sitting on pci or usb bus?

No, as the anachronistic labeling as "i8042" (intel i8042, the keyboard controller of the IBM PC-AT, from 41 years ago) says, this is an emulated peripheral. It's almost certainly emulated by the "Advanced Integrated Peripheral", which on a laptop CPU might be part of a the CPU or one of its directly attached peripheral chips, I'm not too sure; I'd tend towards it being in the platform controller. In any case, no, it does not directly nor indirectly sit on USB, and at best indirectly reside within the PCI hierarchy (but probably not; these are the things that you addressed with special IO instructions directly from the CPU, and CPUs, forty years ago, had their own port just for this controller!). What might be the case is that your system's firmware has been told to emulate a PS/2 peripheral, and could be told to not do that and instead present the keyboard as USB device. Some laptops have such an option in their firmware setups. Look for "legacy OS support" or something and disable it.

Your output points to this being an ACPI-PnP-connected peripheral. That won't help you at all, because that just means status information is literally exchanged using the x86 inb operation; what that does internally to the CPU: not of Linux' concern. It just means it doesn't fall under the categories "PCI device" nor "attached to a USB bus (which typically is attached via a PCI device)" at all.

There's no specific driver code in Linux to drive that (emulated) keyboard controller; this is all quite standard.

Experience also tells me that the things that laptop keyboards do are often extremely quirky. I had to do with one acer laptop whose keyboard controller would send duplicate reports; that was solved in software in a acer-provided driver for windows (on a DVD, no less!); so you had a maximum typing speed for words with consecutive letters on this machine. So, I would not preemptively blame Linux here. The same driver works beautifully on thousands of other, standards-compliant keyboards.

Note that if you look into the Linux kernel's i8042-acpipnpio.h, you'll find a table with 157 entries for "i8042 implementation quirks". In other words, this is so very common for mainboard firmware suppliers to mess up (and frankly, i8042 is one of the least complex legacy peripherals), that there's 157 hotfixes in the Linux kernel for mainboards that just don't work with a correct implementation. Great!

Anyways, you ask how

to find internal keyboard controller model/vendor/Product

and that's easy: look up your laptop's platform controller and CPU. That's where the controller lives. It's not its own chip (and hasn't been for > 30 years).

Improve this answer
11
  • Thank you, very helpful! Is platform controller a part of Ryzen 5 7535HS? i.e. same chip as APU/CPU? If not, how do I find it? Commented Oct 20 at 20:57
  • "I had to do with one acer laptop whose keyboard controller would send duplicate reports" - Have you found this with evtest or there's a lower level keyboard utility? Commented Oct 20 at 22:41
  • Checked BIOS carefully, there's nothing even remotely reminding "legacy OS support". The only option that might indicate BIOS messing with keyboard is "Fool proof Fn Ctrl" - disabled it, and the non-release issue is still present. Commented Oct 20 at 23:02
  • Re: how did you find that? I typed text. Letters appeared twice. People report the same issue on fresh windows installations with default drivers. Hardware/firmware issue. Commented Oct 21 at 11:25
  • Re: legacy options (there's ironically actually things that were part of the original BIOS involved, but what you interacted with has absolutely nothing to do with a BIOS, it's just your firmware setup): not every laptop has these, as said, some. Was worth a try! Commented Oct 21 at 11:27
1

One can only look for a "Parent" device/chip.

See Marcus Müller's answer.

Method 1) On Ryzen this command is likely to output "parent" chip/device for the emulated keyboard controller:

lspci -nnn | grep "ISA bridge"

or if no output

lspci -nnn | grep "ISA" |grep "bridge"

Method 2 (using Windows)):

Honestly I found this using Windows (this may be a more generic way if Windows is accessible of course):

  • In Windows (works at least with Win 11) open device manager
  • find keyboard device and open properties
  • Click "events" tab
  • Find "Parent Device" - there will be something like DEV_xxxx.
  • (in Linux) run lspci -nnn | grep "xxxx" from the last step (remove letters as they are case-sensitive (or use some regexp)).
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.