[SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

Eddie_Foss · 2024-01-02 04:53:02

Firstly I can't program lower level like drivers but could I understand the mechanisms that loads PS/2 keyboard;

I bought last week a laptop from chinese/japanese brand [Seryub] it's a good price / performance, a Ryzen 7 5700U 16G Ram, everything works except fingerprint reader and keyboard, I can live without fingerprint reader but not keyboard.
The keyboard freezes after kernel starts, works in UEFI/BIOS, grub, and MSWindows, after digging up over internet I found that i8042.dumbkbd solves many other people problems but for me seems bugged as any key press delays it for 1 sec to input then repeat presses for more 18 times turning impossible to use this way.

I did use modprobe to load and unload modules and all other kernel parametes listed in modinfo but the only parameter that returns some positive is dumbkbd that at least respond key presses.

Is there anything else I can do or just give up and put back Windows on it?

Last edited by Eddie_Foss (2024-03-11 22:48:49)

seth · 2024-01-02 15:49:53

Test the multi-user.target (console only, no display server anywhere), whether an external keyboard is affected, whether the LTS kernel is affected and please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Eddie_Foss · 2024-01-06 07:58:44

Sorry late answer, I went to MSWin for a while and I hate the Win11 experience.

I'm back on Arch and latest updates had no fix for my issue, so, I'm here to report all what I tried;

This threads is related to the problem I have:
https://www.linux.org/threads/lenova-id … ard.46123/
https://unix.stackexchange.com/question … ot-working
https://bbs.archlinux.org/viewtopic.php?id=255362
https://bbs.archlinux.org/viewtopic.php?id=277260
https://bbs.archlinux.org/viewtopic.php?pid=1996739
https://bbs.archlinux.org/viewtopic.php?id=274130
https://bbs.archlinux.org/viewtopic.php?id=274130&p=2

I built "acpi_override" from the thread below but made no difference
https://www.reddit.com/r/linuxhardware/ … t/ijjjwah/

And this one below with i8042.dumbkbd=1 option
https://unix.stackexchange.com/question … linux-mint

After all of those trials the only erratic response is with dumbkbd=1 which at least make keyboard responsive but with "echoing" behaviour, each key press takes 1 second to react then after first character appearing around ~250ms another 18 others appears.

I'm not sure but it seems that serio module loads run some detection that loads i8042 that loads atkbd when it freezes the keyboard unless the kernel option dumbkbd is enabled

Being a laptop any external keyboard defeats any purpose of portability, so now I'm in a dead end.

seth · 2024-01-06 14:33:05

Being a laptop any external keyboard defeats any purpose of portability, so now I'm in a dead end.

The point is to see whether it's specific to the (internal) keyboard or something on a higher level of input handling.
Did you test the LTS kernel and the multi-user.target (to rule out the display server)?

You didn't post the journal.

Eddie_Foss · 2024-01-06 14:47:57

With wev tool I saw that the key release event for PS/2 takes too long to display

USB Keyboard
[14: wl_keyboard] key: serial: 7588; time: 27003004; key: 54; state: 1 (pressed)
sym: c (99), utf8: 'c'
[14: wl_keyboard] key: serial: 7589; time: 27003076; key: 54; state: 0 (released)
sym: c (99), utf8: ''

PS/2 Built-in Keyboard
[14: wl_keyboard] key: serial: 7590; time: 27006601; key: 54; state: 1 (pressed)
sym: c (99), utf8: 'c'
[14: wl_keyboard] key: serial: 7591; time: 27007641; key: 54; state: 0 (released)
sym: c (99), utf8: ''

Eddie_Foss · 2024-01-07 04:26:39

Wthout dunbkbd=1

http://0x0.st/H6n5.txt

With dumbkbd=1

http://0x0.st/H6nR.txt

seth · 2024-01-07 09:41:25

With wev tool I saw that the key release event for PS/2 takes too long to display

I'll infer from the comparism that the USB keyboard does not exhibit the same behavior?

Wild guess: disable TLP.

Eddie_Foss · 2024-01-07 14:52:41

seth wrote:

With wev tool I saw that the key release event for PS/2 takes too long to display
I'll infer from the comparism that the USB keyboard does not exhibit the same behavior?
Wild guess: disable TLP.

Same behaviour with and without TLP;

USB keyboard no problem, only internal PS/2 as USB doesn't go through i8042 kernel module.

The i8042 driver is probably incompatible with new PS/2 microcontrollers as my laptop is not the only having this behaviour.

I went to this https://github.com/DavidS95/Smokeless_UMAF to check if I have any other option hidden locked by maker of this laptop but no deal too.

Last edited by Eddie_Foss (2024-01-09 02:08:42)

seth · 2024-01-09 23:03:10

USB doesn't go through i8042 kernel module

Yes, that's the point (the idea was to verify that it's the bus and not some userspace daemon or the output)

