| Summary: | input-kbd: shift key doesn't work if pressed very quickly after certain letters | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Brice Goglin <brice.goglin> | ||||||
| Component: | Input/Keyboard | Assignee: | Xorg Project Team <xorg-team> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | bugs.freedesktop.org, sam, sliedes, wouter-freedesktop | ||||||
| Version: | 7.3 (2007.09) | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443250 | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 11667 [details]
Xorg log
Created attachment 11668 [details]
xorg.conf
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. (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. 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. 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. 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). 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. 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 The patch in bug 12858 seems to fix the issue here. 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.
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.