Bug 1542

Summary:

Characters losing their shiftedness when input rapidly

Product:

xorg

Reporter:

David <spam747>

Component:

Input/Keyboard

Assignee:

Adam Jackson <ajax>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

high

Keywords:

patch

Version:

6.7.0

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Patch that corrects problem	none

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
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.

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.