Bug 12509 - input-kbd: shift key doesn't work if pressed very quickly after certain letters
Summary: input-kbd: shift key doesn't work if pressed very quickly after certain letters
Status: RESOLVED DUPLICATE of bug 12858
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/Keyboard (show other bugs)
Version: 7.3 (2007.09)
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-21 03:23 UTC by Brice Goglin
Modified: 2007-10-20 03:48 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (42.68 KB, text/plain)
2007-09-21 10:00 UTC, Martin Pärtel
no flags Details
xorg.conf (4.00 KB, text/plain)
2007-09-21 10:01 UTC, Martin Pärtel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brice Goglin 2007-09-21 03:23:14 UTC
Reported by Martin Pärtel in the Debian BTS after upgrading to Xorg 7.3. He says:

After the recent big Xorg update, I started getting mysterious failures while
typing quickly a password, which contains the sequence "xA". It turned out 
that if I start holding down left shift very quickly after typing "x", the 
following characters will not be uppercase. This also works with the letters 
z, c, and v but not, for example, b.

Everything works fine outside X, and used to work before the upgrade to Xorg 
7.3. Only the left shift key is affected.

The bug can be seen in xev. When I press and release "x" quickly, then quickly
press and hold shift, the shift event takes a moment (0.5-1 sec) to register.
If I press "a" while holding the shift key before the shift event registers,
it will register as a lowercase "a" and the shift event will not arrive at all
before I release the shift. If I try the same with e.g. "b", then the shift 
event registers immediately.

This is on a ThinkPad T60, whose keyboard the KDE control center
indentifies as "IBM ThinkPad S60Z/600/600E/A22E, Intl".
KDE's "Enable keyboard layouts" option is off, however.

The relevant section in xorg.conf:
Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "kbd"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xorg"
        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "ee"
EndSection

Changing layouts or models doesn't help.
Comment 1 Martin Pärtel 2007-09-21 10:00:48 UTC
Created attachment 11667 [details]
Xorg log
Comment 2 Martin Pärtel 2007-09-21 10:01:13 UTC
Created attachment 11668 [details]
xorg.conf
Comment 3 Sami Liedes 2007-09-24 08:48:51 UTC
I can reproduce this on my Debian sid amd64 non-smp desktop. The same update seems to have broken the keyboard leds (might be something related?): Num lock, caps lock and scroll lock leds stay off, no matter what. In the console, those leds still work.
Comment 4 Bernhard Bliem 2007-09-29 05:35:42 UTC
(In reply to comment #3)
> I can reproduce this on my Debian sid amd64 non-smp desktop. The same update
> seems to have broken the keyboard leds (might be something related?): Num lock,
> caps lock and scroll lock leds stay off, no matter what. In the console, those
> leds still work.
> 

I can confirm that on my 32 bit Athlon XP machine with Debian sid. I use the Dvorak keyboard layout and it happens with the Keys ;, q, j and k, which are located at the same position as z, x, c and v on the US layout, as the original poster stated.
Comment 5 Jonathan Schleifer 2007-09-29 06:16:04 UTC
I can reproduce this. Another key affected by this bug is the slash key.
Btw, the keyboard layout doesn't matter, therefore it's keycode related.
Comment 6 Bernhard Bliem 2007-09-29 09:45:05 UTC
Oh, and by the way it only happens if the left shift key is pressed before z, x, c, v, or any other affecte key is released. Once that key is released it works normally.
Comment 7 Sami Liedes 2007-09-29 16:13:32 UTC
Yes, that seems to be the issue: Press the equivalent of v on the qwerty layout, then quickly press and hold shift, release v, and X acts if I don't hold shift down (as long as I hold the shift down, so it's not timing related).
Comment 8 Wouter Van Hemel 2007-10-10 17:13:45 UTC
That last combination, v and x, doesn't work for me either (x is lower case instead of correctly upper case), but I need to type quite fast.

Leds are not working.
Comment 9 martin f. krafft 2007-10-12 02:51:04 UTC
Also see http://lists.freedesktop.org/archives/xorg/2007-October/029115.html and the following xev output. Note how the shift key action registers only after the d key release:

KeyPress event, serial 29, synthetic NO, window 0x4200001,
    root 0x5c, subw 0x0, time 1288285946, (104,90), root:(1622,108),
    state 0x10, keycode 51 (keysym 0x5c, backslash), same_screen YES,
    XLookupString gives 1 bytes: (5c) "\"
    XmbLookupString gives 1 bytes: (5c) "\"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x4200001,
    root 0x5c, subw 0x0, time 1288285995, (104,90), root:(1622,108),
    state 0x10, keycode 51 (keysym 0x5c, backslash), same_screen YES,
    XLookupString gives 1 bytes: (5c) "\"
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x4200001,
    root 0x5c, subw 0x0, time 1288286060, (104,90), root:(1622,108),
    state 0x10, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x4200001,
    root 0x5c, subw 0x0, time 1288286122, (104,90), root:(1622,108),
    state 0x10, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyPress event, serial 32, synthetic NO, window 0x4200001,
    root 0x5c, subw 0x0, time 1288286154, (104,90), root:(1622,108),
    state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x4200001,
    root 0x5c, subw 0x0, time 1288286154, (104,90), root:(1622,108),
    state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 10 Jürg Billeter 2007-10-19 05:35:11 UTC
The patch in bug 12858 seems to fix the issue here.
Comment 11 Samuel Tardieu 2007-10-20 03:48:54 UTC
I confirm that issue #12858 proposed fix works fine for the problem exposed here.

*** This bug has been marked as a duplicate of bug 12858 ***


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.