Do you have interesting parameters in /sys/devices/platform/i8042/serio*/* ?
https://forums.linuxmint.com/viewtopic.php?t=310359

Eddie_Foss · 2024-01-09 23:10:22

Well, I was reading about 8042 controller that long time ago was made by Intel for XT machines and then for AT, my problem may be related to USB legacy support and I may have to recompile the kernel

I'll try your suggestion when I go back home tonight,
Thanks in advance

Eddie_Foss · 2024-01-10 22:06:16

seth wrote:

USB doesn't go through i8042 kernel module
Yes, that's the point (the idea was to verify that it's the bus and not some userspace daemon or the output)
Do you have interesting parameters in /sys/devices/platform/i8042/serio*/* ?
https://forums.linuxmint.com/viewtopic.php?t=310359

With dumbkbd disabled it hangs and never detects any keyboard connected to serial protocol (serio), with dumbkbd enabled detects but it's too simple that has zero configs that differs from parameters already listed in modinfo, the BIOS is an AMI Aptio with only "System Information" page and "Boot Configuration" anything else was hidden or stripped by maker so I tried to find something else with "UMAF" but was nothing there. During my research I found this https://www.kernel.org/doc/html//v5.11/ … pport.html and I'll be checking tonight;
And if nothing else works I'll be trying to understand how it works with this, https://wiki.osdev.org/%228042%22_PS/2_Controller
☺️

seth · 2024-01-10 22:26:49

With dumbkbd disabled it hangs and never detects any keyboard

Did you try noaux, nomux and nopnp (or any combination thereof) instead of "dumbkbd"?

Eddie_Foss · 2024-01-11 03:16:26

seth wrote:

With dumbkbd disabled it hangs and never detects any keyboard
Did you try noaux, nomux and nopnp (or any combination thereof) instead of "dumbkbd"?

Well, dumbkbd it's the only that not freeze the keyboard, everything else gets stuck.

Last edited by Eddie_Foss (2024-01-11 21:10:53)

opsecfail · 2024-01-24 16:47:36

I have the exact same issue with the same hardware. The only difference is mine is from a Turkish brand named 'Casper'.

It works with old versions of distros like Debian 10 and Debian 11. Also OpenBSD just works fine.

On the Arch side it only works with archlinux-2023.08.01-x86_64.iso and images before archlinux-2022.09.03-x86_64.iso.

I tried maybe 30 combination of kernel parameters with lots of different up-to-date distros but the best I can get is 1-5 seconds latency (plus x18 key presses if I'm lucky) with i8042.dumbkbd parameter.

seth · 2024-01-25 14:55:38

Do you have comparative journals (from a good and bad distro boot)?

lulzette · 2024-02-12 15:47:49

Hi.

Recently I bought Lunnen 16, which looks very similar to Seryub and also have Ryzen 7 5800U, issues are the same, keyboard does not work at all, with dumbkbd keys respond very slowly.

I found that keyboard works on archiso from 2023.08.01 with kernel 6.4, but on any distros with newer and older kernel keyboard does not work (I tried Fedora with older kernel and archlinux with newer kernel), Artix uses kernel 6.4, so it also works.

Looks like it is common problem with Ryzen 5XXX

raorn · 2024-02-12 16:43:21

Lunnen 16 user here too. Fedora 39, i8042.dumbkbd is the only option that make internal keyboard responsible (with 1 second key-release delay).

Might be related to https://bbs.archlinux.org/viewtopic.php?id=277260, also Ryzen...

Udate: Well, this fixes the problem:

--- drivers/acpi/resource.c.orig	2024-02-12 22:20:44.034931673 +0300
+++ drivers/acpi/resource.c	2024-02-12 22:19:16.169482965 +0300
@@ -576,6 +576,13 @@
 			DMI_MATCH(DMI_BOARD_NAME, "GM6BG0Q"),
 		},
 	},
