Internal keyboard dead on ADVAN 1405 (APN21S-140P3-CS): i8042 controller OK, keyboard device never ACKs

Internal keyboard dead on ADVAN 1405 (APN21S-140P3-CS): i8042 controller OK, keyboard device never ACKs

[Pujito Adnyana]

Hello,

The internal keyboard on an ADVAN 1405 laptop (AMD Ryzen 5 3500U,
Picasso) does not work under Linux. The keyboard works correctly in
the BIOS setup utility and in the GRUB menu, so the hardware, the FPC
cable and the embedded controller are all functional up to the point
where the kernel takes over the i8042 port. An external USB keyboard
works fine, and the I2C-HID touchpad on the same machine works fine.

The i8042 controller itself passes its self-test and responds
correctly to every controller-level command. The keyboard device
behind it never acknowledges a single keyboard-level command, and no
scancodes are ever delivered.

System information
Model:        ADVAN 1405 (family "soulmate plus")
Baseboard:    SU / APN21S-140P3-CS
BIOS:         American Megatrends 2.03, 09/05/2024
CPU:          AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (Picasso)
Kernel:       6.19.10-300.fc44.x86_64
Distribution: Fedora 44 (Workstation)
Firmware:     UEFI, Secure Boot disabled

DMI strings, for a potential quirk entry:

sys_vendor:      ADVAN
product_name:    1405
board_vendor:    SU
board_name:      APN21S-140P3-CS

This is not a regression introduced by a recent kernel: the same
problem was observed on Ubuntu before this machine was moved to
Fedora.

Symptoms
Internal keyboard produces no input at all under Linux, in the
graphical session and on the text console alike. Not even the Caps
Lock LED reacts.
The same keyboard works in the BIOS setup utility.
The same keyboard works in the GRUB menu (arrow keys and Enter
navigate the boot entries correctly), i.e. it is still alive after
UEFI hands over to the bootloader.
An external USB keyboard (04d9:0203) works normally.
The I2C-HID touchpad (093A:0255 on AMDI0010:01) works normally.
Kernel messages

Without debugging enabled:

i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect
       please boot with i8042.nopnp
serio: i8042 KBD port at 0x60,0x64 irq 1
atkbd serio0: Failed to deactivate keyboard on isa0060/serio0
atkbd serio0: Failed to enable keyboard on isa0060/serio0
input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input4

The input device is registered, but it never emits an event.

i8042.debug trace

Booted with i8042.debug=1 i8042.unmask_kbd_data=1:

i8042: [0] 20 -> i8042 (command)
i8042: [1] 65 <- i8042 (return)
i8042: [1] 20 -> i8042 (command)
i8042: [1] 65 <- i8042 (return)
i8042: [1] 60 -> i8042 (command)
i8042: [1] 74 -> i8042 (parameter)
i8042: [1] 60 -> i8042 (command)
i8042: [1] 65 -> i8042 (parameter)
serio: i8042 KBD port at 0x60,0x64 irq 1
i8042: [2] f5 -> i8042 (kbd-data)
i8042: [211] ed -> i8042 (kbd-data)
i8042: [418] f4 -> i8042 (kbd-data)
input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input4

Observations:

Controller-level traffic is entirely normal. The CCB reads back as
0x65 (keyboard interrupt enabled, keyboard clock enabled, translation
enabled), is temporarily set to 0x74 during probing, and is restored
to 0x65.
A controller self-test (aa -> 55) passes whenever it is issued.
Every keyboard-level command (f5 disable scanning, ed set LEDs, f3 set
typematic, f4 enable scanning) is sent and never acknowledged. The
~205 ms spacing between consecutive commands is the command timeout.

Forcing a reconnect via

echo -n "reconnect" > /sys/devices/platform/i8042/serio0/drvctl

reproduces the same pattern. On one occasion, and only once across
many attempts, a late acknowledgement did arrive:

i8042: [943273] f6 -> i8042 (kbd-data)
i8042: [943474] fa <- i8042 (flush, kbd)
i8042: [943474] Interrupt 1, without any data

The fa arrived roughly 200 ms after the command was sent — just past
the timeout, so the driver had already given up and the byte was
discarded during the flush. The accompanying "Interrupt 1, without any
data" suggests IRQ 1 was asserted while OBF was not yet set when the
kernel sampled the status register.

No <- i8042 (interrupt, kbd) line is ever produced, under any
configuration, when a key is pressed.

ACPI

The keyboard is declared in the DSDT as follows:

Scope (_SB.PCI0.SBRG)
{
    Device (PS2K)
    {
        Name (_HID, "MSFT0001")
        Name (_CID, EisaId ("PNP0303"))
        Method (_STA, 0, NotSerialized)
        {
            Return (0x0F)
        }
        Name (_CRS, Buffer (0x16)
        {
            0x47, 0x01, 0x60, 0x00, 0x60, 0x00, 0x00, 0x01,
            0x47, 0x01, 0x64, 0x00, 0x64, 0x00, 0x00, 0x01,
            0x23, 0x02, 0x00, 0x19, 0x79, 0x00
        })
        Name (_PRS, Buffer (0x18) { ... })
        Method (_PSW, 1, NotSerialized)
        {
            KBFG = Arg0
        }
    }
}

