[Bug 221383] ideapad_laptop: Fn hotkeys stop emitting after s2idle resume on IdeaPad Slim 3 14ARP10 (Ryzen 7735HS)

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221383

--- Comment #23 from Daniel Gibson (metalcaedes@gmail.com) ---
Some more observations:

- `cat /proc/acpi/button/lid/LID/state` always returns the correct state, so it
seems like the lid switch still works and can be queried after suspend, it just
doesn't seem to send events anymore
- When pressing capslock on an external keyboard, usually the internal
keyboards LED is adjusted accordingly and dmesg tells me that the expected
bytes are sent and received by i8042: ed -> i8042 (command for setting LEDs);
fa <- i8042 (ACK); 04 -> i8042 (parameter of the command, bits for set LEDs);
fa <- i8042 (ACK)
- Pressing a key on the internal keyboard still wakes the machine from suspend,
even if the the keyboard otherwise doesn't work. Even for a second suspend
where the keyboard was already broken when suspending.

Maybe pressing a key (or operating the lid switch) just doesn't send an
interrupt anymore after suspend, despite otherwise working? 
This seems to be the case for the lid switch, no idea if the keys do anything
internally, so for that part it's more of a theory.

Furthermore: I can make the "Failed to deactivate keyboard on isa0060/serio0"
message often go away by making __ps2_command() in drivers/input/serio/libps2.c
use higher timeouts for 0x00f5 (ATKBD_CMD_RESET_DIS), like it already does for
PS2_CMD_RESET_BAT. But that doesn't change the fact that the keyboard doesn't
work after resume.
When the `ps2_do_sendbyte(ps2dev, command & 0xff, timeout, 2);` call in that
function fails, it returns -5 (-EIO); I think the problem is that no ACK (0xfa)
was received within the timeout.

So it seems like after resume the i8042 interrupt handler is only called for
direct replies to commands sent to the keyboard (I think I've only seen ACKs)
and even then it:
- sometimes is later than expected
- sometimes lacks data ("[  363.566845] i8042: [363145] Interrupt 1, without
any data") 
- sometimes is missing entirely (no ACK at all after a command) 


By the way, there are several reports of similar/related issues, some of them
resolved, see also https://bugzilla.kernel.org/show_bug.cgi?id=221217#c2

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.