Keys stick and repeat after being released

I have a brand new Framework 16 with the clear RGB keyboard. Sometimes the enter key, or another key, will just act as if it’s being held down, instead of released. I’ll press and release the key, but then the computer interprets that as the key being held down. I’ll press “d,” for example, then release the key, and then a moment later see “ddddddddddd” repeated in a text box—or worse, if I’m using Vim, I’ll see all my lines deleted. The Enter key also sticks this way, as do a few others. If it makes any difference, I’m using NixOS.

This is rather worrying. How can I fix it?

First line of defense against weird Framework glitches: reset the motherboard, and maybe the BIOS (as described there as well). That may well solve the problem. Please let us know whether it does or not.

If it doesn’t, you can try reseating the keyboard. It’s possible that some of the pins simply aren’t making good contact.

If that doesn’t do it either, I’d recommend contacting Framework’s support team.

Some of the keyboard pins breaking contact when this happens would be my guess.

You press the key, it sends the keydown event, then the full force of your keypress bottoms out the key, the keyboard deforms enough to break pin contact, and the keyup event isn’t received.

Framework posted, somewhere, a fix they were testing to reduce the keyboard flex while typing. Adding pads to certain spots under the input deck. I remember Framework posting a picture of the pad locations they were testing.

Resetting the motherboard doesn’t seem to have helped. Nor did reseating the keyboard. This is a really worrying bug, since repeating keys like “dddddddd” have the effect of deleting all my emails, deleting all my browser tabs, or worse. The delete key was stuck recently and it trashed all the directories in my home directory. I really hope there’s a fix for this soon.

Have you used powertop --auto-tune or something similar for power management that turns on USB autosuspend for the keyboard? This will cause the symptom you are describing.

If not, when the problem occurs, does removing an expansion card fix it? If so, I think it is a firmware bug, since it happens even in the BIOS and has been seen by many people over time across many FW models.

Hi,

I have the same problem with missed keys and auto key repeats.
The best guess as to the cause is key codes being lost in transit between key press and cpu.
To diagnose where the codes are being lost one needs:

  1. the circuit diagram of all the schematic between the keyboard and cpu
  2. the protocols used in any software / hardware along that path.

With the above information one could establish where keycodes might be lost, and whether error correction/retransmission are used on the path.

The fix would then be maybe to add error correction/retransmission to the software/protocols.

Do we have any documentation covering the above?

For me, the problem is intermittent. I go from all keypresses OK for a while and then back to many of them lost.

For some ideas to investigate, this thread has some. It is related to a similar problem, just not on the FW laptop.
https://forum.odroid.com/viewtopic.php?f=112&t=7641&sid=5a966859f8af7d00c955716ed5983513&start=50

Some of the ideas from that thread:

  1. Wifi interference
  2. Problem happens when there are a lot of interrupts. Bugs in USB driver causing interrupt storm.
  3. More likely when the CPU is idle, so setting “performance” governor may help.
  4. USB split transactions
    USB Made Simple - Part 7

Split transactions form a high speed only protocol between host controllers and high speed hubs, which are handling full or low speed traffic. This is the means by which the full or low speed traffic is prevented from degrading the high speed bus performance. Each high speed hub is required to have a ‘Transaction Translator’ which handles the full or low speed transactions to particular ports.

My understanding of the USB HID protocol for keyboards is that the host sends a Interrupt_urb:submit then just waits, and the keyboard responds with an interrupt_urb:complete when the user presses a key. the host then sends another interrupt_urb:submit then just waits again.
The complete message has the equivalent of a keycode in it.
So, this is not a reliable protocol. There is no acknowledgement that the host has received the keycode.

This might be related to this thread:

Something that might help a bit.
Disable key autorepeat:
xset r off
Enable key autorepeat
xset r on

By switching it off, it should stop the repeat aspect, but won’t help with the missed keys

Have you used powertop --auto-tune or something similar for power management that turns on USB autosuspend for the keyboard? This will cause the symptom you are describing.

I haven’t, but maybe there’s a power setting somewhere in the NixOS config. Gnome apparently has its own power configuration. I can try to turn off the power configurations, but that will mean the battery life will suffer. I’d like to find a solution which helps to preserve battery life, while not interfering with the keyboard.

If not, when the problem occurs, does removing an expansion card fix it? If so, I think it is a firmware bug, since it happens even in the BIOS and has been seen by many people over time across many FW models.

I’m not sure which expansion card I’m supposed to remove, or how many, but so far this doesn’t seem to have affected anything.

I haven’t, but maybe there’s a power setting somewhere in the NixOS config. Gnome apparently has its own power configuration.

If you cat /sys/bus/usb/devices/{keyboard device}/power/control and it says auto then autosuspend was enabled by something. on means autosuspend is not enabled. (ref) If it says it is not enabled, then this is not your problem.

I’m not sure which expansion card I’m supposed to remove, or how many, but so far this doesn’t seem to have affected anything.

When I had a similar experience to you, it was resolved immediately by removing a DP card, and another time by removing a USB-A card. If it doesn’t resolve that way, then probably your problem is something else.

If neither of these things work then I guess you could try to examine traffic on the USB bus to see if you can see something weird, but at that point I would guess that either you live with an invisible cat or there is a hardware defect.

Hi,
You said removing a dp or usb-a card helped.
That is a interesting observation.
It points a new potential cause of the problem. It might be the usb driver software getting into an unexpected state, so removing a card might change that state thus curing the problem. In order to track this down one would need:

  1. list of what device was plugged into which slot when the problem occurred. E.g. usb-a in slot X. Etc.
  2. were the devices present at boot time or added afterwards
  3. which card one removed from which slot that cured the problem.
  4. Operating System, Windows(version), Linux (Distro)

Then others might be able to reproduce the problem.