+	{
+		/* Lunnen Ground 16 */
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Lunnen"),
+			DMI_MATCH(DMI_BOARD_NAME, "LL6FA"),
+		},
+	},
 	{ }
 };

[    0.332310] ACPI: IRQ 1 override to edge, high(!)

Now going to report it upstream...

Last edited by raorn (2024-02-12 21:45:44)

raorn · 2024-02-12 21:41:32

Eddie_Foss wrote:

I bought last week a laptop from chinese/japanese brand [Seryub] it's a good price / performance, a Ryzen 7 5700U 16G Ram

Can you show like first 50 lines of dmidecode output?

raorn · 2024-02-13 10:10:48

Alternate solution without patching kernel.

Install ACPICA tools (acpica-tools package in Fedora, YMMV)

Dump DSDT

$ sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

Disassemble DSDT

$ iasl -d dsdt.dat

Now edit the resulting dsdt.asl file, you need to chage version (so DSDT can be patched) and update PNP0303 device. For me (Lunnen Ground 16) this patch worked:

--- ../acpi/dsdt.dsl.orig	2024-02-12 20:03:04.450414071 +0300
+++ dsdt.dsl	2024-02-13 12:43:42.570630772 +0300
@@ -18,7 +18,7 @@
  *     Compiler ID      "INTL"
  *     Compiler Version 0x20200717 (538969879)
  */
-DefinitionBlock ("", "DSDT", 2, "ALASKA", "A M I ", 0x01072009)
+DefinitionBlock ("", "DSDT", 2, "ALASKA", "A M I ", 0x0107200a)
 {
     External (_SB_.ALIB, MethodObj)    // 2 Arguments
     External (_SB_.APTS, MethodObj)    // 1 Arguments
@@ -6365,7 +6365,7 @@
                     0x00,               // Alignment
                     0x01,               // Length
                     )
