On Wed, 7 May 2025 12:44:24 +0100
"Russell King (Oracle)" [off-list ref] wrote:

Hi Maxime,

On Wed, May 07, 2025 at 03:32:36PM +0200, Maxime Chevallier wrote:

quoted

Hi Russell,

On Wed, 7 May 2025 10:59:21 +0100
"Russell King (Oracle)" [off-list ref] wrote:
  

quoted

On Wed, May 07, 2025 at 10:23:17AM +0100, Russell King (Oracle) wrote:  

quoted

[Sorry for going off topic here - changed the Cc list, added Linus,
changed the subject.]

On Wed, May 07, 2025 at 10:54:57AM +0200, Maxime Chevallier wrote:    

quoted

On Wed, 7 May 2025 09:31:48 +0100
"Russell King (Oracle)" [off-list ref] wrote:    

quoted

[rest of the email got deleted because Linux / X11 / KDE got confused
about the state the backspace key and decided it was going to be
continuously pressed and doing nothing except shutting the laptop
down would stop it.]    

Funny how I have the same exact issue on my laptop as well...     

I've had the "stuck key" behaviour with the HP Pavilion 15-au185sa
laptop I had previously (normally with ctrl-F keys). However, hitting
ctrl/shift/alt would stop it.

This is the first time I've seen the behaviour with the Carbon X1
laptop, but this was way more severe. No key would stop it. Trying to
move the focus using the trackpad/nipple had any effect. Meanwhile
the email was being deleted one character at a time. So I shut the
laptop lid causing it to suspend, and wondered what to do... on
re-opening the laptop, it didn't restart and is back to normal.

This suggests that the entire input subsystem in the software stack
collapsed just after the backspace key was pressed, and Xorg never
saw the key-release event. So Xorg duitifully did its key-repeat
processing, causing the email to be deleted one character at a time.

The problem is, not only did this destroy the email reply, but it
also destroyed my train of thought for the reply as well through
the panic of trying to stop the entire email being deleted.

I don't think this is a hardware issue - I think there's a problem
in the input handling somewhere in the stack of kernel, Xorg,
whatever multiple input libraries make up modern systems, and KDE.

I did check the logs. Nothing in the kernel messages that suggests
a problem. Nothing in Xorg's logs (which are difficult to tie up
because it doesn't use real timestamps that one can relate to real
time.) There's no longer any ~/.xsession-errors logfile for logging
the stuff below Xorg.

I'm running Debian Stable here - kernel 6.1.0-34-amd64, X.Org X Server
1.21.1.7, KDE Plasma (5.27.5, frameworks 5.103.0, QT 5.15.8).    

I'll also add that The Carbon X1, being a laptop, its built-in keyboard
uses the i8042:

[    1.698156] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
[    1.698543] i8042: Warning: Keylock active
[    1.700170] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.700174] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.700271] mousedev: PS/2 mouse device common for all mice
[    1.702951] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

I don't have the HP laptop with me to check what that was using.

The mysterious thing is "Keylock active" - clearly it isn't because I
can write this email typing on that very keyboard. However, I wonder
if it needs i8042_unlock=1 to set I8042_CTR_IGNKEYLOCK.

Unfortunately, it's probably going to take a year on the Carbon X1
to work out if this makes any difference.
 

quoted

Anyone else seeing this kind of behaviour - if so, what are you
using?  

It just happened to me as I was typing this very email (key 'd' got
stuck, nothing could un-stick it, couldn't move the mouse cursor but
mouse-click events did work, had to suspend/resume the laptop to fix
that)  

'd' can be quite disastrous if you're using vi and you're in command
mode!

quoted

Got the same "Keylock active" warning at boot :

[    0.916750] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    0.917210] i8042: Warning: Keylock active
[    0.920087] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.920090] serio: i8042 AUX port at 0x60,0x64 irq 12

Nothing in the kernel logs when the key got stuck.

Laptop is a Dell XPS 15 9510, Running Fedora 41 but I saw this issue
before, kernel 6.14.4-200.fc41.x86_64, Wayland-based, Gnome 47.

Hopefully this helps a bit narrowing this down, I have a fairly
different userspace stack and kernel version, but we do have the same
driver involved and same keylock warning...  

Could you try booting with i8042_unlock=1 and see whether that makes any
difference please?

I'll try this out indeed :)

I've added that to my grub config in preparation for rebooting, but even
if I booted now, I suspect it'll be some time before I have any useful
result.

How often do you see the problem?

It's very sporadic, sometimes I'll see this behaviour multiple times a
day, and then nothing for weeks... This laptop has been very quirky
ever since I got it, so I categorized that as a "yet another XPS 9510
broken behaviour", but this has been a recurrent thing for multiple
years...

So, same as you, it'll take a long time for me to say with some amount
of certainty that 'i8042_unlock=1' has a beneficial effect, of
course unless I see the problem happen again in the meantime.

Maxime