Del key behaves incorrectly after suspend&wake-up

This is a really bizarre bug that recently started happening:

When I boot my laptop, the del key works correctly. However, when I suspend the laptop and wake up again, the key gets mapped to power button: meaning that when I press the del key I get the power off logout options.

Changing keyboard layout has no effect. Monitoring key presses with showkey command revealed an interesting behaviour: before suspending, pressing the del key results in a keycode 111 event. After waking up from suspend I get keycode 116 events. Keycode 116 is the keycode for the power button. The power button continues to be mapped to keycode 116 after suspend.

As far as I can see, the del key is the only key that behaves in a weird way, but I haven’t comprehensively checked everything.

Some system info below:

Kernel: 6.10.6-10-MANJARO Desktop: Xfce v: 4.18.1

My lowlevel knowledge is limited - but based on what I do know - buttons sends the same scancode no matter the layout.

The actual layout may differ though the keys are numbered from left to right.

The layout will on the other hand interpret the scancode to a keycode to a printable char depending on the keycode. (in root context

# showkey -s

E.g. on a danish layout the scancode 26 prints å to the console but using and us layout the same keycode prints [.

So your keyboard changing scancode waking up from suspend is really strange - that only happens if the memory is corrupt - something like that.

I suggest you boot a live ISO an run some extensive test on the RAM.

I got some of my info from http://www.osfree.org/docs/cmdref/cmdref.2.0476.php

Other resources https://linux.die.net/man/1/showkey

According to Keyboard input - ArchWiki the most reliable tester is evtest from that package.

@linux-aarhus , I ran with evtest results are below:

before suspend (works correctly)

Event: time 1725799816.283905, type 4 (EV_MSC), code 4 (MSC_SCAN), value d3
Event: time 1725799816.283905, type 1 (EV_KEY), code 111 (KEY_DELETE), value 0

after suspend (thinks its power button)

Event: time 1725799227.207448, type 4 (EV_MSC), code 4 (MSC_SCAN), value d3

Actual power button:

Event: time 1725799328.231334, type 1 (EV_KEY), code 116 (KEY_POWER), value 0

So evtest doesn’t acutally think the del key is the powerbutton, but I have no idea why I get two events before suspend (type 4 and type 1), and only one afterwards (just type 4). Somehow suspend changes the behaviour, which then gets interpreted as power key.

This error is very reproducible. If it was corrupt RAM, would it not be more random?

I don’t know know - perhaps - likely … but again it is stranger than strange - likely because we cannot deduce why.

The only thing that comes to mind is your system firmware playing tricks.

Make your self a note about what you have changed in your firmware - secure boot comes to mind - but most do not change anything else.

Enter the firmware setup and use your firmware’s reset to default entry - see if it changes anything.

Scancode d3 is being correctly mapped to keycode 111. Though it can vary based on the physical keyboard layout. For me d3 also gets mapped to 111, this probably applies to most if not all standard layouts.

The keycode part is missing, but it’s unsurprisingly still scancode d3.

Seems like something is going wrong with the scancode to keycode mapping after suspend. No idea why.

It probably won’t help but what does xev -event keyboard say? The keycode will be different, the correct one will be 119 for xev (it matches 111 in evtest, X adds an offset for some reason, though if I remember correctly some of the lower keycodes aren’t offset) .

You may be able to remap it back to the correct keycode, but it depends on what’s going wrong. :crossed_fingers:

https://wiki.archlinux.org/title/Map_scancodes_to_keycodes
https://wiki.archlinux.org/title/Input_remap_utilities

@linux-aarhus

Slight correction, the keyboard sends scancodes (in this case d3), which are then mapped to keycodes, which are in turn mapped to keysyms.

AFAIK all the mapping happens in the OS, and we’re still getting the correct scancode, so I’m not sure how likely it is to be the firmware. Having said that, I’ve no idea how it could go wrong elsewhere either. :man_shrugging:

I have corrected because the above I referenced is scancodes - the numerical value

Esc = 1
1 = 2
2 = 3

//EDIT - just a random connection
Could it be related to the systemd freeze user sessions on suspend issue?