Bug 112217 - Left shift key stops working with auto-repeat
Left shift key stops working with auto-repeat
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-16 06:33 EST by Chris Underhill
Modified: 2007-04-18 13:00 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-22 08:43:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Underhill 2003-12-16 06:33:23 EST
Description of problem:
The XFree keyboard driver appears to report bogus key press/release
events with the left shift key, causing it to cease capitalising typed
characters etc. Snipped output from xev shows:

KeyPress event, serial 23, synthetic NO, window 0x3000001,
    root 0x58, subw 0x0, time 324529369, (89,60), root:(441,478),
    state 0x1, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes:  "A"
                                                                     
             
KeyRelease event, serial 23, synthetic NO, window 0x3000001,
    root 0x58, subw 0x0, time 324529483, (89,60), root:(441,478),
    state 0x1, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes:  "A"
                                                                     
             
KeyRelease event, serial 23, synthetic NO, window 0x3000001,
    root 0x58, subw 0x0, time 324529516, (89,60), root:(441,478),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:  ""
                                                                     
             
KeyPress event, serial 23, synthetic NO, window 0x3000001,
    root 0x58, subw 0x0, time 324529516, (89,60), root:(441,478),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:  ""
                                                                     
             
KeyRelease event, serial 23, synthetic NO, window 0x3000001,
    root 0x58, subw 0x0, time 324529516, (89,60), root:(441,478),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:  ""
                                                                     
             
KeyPress event, serial 23, synthetic NO, window 0x3000001,
    root 0x58, subw 0x0, time 324529653, (89,60), root:(441,478),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes:  "a"
                                                                     
             


Version-Release number of selected component (if applicable):
XFree86-4.3.0-2.90.43

How reproducible:
Always

Steps to Reproduce:
1. In X application, hold down the left shift key
2. Press another key and keep holding down both for a few seconds
3. View output
    

Actual Results:  If key pressed was an A, then I see something like:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaa

Number of characters before case shift is seemingly random

Expected Results:  I should just see upper case A's

Additional info:

Tried swapping keyboards with no change in output. In console mode,
the capitalisation works fine so I don't believe this to be a hardware
problem. This keyboard also worked fine with Red Hat 7.3.

Video card is a dual-head Matrox G450 operating in xinerama mode.
Keyboard is set for for UK. Gnome desktop, but bug also occurs within
KDE apps. All updates as of bug-report date have been applied. CPU is
Athlon 1.2GHz with 1GB memory - kernel is 2.4.20-24.9bigmem.

Note that the right shift key works fine however.
Comment 1 Mike A. Harris 2003-12-16 10:51:14 EST
Did the same problem occur with stock RHL 9?  How about Fedora Core 1?
Comment 2 Chris Underhill 2003-12-16 11:37:54 EST
I don't have another machine on which to put Fedora but do have
another which has not yet been fully updated and still has
XFree86-4.3.0-2 from RH9. 

Admittedly it's running a non-RH kernel (2.4.22-pre4) and has a
different graphics card (Intel i810), but on that machine, the left
shift works fine. I'll update various packages on it and see if/when
it breaks.

The keyboard section from my XF86Config on both machines contains:

        Identifier  "Keyboard0"
        Driver      "keyboard"
        Option      "XkbRules" "xfree86"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "gb"
Comment 3 Chris Underhill 2004-01-22 08:43:53 EST
After some investigation, this is not a bug but a feature of running
gxine, which mimics the sending of the left shift key to stop the X
screensaver activating. The offending line is, with version 0.3.3,
gtkxine.c:160 - changing the key faked from XK_Shift_L to XK_Shift_R
lets the left shift key work properly again, but causes the right
shift key to malfunction instead. This is however much more
comfortable to my right-handed two-fingered typing :-)

Note You need to log in before you can comment on or make changes to this bug.