Ubuntu 22.04 infrequent random key sticking on Dell G15 5521, that immediately clears on pressing a different key

Question

Setup:

• Ubuntu 22.04, clean install.
• Dell G15 5521 Laptop
• Latest firmware
• 6.0.8-060008-generic
• Nvidia 525.60.11
• X11 Ubuntu flavour of Gnome

Very randomly and very infrequently (probably once a day for me) a key appears to get stuck and auto-repeats. Pressing any other key stops the auto repeat.

This happens with the default kernel and with 6.0.8.

The problem does not occur on Windows 11. The problem does not occur when running the pre-post keyboard tests (fn key held down when powering on).

The problem occurs on multiple G15 laptops. I have one for work, one for personal use and work has 3 more. All exhibit the same random infrequent problem, but frequently enough to be complained at...

The problem does not always occur when the system is under load. Typing speed does not appear to have any influence on the issue.

dmesg does not show any thing related to keyboard or USB when the issue occurs.

I do not want to turn off key repeat (xset -r).

A bit more information on input devices:

$ xinput list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ DELL0B56:00 06CB:CE81 Mouse               id=10   [slave  pointer  (2)]
⎜   ↳ DELL0B56:00 06CB:CE81 Touchpad            id=11   [slave  pointer  (2)]
⎜   ↳ PS/2 Generic Mouse                        id=17   [slave  pointer  (2)]
⎜   ↳ Logitech MX Ergo Multi-Device Trackball   id=18   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Video Bus                                 id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Integrated_Webcam_HD: Integrate           id=9    [slave  keyboard (3)]
    ↳ Intel HID 5 button array                  id=12   [slave  keyboard (3)]
    ↳ Intel HID events                          id=13   [slave  keyboard (3)]
    ↳ Dell Privacy Driver                       id=14   [slave  keyboard (3)]
    ↳ Dell WMI hotkeys                          id=15   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=16   [slave  keyboard (3)]
$ uname -a
Linux Dell-G15-Special-Edition-5521 6.0.8-060008-generic #202211101901 SMP PREEMPT_DYNAMIC Thu Nov 10 20:44:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Is there anything I can try to narrow down where this problem is occurring?

I have looked at numerous different posts and questions but the advice is limited.

Edit 20 September 2023

We now have 8 of the Dell G15's, all up to date. All have the same issue.

The problem does not occur when running Windows.

Answer 1

EDIT 09/02/2024: while I'm waiting for my Thinkpad to arrive, I have limited the C-states to C2 with intel_idle.max_cstate=2 kernel option (set in grub configuration). So far no issues with keyboard...

EDIT 18/01/2024: Since I found out that hw interrupts for key-release are being delayed I have tried a couple of things:

• remove irqbalance service from my environment
• dedicate a single core only to keyboard interrupt handling
• bonus: got a bios update (1.11.0) that bumped the Embedded Controller fw revision

Unfortunately none of those changes helped.

EDIT 09/01/2024: I have confirmed that the hw interrupt is missing for the key-release

Jan  9 13:31:50 atoppi kernel: [ 9452.070032] i8042: [2362855] 1c <- i8042 (interrupt, 0, 1)
Jan  9 13:31:50 atoppi kernel: [ 9452.205121] i8042: [2362889] 9c <- i8042 (interrupt, 0, 1)
Jan  9 13:31:52 atoppi kernel: [ 9453.842970] i8042: [2363298] 1c <- i8042 (interrupt, 0, 1)
Jan  9 13:31:52 atoppi kernel: [ 9453.935991] i8042: [2363322] 9c <- i8042 (interrupt, 0, 1)
Jan  9 13:31:53 atoppi kernel: [ 9454.655751] i8042: [2363502] 1c <- i8042 (interrupt, 0, 1)
here is missing the "9c" (aka ENTER key release)
from this moment ENTER key is stuck
Jan  9 13:32:06 atoppi kernel: [ 9468.085395] i8042: [2366859] e0 <- i8042 (interrupt, 0, 1)
Jan  9 13:32:06 atoppi kernel: [ 9468.085590] i8042: [2366859] 2a <- i8042 (interrupt, 0, 1)
Jan  9 13:32:06 atoppi kernel: [ 9468.085760] i8042: [2366859] e0 <- i8042 (interrupt, 0, 1)
Jan  9 13:32:06 atoppi kernel: [ 9468.085946] i8042: [2366859] 48 <- i8042 (interrupt, 0, 1)
"9c" arrives after pressing other keys
Jan  9 13:32:06 atoppi kernel: [ 9468.098398] i8042: [2366862] 9c <- i8042 (interrupt, 0, 1)