-                IRQ (Edge, ActiveLow, Shared, )
+                Interrupt (ResourceConsumer, Edge, ActiveHigh, Shared, ,, )
                     {1}
             })
             Name (_PRS, ResourceTemplate ()  // _PRS: Possible Resource Settings

I increased version (so DSDT can be overriden) and changed IRQ to Interrupt(ResourceConsumer, ...) while also altering level from ActiveLow to ActiveHigh.

Now compile this back to asl

$ iasl -tc dsdt.dsl
...
ASL Input:     dsdt.dsl -  238309 bytes   2618 keywords   7094 source lines
AML Output:    dsdt.aml -   27393 bytes   1608 opcodes    1010 named objects
Hex Dump:      dsdt.hex -  257264 bytes

Compilation successful. 0 Errors, 27 Warnings, 50 Remarks, 100 Optimizations

Now you need to add updated file to initrd. There are many ways to aoverride DSDT, google "<your distro name> DSDT override". I'm using dracut on Fedora, so copied dsdt.asl to /etc/acpi and created /etc/dracut.conf.d/acpi.conf:

acpi_override="yes"
acpi_table_dir="/etc/acpi"

and then

$ sudo dracut -f
...
dracut: *** Packaging ACPI tables to override BIOS provided ones ***
dracut:    Adding ACPI table: /etc/acpi/dsdt.aml
...
dracut: *** Creating initramfs image file '/boot/initramfs-6.7.4-200.fc39.x86_64.img' done ***

Hope that helps!

Eddie_Foss · 2024-02-13 14:28:27

Sorry everyone for a very, very late answer, I was very busy in my job;
Today I found a solution with just one kernel parameter!!!
In the "GRUB_CMDLINE_LINUX_DEFAULT" I just appended "pnpacpi=off" and the keyboard worked like a charm!!!!
My hypothesis is that acpi method conflicts with legacy methods (possibly PS/2 can't communicate properly by ACPI) causing irq conflicts where the keyboard can't be detected at normal state and with dumbkbd=true (in my case) detects but with crazy interruption turning unusable.

I hope this helps many others with similar issue but as I'm not a hardware specialist I don't know how much absence of ACPI PNP affects other parts, at this moment everything looks normal in my system.

Thank you guys so much and sorry for the hassle
Best regards,
Eddie

Last edited by Eddie_Foss (2024-02-13 14:33:04)

lulzette · 2024-02-13 14:39:25

Eddie_Foss wrote:

Sorry everyone for a very, very late answer, I was very busy in my job;
Today I found a solution with just one kernel parameter!!!
In the "GRUB_CMDLINE_LINUX_DEFAULT" I just appended "pnpacpi=off" and the keyboard worked like a charm!!!!
My hypothesis is that acpi method conflicts with legacy methods (possibly PS/2 can't communicate properly by ACPI) causing irq conflicts where the keyboard can't be detected at normal state and with dumbkbd=true (in my case) detects but with crazy interruption turning unusable.
I hope this helps many others with similar issue but as I'm not a hardware specialist I don't know how much absence of ACPI PNP affects other parts, at this moment everything looks normal in my system.
Thank you guys so much and sorry for the hassle
Best regards,
Eddie

Yep, "pnpacpi=off" worked, without DSDT overriding and kernel patches. That was so simple.

raorn · 2024-02-13 15:00:15

Don't forget, that if you disable pnpacpi, you better turn off "Fast boot" or "PnP OS installed" setting in BIOS.

djoksa · 2024-05-20 23:24:40

Eddie_Foss wrote:

Sorry everyone for a very, very late answer, I was very busy in my job;
Today I found a solution with just one kernel parameter!!!
In the "GRUB_CMDLINE_LINUX_DEFAULT" I just appended "pnpacpi=off" and the keyboard worked like a charm!!!!
My hypothesis is that acpi method conflicts with legacy methods (possibly PS/2 can't communicate properly by ACPI) causing irq conflicts where the keyboard can't be detected at normal state and with dumbkbd=true (in my case) detects but with crazy interruption turning unusable.
I hope this helps many others with similar issue but as I'm not a hardware specialist I don't know how much absence of ACPI PNP affects other parts, at this moment everything looks normal in my system.
Thank you guys so much and sorry for the hassle
Best regards,
Eddie

Had a similar issue - my laptop keyboard would stop working after going to sleep.
pnpacpi=off solved the problem but introduced another one - now when laptop goes to sleep and wakes up the function (Fn) keys are no longer working.
Any ideas?

Arch Linux

#1 2024-01-02 04:53:02

[SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#2 2024-01-02 15:49:53

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#3 2024-01-06 07:58:44

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#4 2024-01-06 14:33:05

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#5 2024-01-06 14:47:57

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#6 2024-01-07 04:26:39

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#7 2024-01-07 09:41:25

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#8 2024-01-07 14:52:41

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#9 2024-01-09 23:03:10

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#10 2024-01-09 23:10:22

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#11 2024-01-10 22:06:16

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#12 2024-01-10 22:26:49

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#13 2024-01-11 03:16:26

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#14 2024-01-24 16:47:36

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#15 2024-01-25 14:55:38

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#16 2024-02-12 15:47:49

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#17 2024-02-12 16:43:21

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#18 2024-02-12 21:41:32

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#19 2024-02-13 10:10:48

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#20 2024-02-13 14:28:27

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#21 2024-02-13 14:39:25

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#22 2024-02-13 15:00:15

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

#23 2024-05-20 23:24:40

Re: [SOLVED] PS/2 keyboard on i8042 conflicts with PnP ACPI

Board footer