Bug 1542 - Characters losing their shiftedness when input rapidly
Summary: Characters losing their shiftedness when input rapidly
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/Keyboard (show other bugs)
Version: 6.7.0
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Adam Jackson
QA Contact: Xorg Project Team
Keywords: patch
Depends on:
Reported: 2004-10-05 13:45 UTC by David
Modified: 2011-10-17 03:29 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Patch that corrects problem (1.32 KB, patch)
2005-05-03 09:11 UTC, David
no flags Details | Splinter Review

Description David 2004-10-05 13:45:24 UTC
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.
Comment 1 David 2005-05-03 09:11:10 UTC
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

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.
Comment 2 Adam Jackson 2005-05-06 12:22:38 UTC
i'll take this one.
Comment 3 Daniel Stone 2007-02-27 01:24:17 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 4 Jeremy Huddleston Sequoia 2011-10-17 03:29:00 UTC
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.