EDIT 26/12/2023: I have tested almost all the parameters of the i8042 driver (the one that handles ps/2 interface for keyboard), but the issue still persists. At this point either the Linux driver is buggy or the hw controller is, imho the latter is more likely. Probably a firmware update might solve, but good luck trying to explain the issue to the dumb Dell support.

Im trashing this garbage laptop, moving to a Thinkpad and never looking back to Dell anymore.

EDIT 20/12/2023: I was writing the word "room" while tracing the events with evtest. Suddenly the second "o" got stuck on the keyboard, so I stopped the repeating loop with an "a".

I discovered that the issue is due to a delayed "KeyRelease" event from the kernel

Event: time 1703089559.564161, type 4 (EV_MSC), code 4 (MSC_SCAN), value 13
Event: time 1703089559.564161, type 1 (EV_KEY), code 19 (KEY_R), value 1
Event: time 1703089559.564161, -------------- SYN_REPORT ------------
Event: time 1703089559.692291, type 4 (EV_MSC), code 4 (MSC_SCAN), value 13
Event: time 1703089559.692291, type 1 (EV_KEY), code 19 (KEY_R), value 0
Event: time 1703089559.692291, -------------- SYN_REPORT ------------
Event: time 1703089560.008009, type 4 (EV_MSC), code 4 (MSC_SCAN), value 18
Event: time 1703089560.008009, type 1 (EV_KEY), code 24 (KEY_O), value 1
Event: time 1703089560.008009, -------------- SYN_REPORT ------------
Event: time 1703089560.126559, type 4 (EV_MSC), code 4 (MSC_SCAN), value 18
Event: time 1703089560.126559, type 1 (EV_KEY), code 24 (KEY_O), value 0
Event: time 1703089560.126559, -------------- SYN_REPORT ------------
Event: time 1703089560.618210, type 4 (EV_MSC), code 4 (MSC_SCAN), value 18
Event: time 1703089560.618210, type 1 (EV_KEY), code 24 (KEY_O), value 1
Event: time 1703089560.618210, -------------- SYN_REPORT ------------
Event: time 1703089564.805921, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e
Event: time 1703089564.805921, type 1 (EV_KEY), code 30 (KEY_A), value 1
Event: time 1703089564.805921, -------------- SYN_REPORT ------------
Event: time 1703089564.818837, type 4 (EV_MSC), code 4 (MSC_SCAN), value 18
Event: time 1703089564.818837, type 1 (EV_KEY), code 24 (KEY_O), value 0
Event: time 1703089564.818837, -------------- SYN_REPORT ------------
Event: time 1703089564.870330, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1e
Event: time 1703089564.870330, type 1 (EV_KEY), code 30 (KEY_A), value 0
Event: time 1703089564.870330, -------------- SYN_REPORT ------------

Notice how the second "o" gets released (value 0) only when the letter "a" is pressed (value 1) after 4 seconds.

