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.
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.
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.
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:
the circuit diagram of all the schematic between the keyboard and cpu
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.
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.
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:
list of what device was plugged into which slot when the problem occurred. E.g. usb-a in slot X. Etc.
were the devices present at boot time or added afterwards
which card one removed from which slot that cured the problem.
Operating System, Windows(version), Linux (Distro)
Then others might be able to reproduce the problem.
I was finally able to fix this by disabling powertop and power-related settings in NixOS. Unfortunately this means that my battery life is now not quite as good, but at least I don’t have keyboard issues any more.
I was able to reproduce the problem with this combination on a FW16, Linux Ubuntu 24.04:
Slot 1: USB-C nothing plugged in.
Slot 2: USB-C nothing plugged in.
Slot 3: USB-C nothing plugged in.
Slot 4: USB-C FW 180W Power brick plugged in.
Slot 5: Ethernet cable plugged in.
Slot 6: USB-A nothing plugged in.
powertop set to all good, none bad.
Wifi is off.
Relatively busy network with many file transfers running (a backup running)
So, the “powertop” seems to be a common factor.
I cannot reproduce the problem with powertop alone, so I think a busy ethernet cabled network connection might contribute to being able to reproduce the problem.
If I stop using powertop, I cannot then reproduce the problem.