My DELL is messed up too. I have the MC16255 and my EC does the exact same thing. I will be trying to search something or write an email and the key drifts several characters despite only being pressed once. It has been intervening constantly and I have to reset the workspace environment each time.

Hi

I asked the internet (so it is a possibly a lot of what you have tried already), and.....

1) Quick diagnostics (rule out simple causes)

Run these first to confirm it’s EC/firmware and not debris or accessibility settings:

• If repeat rate/delay look normal and the problem is random (not just when holding a key), it’s not a user setting.

• Test in a TTY (Ctrl+Alt+F3): if keys still repeat/stick there, it’s below the DE (driver/EC/firmware).dell

Also run Dell’s built‑in diagnostics:

• Reboot → tap F12 → choose Diagnostics → let the keyboard test run.
  If the fault appears there too, it strongly points to hardware/EC.dell

2) Update BIOS, EC, and chipset firmware (most effective fix)

Dell fixes many of these EC key‑release bugs via BIOS/EC updates. On your Pro Max (Ryzen AI Pro 7), this is the single most important step.discuss.cachyos

Option A: Dell Command | Update (Linux)

If you have dcu/command-update:  

Or use the GUI if installed.

Option B: Manual BIOS/EC update from Dell

1. Go to: https://www.dell.com/support → enter your Service Tag or model.

2. Download the latest:

   • BIOS Update (often bundles EC firmware)

   • Chipset / AMD Platform drivers (if listed for Linux/UEFI)

3. Create a FAT32 USB stick, copy the BIOS .exe (UEFI capsule) or use Dell’s “BIOS Update from USB” method.

4. Reboot → F12 → BIOS Flash Update → select the file on USB.

After update:

• Enter BIOS → ensure:

  • POST Behaviour → Fastboot = off (temporarily, for stability)

  • Power Management → Wake on AC / USB = off (test)

  • No unusual keyboard options enabled.

Many users with similar “random key repeat until another key pressed” on Dell laptops see this resolved after a BIOS/EC refresh.dell+1

3) Disable problematic power states (s2idle / deep sleep)

Some AMD Dell platforms mis‑handle EC state after S2Idle/suspend, causing key release events to be lost.

Check current sleep mode:

If you see s2idle and the issue appears after suspend:

Temporarily test with suspend disabled

Use hibernate or shutdown instead for a few days. If the problem disappears, it’s sleep‑related.

Force deeper sleep (if supported)

Edit GRUB     sudo nano /etc/default/grub

Add to GRUB_CMDLINE_LINUX_DEFAULT:

Then:sudo update-grub sudo reboot

If deep isn’t available, your firmware may only support s2idle; in that case, minimizing suspend usage until Dell releases a firmware fix is the pragmatic approach.

4) Kernel / input tweaks (workarounds)

If firmware updates don’t fully resolve it, try these Linux‑side mitigations.

a) Increase key debounce / ignore very fast repeats

Create a udev hwdb rule to add a small debounce on the internal keyboard.

Example content (adjust evdev:input:* match as needed; use libinput list to identify):

Then:

This can reduce spurious repeats caused by EC bounce.

b) Use atkbd or libinput parameters (if applicable)

For PS/2‑style embedded keyboards:

Add  

Then reboot.

For libinput, you can tune repeat via desktop settings or gsettings:

These don’t fix EC release failures but can make symptoms less disruptive.ubuntu+2

5) Check dmesg / logs for EC / ACPI errors

Look for EC timeouts, ACPI GPE storms, or keyboard controller errors:

dmesg -T | grep -iE 'ec|acpi|keyboard|atkbd|i8042' journalctl -k | grep -iE 'ec|acpi|keyboard' | tail -n 50

If you see repeated lines like:

• EC: timed out waiting for command

• ACPI Exception: AE_TIME

• i8042: failed to reset keyboard

that strongly indicates an EC/firmware bug. Capture a full log after a bad session and:

• Open a Dell support case with those logs + exact model + kernel version.

• Search Dell community forums for your exact model + “EC key release” or “random key repeat”.dell+1

6) If all else fails: hardware path

If:

• The issue occurs in BIOS diagnostics,

• Persists across multiple Linux kernels and even another OS,

• And BIOS/EC are already latest,

then the internal keyboard or EC hardware may be faulty. In that case:

• Test with an external USB keyboard (if external is fine, internal keyboard/EC is suspect).

• Contact Dell support under warranty for keyboard/EC replacement on the Pro Max chassis.dell+1

Recommended order for you

Given your hardware and skill level:

1. Update BIOS/EC via Dell’s latest package.

2. Test with suspend disabled (systemctl mask systemd-suspend.service) for a few days.

3. If still present, add the debounce hwdb rule and check dmesg for EC/ACPI errors.

4. If diagnostics at F12 also show the fault, push Dell support with logs and request an EC/board fix or replacement.

@anne_droid​ Thanks for the reply!

So I have the latest firmware and bios via the dell command app thing (I boot into Windows on a windows drive for updates).

disabling suspend does somewhat fix the issue, the problem seems to only happen on boot or waking from suspend, it doesn't start mid-session. If suspend is disabled then as long as the boot didn't initialize the bad state then its safe, but then I don't have suspend and power on is still a dice roll on it.

Debounce rules do work, it has to be a full second though, the delay ranges from 600-1000ms. You can still tell the EC is on the fritz because the single key presses have significant delays and it feels like there is a lagged keyboard buffer or something but who knows.

This is one crazy thing, dmesg shows absolutely clean logs, the kernel seems completely unaware any issue is occurring!

Diagnostics are tricky because the problem is super intermittent, our Uni required this model of laptop for the whole class, so all of the students have it, its an engineering school with heavy Linux use and a lot of CS/CompE, and it seems students are experiencing this on average once every 3 to 5 days of consistent use. This is leading to a real reproduction issue in trying to debug. I will try Dells diagnostic next time it occurs on my computer.

Hi 

Daft idea...

Run an OS (like Zorin in VM) using Virtual Machine, just in the background, and see if it functions when the base OS fails on your own machine.

I keep Mint, Debian and Zorin on USB sticks for the day the apocalypse arrives.

Bump. An issue was submitted to the kernel ACPI mailing list. I think this has to be a Dell fix it's more than likely out of the kernel's hands.

@anne_droid​ I did a bit, VMs in GNOME boxes have the same issue if the base image is suffering from it, but hypervisor in windows never seems to have the issue. But then Windows is managing my hardware so battery is terrible, memory is terrible, gpu wont power off, all my data goes to Microsoft and they don't compensate me for it, all the standard complaints about using Windows as a solution.

I should probably mention this issue only occurs on the internal keyboard, usb keyboards are not effected

@Mccalabrese​ 

I got Tiny11 for dual boot and in VM.

NB: The best solution is Sulphuric Acid, as tried by Dr John Haigh circa 1944 - 49.

@anne_droid​ HAHA thats awesome, as soon as I graduate and off the uni's managed windows stuff I'm probably going to do the same