Heads-up: XPS 16 DA16260 built-in keyboard drops keystrokes (Dell firmware issue, not Omarchy)

[zoan37]

If your XPS 16 (DA16260, Panther Lake) on Omarchy seems to miss letters or spaces, or types them out of order, this is probably the XPS 16's built-in keyboard, not Omarchy or Hyprland.

System: XPS 16 DA16260, Omarchy 4.0.4, Hyprland 0.56.2, kernel 7.2.5-3-omarchy, libinput 1.31.3

What's happening

Dell has a support article for this exact issue: 000435203, "Laptop Keyboard Mistyping When Typed Quickly". It lists the DA16260 and says BIOS 1.4.1 fixes it. On my machine it still happens on BIOS 1.10.1, and on the latest BIOS, 1.11.0 (09 Sep 2026).

The keyboard's controller stops reporting for about 100–400ms and then sends only its current state. In libinput debug-events, that shows up as a key that seems to be held far too long, followed by a release and the next press in the same millisecond. Keys pressed during that gap are lost, and the long "hold" can set off key repeat (qqqqqqq).

How to check yours

sudo libinput debug-events --show-keycodes

Slide one finger across q w e r t y u i o p in about 0.7s, 10 or more times. Each swipe should show all 10 keys in order.

Keyboard	Complete swipes
XPS 16 built-in, BIOS 1.10.1	0 / 7
XPS 16 built-in, BIOS 1.11.0	9 / 19
External Dell USB keyboard on the same XPS 16	11 / 11
XPS 13 on Omarchy	6 / 6

The external keyboard is perfect on the same laptop, BIOS, and OS, so this is the built-in keyboard (the keyboard or its controller firmware). The Omarchy configuration isn't involved. I've opened a Dell support case. If you're affected, it's worth doing the same so Dell sees more reports.

Things I ruled out: key repeat settings (they only affect held keys), Hyprland config, tap-to-click, and key remappers (fcitx5's virtual keyboard doesn't hide keys from libinput, unlike the Makima case in #5071).

Updating the BIOS from Omarchy: LVFS only has 1.9.0 for this model. To get 1.11.0, download the .exe from Dell, copy it to a FAT32 USB stick, and use F12 → BIOS Flash Update. The F12 menu kept closing before I could use it until I ran systemctl reboot --firmware-setup, set Extend BIOS POST Time to 10 seconds, and kept my hands off the keyboard and touchpad once "Preparing one-time boot menu" appeared.

[zoan37]

Update: much rarer now, but not fixed (still BIOS 1.11.0)

Dell support asked me to test the keyboard inside the BIOS setup screen, so I fully powered off and booted straight into BIOS (F2). After that, the drops became much rarer on the same BIOS 1.11.0:

	Complete swipes
Before (BIOS 1.11.0, from the post above)	9 / 19
Tonight, over 5 boots (2 full power-offs, 2 restarts, 1 suspend/resume)	171 / 173

Both failures tonight had the same signature as before. For example, T appeared held for 94ms, then "T released" and "I pressed" arrived in the same millisecond, and Y and U were lost. So the bug is still there, just about 1 in 85 swipes instead of about 1 in 2.

What didn't clearly matter: deep CPU sleep states (C6S and C10 disabled vs enabled), charger vs battery, suspend/resume, or a normal restart vs a full power-off. For a while, "full power-off clears it, restart brings it back" looked plausible, but a second restart was clean for 54 swipes, so that didn't hold up.

If you're affected: after flashing the BIOS, it may be worth doing one full shutdown (not a restart) and then retesting. I can't prove that's what helped, but it's free to try.

I'm keeping the Dell case open, since their article says this was fixed in BIOS 1.4.1.