EDIT: Unfortunately the issue came back after a lot of time, even with the workaround I propose below :-(

I switched to xfce and blacklisted the following kernel modules. The problem still has to represent since then (edited blacklist.conf under /etc/modprobe.d):

blacklist dell_laptop
blacklist dell_wmi
blacklist dell_wmi_sysman
blacklist dell_wmi_ddv
blacklist dell_smbios
blacklist dell_wmi_descriptor

I have not encountered any issue after disabling those modules, all hw devices work and battery is the same as before.

Answer 2

Same here, with a DELL Vostro 15 3510.

You can confirm this is not a notebook keyboard issue by using an external USB keyboard for some time.

It seems this is a Wayland problem, that went away for me when I switched to Xorg. Just select "Ubuntu on Xorg" in the login screen (small gear in the bottom right).

Answer 3

I have the same problem with a Dell Vostro 15 3510 and I created a workaround script. I noticed that whenever I press alt+f4, it fires a lot of press and release events for the same key within a very short span of time.

Some OS info:

$ uname -a
Linux pc 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 23.10
Release:        23.10
Codename:       mantic

I use KDE and X11.

Let's first see the keyboard device id:

$ xinput list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ DELL0AB2:00 27C6:0D43 Mouse               id=8    [slave  pointer  (2)]
⎜   ↳ DELL0AB2:00 27C6:0D43 Touchpad            id=9    [slave  pointer  (2)]
⎜   ↳ PS/2 Generic Mouse                        id=15   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Video Bus                                 id=6    [slave  keyboard (3)]
    ↳ Power Button                              id=7    [slave  keyboard (3)]
    ↳ Intel HID 5 button array                  id=10   [slave  keyboard (3)]
    ↳ Intel HID events                          id=11   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=14   [slave  keyboard (3)]

In this case it's 14:

↳ AT Translated Set 2 keyboard id=14 [slave keyboard (3)]

Then let's see the keys pressed:

key press   64 
key press   70 
key release 64 
key release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey release 70 
key press   70 
^[OSkey press   37 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key release 70 
key press   70 
key press   54 
^C

First I pressed some random keys, then I opened some windows and closed them with alt+f4 (70), then it started to repeat the press and release events of alt+f4.

So, what I did was to detect this behavior and disable and re-enable the keyboard, so that all these events will stop. I know it's totally not an acceptable solution but I couldn't come up with anything else.

First install xdotool:

sudo apt install -y xdotool

Then save this in an .sh file, for example script.sh:

#!/bin/bash
export DISPLAY=":0"
keycode="70"
xinput="/usr/bin/xinput"
xdotool="/usr/bin/xdotool"
keyboard_name='AT Translated Set 2 keyboard'
xinput_keyboard_id=$($xinput list | grep "$keyboard_name" | grep -o 'id=[0-9]+' | cut -d= -f2 | tr -d "\n")
if [ -z $xinput_keyboard_id ]; then
    >&2 echo "Error getting the device xinput id."
    exit 1
fi
release_alt_f4_key() {
    $xinput disable $xinput_keyboard_id
    $xinput enable $xinput_keyboard_id
    sleep 0.1
    $xdotool keyup $keycode
}
$xinput test $xinput_keyboard_id | while read line; do
    line=$(echo $line | tr -d '\r')
    if [[ $line =~ "key press $keycode" ]]; then
        now=$(date +%s.%N)
        if [[ -n "$last_ts" && $(bc <<< "$now - $last_ts < 1") -eq 1 ]] ; then
            release_alt_f4_key
        fi
        last_ts=$now
    fi
done
exit 0

Please notice that you have to change the keyboard_name with your keyboard device name we got before with xinput list.

Then make it executable: chmod u+x script.sh

Then run it: ./script.sh

Or you can run it in background: nohup ./script.sh >/dev/null 2>&1 &

Or you can schedule it to run at each OS startup with crontab -e:

# m h  dom mon dow   command
@reboot sleep 10 && /home/user/script.sh

If you come up with a better solution, please let me know!

Answer 4

I've had this problem for two years as well, this is very annoying. I've searched everywhere, some people seem to indicate this comes from a bad interaction between the touchpad and the keyboard. Unfortunately on this computer the touchpad is i2c and cannot be disabled.

There are still a few things that reduce the occurrence of the problem. Lower system load helps, disabling the sound daemon 'pipewire' for example seems to make it happen less. Unloading the driver in linux still helps a little if you have an external mouse:

rmmod i2c_hid_acpi i2c_hid

The suggestion of limiting the C-states to C2 also helps, but none of those solutions completely fixes the problem.

I was not able to try another OS in this computer.