I've got a USB magnetic card reader that emulates a USB HID-based keyboard. In MS Windows and the Linux console, it works perfectly. In X (any program) it sporadically "unshifts" characters. For example, if the expected input is "%DAVID?" I'd get something like: "5DAvID?", or perhaps "%DAViD/", or some other combination. The device can have it's USB polling interval adjusted. When I change it from 1ms to 5ms, things improve, but still aren't perfect. I've tried up to 16ms and it still fails. As this is essentially an inter-character delay, higher values defeat the point of a card swipe. I'm guessing this bug affects all USB keyboards, it's just that most people don't type shifted characters fast enough to notice. From a quick test with 1130 total characters: of 230 characters that should have been shifted characters, 50 were not (~20%). I will gladly ship/loan the hardware to anyone in a position to fix the bug and are unable to reproduce it. Also, my email address is real, it's just disposable.
Created attachment 2614 [details] [review] Patch that corrects problem I'm completely new to hacking X, so all I can say is that it seems to work for me. The problem is that the kbd driver looks for two key-pressed keycodes without a key-release keycode between them. It then discards these for certain keys (shift,control,alt, etc.) if they're irrelevant autorepeats. The old code used the KeyPressed() macro to determine whether a "down" keycode had arrived for a key that was already down, but this macro uses data that isn't updated until the event queue is processed. As a result, very rapid keypresses might cause a new "down" to be seen before an older "up" gets processed (a race condition). The magswipe sends an explicit "shift down" and "shift up" before and after each shifted character, triggering the failure. To correct this, the key state information is handled via a static local variable instead of the structure managed by the event handler.
i'll take this one.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
This has sense radically changed. If things don't work with the new keyboard driver or evdev, please reopen.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.