Comment 145 for bug 124406

>Has anyone tried creating a custom kernel with a faster interrupt timer?

Even if that reduced the frequency of the problem, the underlying kernel bug would still be present. The kernel must have enough state to know that the key is up (else it would generate repeat events), but is not passing the key-up event along through the /dev/input/event* devices.

There are a number of different issues here.

I saw this problem in both gutsy and hardy -- rare incidents of control+key resulting in the key being stuck down until the next keypress. pauls saw it only in hardy. Harvey gets the same behavior on identical hardware as me (inspiron 1420). Harvey also mentioned what I would guess would be an unrelated type of behavior (behavior of fn+f10, which is not timing-dependent and reproducible 100% of the time). Finally, there are the "locked keys until X server reboot" and the "scheduler bug that clears up after a few seconds" people.

(Harvey, can you please log od -x output from /dev/input/event(the event device for the keyboard), as I did, and try to repro the problem? Your "repeat.key" log shows xev output, which I would expect to not be able to differentiate between things -- the input system is what feeds xorg, and the problem is already present at that point.)

I should really split what Harvey and I are seeing off into a new bug, just to reduce the number of similar issues being thrown into this one...