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.
@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?
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.
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.