Points worth noting:

_STA returns 0x0F unconditionally. There is no _OSI-dependent branch,
so the firmware is not hiding the device from non-Windows systems. For
completeness, several acpi_osi= variants were tried anyway and made no
difference. (acpi_osi=! on its own additionally kills the backlight on
this machine and leaves the display blank.)
Resources are entirely conventional: ports 0x60 and 0x64, IRQ 1.
_HID is MSFT0001 with PNP0303 only as _CID. Linux matches on the _CID
and enumeration succeeds, so this does not appear to be the problem,
but it is unusual enough to mention.

The keyboard device and the embedded controller share a parent scope:

MSFT0001:00 -> .../LNXSYBUS:00/PNP0A08:00/device:3a/MSFT0001:00
PNP0C09:00  -> .../LNXSYBUS:00/PNP0A08:00/device:3a/PNP0C09:00

This suggests the PS/2 keyboard is emulated by the EC rather than
being an independent PS/2 device. The EC itself initialises without
complaint:

ACPI: EC: EC started
ACPI: EC: interrupt blocked
ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
ACPI: EC: interrupt unblocked
ACPI: EC: event unblocked
ACPI: EC: GPE=0x3
Kernel parameters tried, without success

Individually and in combination:

i8042.dumbkbd
i8042.nopnp
i8042.reset
i8042.reset=never
i8042.nomux
i8042.noloop
i8042.notimeout
i8042.probe_defer
i8042.unmask_kbd_data
atkbd.reset=1
acpi_osi=! acpi_osi="Windows 2015"
acpi_osi=Linux

i8042.dumbkbd is of particular interest. With it, f5/ed/f3/f4 are
never sent, the CCB is left at 0x65, and the keyboard is left in
whatever state the firmware handed over — yet still no scancodes
arrive. This suggests the firmware leaves scanning disabled on
ExitBootServices, so the keyboard genuinely needs the f4 that never
gets acknowledged. That leaves no working path: with f4 the command
times out, without f4 the keyboard is never enabled.

A cold EC reset (full power off, adapter removed, power button held
for 60 seconds) was performed before testing and changed nothing. The
machine has no Windows installation left, so no cross-check against
the vendor OS is available.

Question

Is there a way to make atkbd tolerate an acknowledgement that arrives
just past the command timeout, or to retry enabling scanning after the
initial probe? If a DMI quirk is the right mechanism here, I am happy
to test patches and provide any further data needed.

Full dmesg output, the decompiled DSDT and acpidump output are
available on request, or can be attached if preferred.

Thanks for your time.
Pujito Adnyana
+6285935178773
zhee.tou@gmail.com

Re: Internal keyboard dead on ADVAN 1405 (APN21S-140P3-CS): i8042 controller OK, keyboard device never ACKs

[Lovekesh Solanki]

Hi thanks for the report,

On Mon, Sep 14, 2026 at 08:14:24AM +0800, Pujito Adnyana wrote:
> i8042: [943273] f6 -> i8042 (kbd-data)
> i8042: [943474] fa <- i8042 (flush, kbd)
> i8042: [943474] Interrupt 1, without any data
> 
> The fa arrived roughly 200 ms after the command was sent — just past
> the timeout, so the driver had already given up and the byte was
> discarded during the flush. The accompanying "Interrupt 1, without any
Yeah that seems like the cause.

> Is there a way to make atkbd tolerate an acknowledgement that arrives
> just past the command timeout, or to retry enabling scanning after the
> initial probe? If a DMI quirk is the right mechanism here, I am happy
> to test patches and provide any further data needed.
We could keep the current 200 ms attempt and if it fails retry a few times.

Could you apply the patch below against a mainline tree and test it?

Thanks,
Lovekesh

diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index b9ad2381f885..81df4b7a5685 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -714,12 +714,28 @@ static inline void atkbd_disable(struct atkbd *atkbd)
 static int atkbd_activate(struct atkbd *atkbd)
 {
 	struct ps2dev *ps2dev = &atkbd->ps2dev;
+	int error;
 
 /*
  * Enable the keyboard to receive keystrokes.
  */
+
+	error = ps2_command(ps2dev, NULL, ATKBD_CMD_ENABLE);
+	if (!error)
+		return 0;
+
+	ps2_begin_command(ps2dev);
+
+	for(int i = 0; i < 3; i++) {
+		error = ps2_sendbyte(ps2dev, ATKBD_CMD_ENABLE & 0xff, 1000);
+		if (!error) {
+			break;
+		}
+	}
+	ps2_end_command(ps2dev);
+
 
-	if (ps2_command(ps2dev, NULL, ATKBD_CMD_ENABLE)) {
+	if (error) {
 		dev_err(&ps2dev->serio->dev,
 			"Failed to enable keyboard on %s\n",
 			ps2dev->serio->phys);
-- 
2.55.0