Bug 25480 - 'Stickykeys' caps issue
Summary: 'Stickykeys' caps issue
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-06 18:19 UTC by Stefan de Konink
Modified: 2010-06-10 19:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
XEV output, with comments inline="###" (15.34 KB, text/plain)
2010-03-10 07:40 UTC, Chad MILLER
no flags Details
Testcase for sticky shift with XTEST (902 bytes, text/x-csrc)
2010-06-08 15:57 UTC, noordsij
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan de Konink 2009-12-06 18:19:21 UTC
After a recent upgrade of X.org on Gentoo Linux my keyboard is behaving in a way I don't like. For no reason what so ever the keyboard behaves like the shift key is pressed.

To me it is completely random behavior while described by others before:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/213669
http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg85076.html

or myself:
http://bugs.gentoo.org/show_bug.cgi?id=292444


In a different setting on Centos I noticed something similar is going; it seems like the key modifiers (alt/ctrl) are for some reason pressed, but never receive a release. Not even after pressing them several times.

The behavior is only present within X, and not on the console. I did not yet find out what actually causes te release (back to normal behavior). As you can understand this totally kills productivity... and I am very willing to help debugging it.


X.Org X Server 1.7.3
xf86-input-evdev-2.3.1
Comment 1 Peter Hutterer 2009-12-06 18:47:51 UTC
Reassigning to XKB, my bet is it's a race condition in the repeat code.
Comment 2 Stefan de Konink 2009-12-07 15:12:13 UTC
I don't know if I can blame some random mouse movements around this event also on this bug, or that is my optical mouse going nuts.
Comment 3 Peter Hutterer 2009-12-07 20:21:03 UTC
any specific version you noticed this behaviour first? e.g. it happend in
1.7.3 but not in 1.7.1.
If so, is it possible to bisect it to the commit it started appearing in?

if not, do you have a reproducible testcase?
Comment 4 Stefan de Konink 2009-12-07 20:34:46 UTC
An upgrade between 1.6.4 and -1.7.1 will probably not help us at all...
Comment 5 Stefan de Konink 2009-12-08 12:39:49 UTC
Some other observations;

When I'm stuck in this mode. Within vim my arrow up and down behave like pageup down. If I type the arrow keys in xterm I get A B C D.
Comment 6 Peter Hutterer 2009-12-08 17:39:35 UTC
looking at the xorg.conf from the gentoo bug:
you can just remove the mouse and the keyboard section, it's HAL that provides the configuration anyway. this way the log and the config are less noisy.

please try with the default keyboard configuration - does it happen there as well? (just trying to rule out configuration issues).

i haven't seen this behaviour here (running 1.7.3/master) so without a test case to reproduce it's going to be hard to find.
Comment 7 Stefan de Konink 2009-12-09 11:41:40 UTC
What kernel version are you running? Because I just upgraded a P4 with 2.6.32 and out of the blue there is a key down event while my entire keyboard isn't doing anything.
Comment 8 Stefan de Konink 2009-12-29 12:53:23 UTC
There are typically 3 events; these are the first two:

(gdb) p *keybd
$3 = {public = {devicePrivate = 0x293eda0,
    processInputProc = 0x57b60f <ProcessKeyboardEvent>,
    realInputProc = 0x57b60f <ProcessKeyboardEvent>,
    enqueueInputProc = 0x43f8a8 <EnqueueEvent>, on = 1}, next = 0x2947720,
  startup = 1, deviceProc = 0x7f72a978eaf0 <EvdevProc>, inited = 1,
  enabled = 1, coreEvents = 4, deviceGrab = {grabTime = {months = 0,
      milliseconds = 14844647}, fromPassiveGrab = 0, implicitGrab = 0,
    activeGrab = {next = 0x0, resource = 0, device = 0x0, window = 0x0,
      ownerEvents = 0, keyboardMode = 0, pointerMode = 0,
      grabtype = GRABTYPE_CORE, type = 0 '\000', modifiersDetail = {exact = 0,
        pMask = 0x0}, modifierDevice = 0x0, detail = {exact = 0, pMask = 0x0},
      confineTo = 0x0, cursor = 0x0, eventMask = 0, deviceMask = 0, xi2mask = {
        "\000\000" <repeats 42 times>}}, grab = 0x0, activatingKey = 0 '\000',
    ActivateGrab = 0x440887 <ActivateKeyboardGrab>,
    DeactivateGrab = 0x440a46 <DeactivateKeyboardGrab>, sync = {frozen = 0,
      state = 0, other = 0x0, event = 0x0}}, type = 3, xinput_type = 74,
  name = 0x293fd90 "AT Translated Set 2 keyboard", id = 7, key = 0x2940a70,
  valuator = 0x0, button = 0x0, focus = 0x2945c70, proximity = 0x0,
  absolute = 0x0, kbdfeed = 0x2940af0, ptrfeed = 0x0, intfeed = 0x0,
  stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x0,
  config_info = 0x2945d70 "hal:/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input", devPrivates = 0x2940640, nPrivates = 0,
  unwrapProc = 0x577004 <xkbUnwrapProc>, spriteInfo = 0x2940618, u = {
    master = 0x2615ab0, lastSlave = 0x2615ab0}, last = {valuators = {
---Type <return> to continue, or q <return> to quit---
      0 <repeats 36 times>}, remainder = {0 <repeats 36 times>},
    numValuators = 0, slave = 0x0}, properties = {properties = 0x2945ce0,
    handlers = 0x2945d10}}
(gdb) p *event
$4 = {header = 255 '\377', type = ET_KeyPress, length = 408, time = 18332074,
  deviceid = 7, sourceid = 7, detail = {button = 43, key = 43}, root_x = 0,
  root_x_frac = 0, root_y = 0, root_y_frac = 0,
  buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000",
    mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {
      0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0,
    effective = 0}, group = {base = 0 '\000', latched = 0 '\000',
    locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0,
  key_repeat = 0}


(gdb) p *keybd
$5 = {public = {devicePrivate = 0x293eda0, 
    processInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    realInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    enqueueInputProc = 0x43f8a8 <EnqueueEvent>, on = 0}, next = 0x2617560, 
  startup = 1, deviceProc = 0x42757b <CoreKeyboardProc>, inited = 1, 
  enabled = 1, coreEvents = 1, deviceGrab = {grabTime = {months = 0, 
      milliseconds = 18283658}, fromPassiveGrab = 0, implicitGrab = 0, 
    activeGrab = {next = 0x0, resource = 12582912, device = 0x2615ab0, 
      window = 0x296b9f0, ownerEvents = 0, keyboardMode = 1, pointerMode = 1, 
      grabtype = GRABTYPE_CORE, type = 0 '\000', modifiersDetail = {exact = 0, 
        pMask = 0x0}, modifierDevice = 0x0, detail = {exact = 0, pMask = 0x0}, 
      confineTo = 0x0, cursor = 0x0, eventMask = 3, deviceMask = 0, xi2mask = {
        "\000\000" <repeats 42 times>}}, grab = 0x0, 
    activatingKey = 23 '\027', ActivateGrab = 0x440887 <ActivateKeyboardGrab>, 
    DeactivateGrab = 0x440a46 <DeactivateKeyboardGrab>, sync = {frozen = 0, 
      state = 0, other = 0x0, event = 0x33463d0}}, type = 2, xinput_type = 0, 
  name = 0x2615ed0 "Virtual core keyboard", id = 3, key = 0x264ad00, 
  valuator = 0x0, button = 0x0, focus = 0x2656d50, proximity = 0x0, 
  absolute = 0x0, kbdfeed = 0x264ad80, ptrfeed = 0x0, intfeed = 0x0, 
  stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x31c60b0, 
  config_info = 0x0, devPrivates = 0x2615f10, nPrivates = 0, 
  unwrapProc = 0x577004 <xkbUnwrapProc>, spriteInfo = 0x2615e28, u = {
    master = 0x29402a0, lastSlave = 0x29402a0}, last = {valuators = {
      0 <repeats 36 times>}, remainder = {0 <repeats 36 times>}, 
---Type <return> to continue, or q <return> to quit---
    numValuators = 0, slave = 0x29402a0}, properties = {
    properties = 0x2615e50, handlers = 0x2615ea0}}
(gdb) p *event
$6 = {header = 255 '\377', type = ET_KeyPress, length = 408, time = 18332074, 
  deviceid = 3, sourceid = 7, detail = {button = 43, key = 43}, root_x = 0, 
  root_x_frac = 0, root_y = 0, root_y_frac = 0, 
  buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000", 
    mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {
      0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, 
    effective = 0}, group = {base = 0 '\000', latched = 0 '\000', 
    locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, 
  key_repeat = 0}
Comment 9 Stefan de Konink 2009-12-29 13:07:43 UTC
Some more, this produced 'D' while 'd' was expected

(gdb) p *event
$7 = {header = 255 '\377', type = ET_KeyPress, length = 408, time = 19366513, 
  deviceid = 7, sourceid = 7, detail = {button = 43, key = 43}, root_x = 0, 
  root_x_frac = 0, root_y = 0, root_y_frac = 0, 
  buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000", 
    mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {
      0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, 
    effective = 0}, group = {base = 0 '\000', latched = 0 '\000', 
    locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, 
  key_repeat = 0}
(gdb) p *keybd
$8 = {public = {devicePrivate = 0x293eda0, 
    processInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    realInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    enqueueInputProc = 0x43f8a8 <EnqueueEvent>, on = 1}, next = 0x2947720, 
  startup = 1, deviceProc = 0x7f72a978eaf0 <EvdevProc>, inited = 1, 
  enabled = 1, coreEvents = 4, deviceGrab = {grabTime = {months = 0, 
      milliseconds = 14844647}, fromPassiveGrab = 0, implicitGrab = 0, 
    activeGrab = {next = 0x0, resource = 0, device = 0x0, window = 0x0, 
      ownerEvents = 0, keyboardMode = 0, pointerMode = 0, 
      grabtype = GRABTYPE_CORE, type = 0 '\000', modifiersDetail = {exact = 0, 
        pMask = 0x0}, modifierDevice = 0x0, detail = {exact = 0, pMask = 0x0}, 
      confineTo = 0x0, cursor = 0x0, eventMask = 0, deviceMask = 0, xi2mask = {
        "\000\000" <repeats 42 times>}}, grab = 0x0, activatingKey = 0 '\000', 
    ActivateGrab = 0x440887 <ActivateKeyboardGrab>, 
    DeactivateGrab = 0x440a46 <DeactivateKeyboardGrab>, sync = {frozen = 0, 
      state = 0, other = 0x0, event = 0x0}}, type = 3, xinput_type = 74, 
  name = 0x293fd90 "AT Translated Set 2 keyboard", id = 7, key = 0x2940a70, 
  valuator = 0x0, button = 0x0, focus = 0x2945c70, proximity = 0x0, 
  absolute = 0x0, kbdfeed = 0x2940af0, ptrfeed = 0x0, intfeed = 0x0, 
  stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x0, 
  config_info = 0x2945d70 "hal:/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input", devPrivates = 0x2940640, nPrivates = 0, 
  unwrapProc = 0x577004 <xkbUnwrapProc>, spriteInfo = 0x2940618, u = {
    master = 0x2615ab0, lastSlave = 0x2615ab0}, last = {valuators = {
---Type <return> to continue, or q <return> to quit---
      0 <repeats 36 times>}, remainder = {0 <repeats 36 times>}, 
    numValuators = 0, slave = 0x0}, properties = {properties = 0x2945ce0, 
    handlers = 0x2945d10}}




(gdb) p *event
$9 = {header = 255 '\377', type = ET_KeyPress, length = 408, time = 19366513, 
  deviceid = 3, sourceid = 7, detail = {button = 43, key = 43}, root_x = 0, 
  root_x_frac = 0, root_y = 0, root_y_frac = 0, 
  buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000", 
    mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {
      0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, 
    effective = 0}, group = {base = 0 '\000', latched = 0 '\000', 
    locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, 
  key_repeat = 0}
(gdb) p *keybd
$10 = {public = {devicePrivate = 0x293eda0, 
    processInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    realInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    enqueueInputProc = 0x43f8a8 <EnqueueEvent>, on = 0}, next = 0x2617560, 
  startup = 1, deviceProc = 0x42757b <CoreKeyboardProc>, inited = 1, 
  enabled = 1, coreEvents = 1, deviceGrab = {grabTime = {months = 0, 
      milliseconds = 19347976}, fromPassiveGrab = 0, implicitGrab = 0, 
    activeGrab = {next = 0x0, resource = 39845888, device = 0x2615ab0, 
      window = 0x3399f10, ownerEvents = 1, keyboardMode = 1, pointerMode = 1, 
      grabtype = GRABTYPE_CORE, type = 0 '\000', modifiersDetail = {exact = 0, 
        pMask = 0x0}, modifierDevice = 0x0, detail = {exact = 0, pMask = 0x0}, 
      confineTo = 0x0, cursor = 0x0, eventMask = 3, deviceMask = 0, xi2mask = {
        "\000\000" <repeats 42 times>}}, grab = 0x0, 
    activatingKey = 23 '\027', ActivateGrab = 0x440887 <ActivateKeyboardGrab>, 
    DeactivateGrab = 0x440a46 <DeactivateKeyboardGrab>, sync = {frozen = 0, 
      state = 0, other = 0x0, event = 0x33463d0}}, type = 2, xinput_type = 0, 
  name = 0x2615ed0 "Virtual core keyboard", id = 3, key = 0x264ad00, 
  valuator = 0x0, button = 0x0, focus = 0x2656d50, proximity = 0x0, 
  absolute = 0x0, kbdfeed = 0x264ad80, ptrfeed = 0x0, intfeed = 0x0, 
  stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x2f4c0e0, 
  config_info = 0x0, devPrivates = 0x2615f10, nPrivates = 0, 
  unwrapProc = 0x577004 <xkbUnwrapProc>, spriteInfo = 0x2615e28, u = {
    master = 0x29402a0, lastSlave = 0x29402a0}, last = {valuators = {
      0 <repeats 36 times>}, remainder = {0 <repeats 36 times>}, 
---Type <return> to continue, or q <return> to quit---
    numValuators = 0, slave = 0x29402a0}, properties = {
    properties = 0x2615e50, handlers = 0x2615ea0}}


(gdb) p *event
$11 = {header = 255 '\377', type = ET_KeyPress, length = 408, time = 19415753, 
  deviceid = 5, sourceid = 5, detail = {button = 50, key = 50}, root_x = 0, 
  root_x_frac = 0, root_y = 0, root_y_frac = 0, 
  buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000", 
    mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {
      0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, 
    effective = 0}, group = {base = 0 '\000', latched = 0 '\000', 
    locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, 
  key_repeat = 0}
(gdb) p *keybd
$12 = {public = {devicePrivate = 0x0, 
    processInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    realInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    enqueueInputProc = 0x43f8a8 <EnqueueEvent>, on = 0}, next = 0x293b5a0, 
  startup = 1, deviceProc = 0x42757b <CoreKeyboardProc>, inited = 1, 
  enabled = 1, coreEvents = 1, deviceGrab = {grabTime = {months = 0, 
      milliseconds = 14844647}, fromPassiveGrab = 0, implicitGrab = 0, 
    activeGrab = {next = 0x0, resource = 0, device = 0x0, window = 0x0, 
      ownerEvents = 0, keyboardMode = 0, pointerMode = 0, 
      grabtype = GRABTYPE_CORE, type = 0 '\000', modifiersDetail = {exact = 0, 
        pMask = 0x0}, modifierDevice = 0x0, detail = {exact = 0, pMask = 0x0}, 
      confineTo = 0x0, cursor = 0x0, eventMask = 0, deviceMask = 0, xi2mask = {
        "\000\000" <repeats 42 times>}}, grab = 0x0, activatingKey = 0 '\000', 
    ActivateGrab = 0x440887 <ActivateKeyboardGrab>, 
    DeactivateGrab = 0x440a46 <DeactivateKeyboardGrab>, sync = {frozen = 0, 
      state = 0, other = 0x0, event = 0x0}}, type = 3, xinput_type = 0, 
  name = 0x2618590 "Virtual core XTEST keyboard", id = 5, key = 0x2619cc0, 
  valuator = 0x0, button = 0x0, focus = 0x261eb80, proximity = 0x0, 
  absolute = 0x0, kbdfeed = 0x2619d40, ptrfeed = 0x0, intfeed = 0x0, 
  stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x0, 
  config_info = 0x0, devPrivates = 0x26185e0, nPrivates = 0, 
  unwrapProc = 0x577004 <xkbUnwrapProc>, spriteInfo = 0x2618508, u = {
    master = 0x2615ab0, lastSlave = 0x2615ab0}, last = {valuators = {
      0 <repeats 36 times>}, remainder = {0 <repeats 36 times>}, 
---Type <return> to continue, or q <return> to quit---
    numValuators = 0, slave = 0x0}, properties = {properties = 0x2657290, 
    handlers = 0x26572e0}}

(gdb) p *event
$13 = {header = 255 '\377', type = ET_KeyPress, length = 408, time = 19415753, 
  deviceid = 3, sourceid = 5, detail = {button = 50, key = 50}, root_x = 0, 
  root_x_frac = 0, root_y = 0, root_y_frac = 0, 
  buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000", 
    mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {
      0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, 
    effective = 0}, group = {base = 0 '\000', latched = 0 '\000', 
    locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, 
  key_repeat = 0}
(gdb) p *keybd
$14 = {public = {devicePrivate = 0x0, 
    processInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    realInputProc = 0x57b60f <ProcessKeyboardEvent>, 
    enqueueInputProc = 0x43f8a8 <EnqueueEvent>, on = 0}, next = 0x2617560, 
  startup = 1, deviceProc = 0x42757b <CoreKeyboardProc>, inited = 1, 
  enabled = 1, coreEvents = 1, deviceGrab = {grabTime = {months = 0, 
      milliseconds = 19347976}, fromPassiveGrab = 0, implicitGrab = 0, 
    activeGrab = {next = 0x0, resource = 39845888, device = 0x2615ab0, 
      window = 0x3399f10, ownerEvents = 1, keyboardMode = 1, pointerMode = 1, 
      grabtype = GRABTYPE_CORE, type = 0 '\000', modifiersDetail = {exact = 0, 
        pMask = 0x0}, modifierDevice = 0x0, detail = {exact = 0, pMask = 0x0}, 
      confineTo = 0x0, cursor = 0x0, eventMask = 3, deviceMask = 0, xi2mask = {
        "\000\000" <repeats 42 times>}}, grab = 0x0, 
    activatingKey = 23 '\027', ActivateGrab = 0x440887 <ActivateKeyboardGrab>, 
    DeactivateGrab = 0x440a46 <DeactivateKeyboardGrab>, sync = {frozen = 0, 
      state = 0, other = 0x0, event = 0x33463d0}}, type = 2, xinput_type = 0, 
  name = 0x2615ed0 "Virtual core keyboard", id = 3, key = 0x264ad00, 
  valuator = 0x0, button = 0x0, focus = 0x2656d50, proximity = 0x0, 
  absolute = 0x0, kbdfeed = 0x264ad80, ptrfeed = 0x0, intfeed = 0x0, 
  stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x2f4c0e0, 
  config_info = 0x0, devPrivates = 0x2615f10, nPrivates = 0, 
  unwrapProc = 0x577004 <xkbUnwrapProc>, spriteInfo = 0x2615e28, u = {
    master = 0x2618190, lastSlave = 0x2618190}, last = {valuators = {
      0 <repeats 36 times>}, remainder = {0 <repeats 36 times>}, 
---Type <return> to continue, or q <return> to quit---
    numValuators = 0, slave = 0x2618190}, properties = {
    properties = 0x2615e50, handlers = 0x2615ea0}}
Comment 10 Stefan de Konink 2009-12-29 20:09:54 UTC
Peter, looking at the GDB output. Is there some 'two keyboards' in my system issue? Where one keyboard is picked up by evdev and the other by corekeyboard, whatever that maybe?
Comment 11 Peter Hutterer 2010-01-03 19:11:18 UTC
(In reply to comment #10)
> Peter, looking at the GDB output. Is there some 'two keyboards' in my system
> issue? Where one keyboard is picked up by evdev and the other by corekeyboard,
> whatever that maybe?
> 

the virtual core keyboard is hardcoded and always present, that's fine. I'm more surprised by the XTEST keyboard here, it's not something I'd expect unless you're using synergy or something.
Comment 12 Stefan de Konink 2010-01-03 19:24:50 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > Peter, looking at the GDB output. Is there some 'two keyboards' in my system
> > issue? Where one keyboard is picked up by evdev and the other by corekeyboard,
> > whatever that maybe?
> > 
> 
> the virtual core keyboard is hardcoded and always present, that's fine. I'm
> more surprised by the XTEST keyboard here, it's not something I'd expect unless
> you're using synergy or something.

I do have it installed, but I don't run it that often. And I'm very sure it wasn't started.
Comment 13 Stefan de Konink 2010-01-07 12:26:36 UTC
(In reply to comment #12)
> I do have it installed, but I don't run it that often. And I'm very sure it
> wasn't started.

Found out that tvtime also uses it.
Comment 14 Stefan de Konink 2010-01-10 16:25:03 UTC
I have uninstalled Xtst, and I have not yet experienced any incident.
Comment 15 Rolf Leggewie 2010-01-19 05:05:46 UTC
could this be bug 23938 after all?  There are a number of reports floating around the net.  The symptoms are always slightly different, but at the same time similar enough that the root cause may be the same.

FWIW, I experienced stuck keys only in X and when under high load.
Comment 16 Rolf Leggewie 2010-01-19 05:06:32 UTC
Oh, there are reports that evdev does not have the stuck key problem.
Comment 17 Stefan de Konink 2010-01-19 05:11:12 UTC
After having libXtst uninstalled, I have used mplayer to display television. And I have never had the problem ever again. So I am positive that this is related to LibXtst
Comment 18 Chad MILLER 2010-03-10 07:40:09 UTC
Created attachment 33923 [details]
XEV output, with comments inline="###"

Here are my XEV dump results of this problem, which I can reproduce reliably on remote x2x Ctrl press.
Comment 19 Chad MILLER 2010-03-10 07:44:49 UTC
With both X2X and Synergy, the local key state gets stuck with some modifiers on, both randomly and in response to key usage on the remote X.

Case 1, random: I have seen Shift toggled on in the middle of a sENTENCE< EVEN WHEN IT was unused. Pressing Shift on the remote keyboard has no effect, but on the local keyboard, it will un-set the Shift modifier. Triggering of this case appears to be somewhat rare, perhaps once every ten thousand button presses or 10 times per day.

Case 2, repeatable: For the last week or so, I can repeatably and reliably trigger Ctrl state high, on any use of Ctrl from the remote keyboard. Again, only local Ctrl press+release unsets the state. For this case, I attach an XEV dump of it happening.

local xorg v1:7.5+1ubuntu2
remote xorg v1:7.5+3ubuntu1
(Both are loosely following Ubuntu 10.04-pre, and are updated occasionally. The problems have been happening since before Ubuntu 9.10, though.)

Other disclosure: Using compiz or not does not seem to affect it. On both machines, I have set CapsLock to be Ctrl, and Menu key to be Compose, and Hyper is mapped to Win-keys. Both are using the same keymapping, according to Gnome Keyboard Preferences + Layout: "Generic 104-key PC". (Though one is a laptop (~86) and one is a true 104.)
Comment 20 noordsij 2010-06-03 11:40:38 UTC
My specific symptoms: when typing fast, some combination of shift+character and just a character, at some point shift key seems to get stuck, i.e. it types only capitals, page-up/down are broken, etc. According to xev the keyboard modifier state has become 0x1, corresponding to a shift-pressed state, however, I've added debug prints to the evdev driver and all shift keypresses (key #50 for lshift) and keyreleases work properly, also while in the broken state. I.e., xorg is definitely receiving lshift-released events. The xorg internal modifier state however does not change until I ctrl-alt-f1 out of X, ctr-alt-f7 back, and then press lshift once.

* Arch Linux, 64 bit, updated regularly, issue has existed for a while (months..) However, only happens on this exact PC, not a laptop with the same distro (and thus kernel/xorg version).
* Happens both with a PS/2 and a USB keyboard, both using evdev driver
* No synergy, no X2X, nothing special, just plain X
* Happens with intel and/or nvidia graphics cards and drivers
* Usually happens in a vim session in a konsole window in a kde4 session

It does not seem to be randomly distributed; it may not happen for hours, just long to start thinking "Hmm could it really be gone" and then suddenly it will hit 5 times in a row.

I'd be happy to poke around in X, it would be nice if someone can offer a good place to start looking (where/how is modifier state updated in X?)
Comment 21 Stefan de Konink 2010-06-03 11:43:04 UTC
(In reply to comment #20)
> * No synergy, no X2X, nothing special, just plain X

Check if libXtst is installed.
Comment 22 noordsij 2010-06-08 12:20:46 UTC
Interestingly, the problem seems to trigger only when Kaffeine is running (during playback). Kaffeine, when not running under KDE, uses fake key presses to prevent the screensaver from coming up, using the XTEST extension

The relevant code:

#ifdef HAVE_XTEST
    haveXTest = false;

    int dummy_event, dummy_error, dummy_major, dummy_minor;
    if (XTestQueryExtension(x11Display(), &dummy_event, &dummy_error, &dummy_major, &dummy_minor)) {
        fakeKeycode = XKeysymToKeycode(x11Display(), XK_Shift_L);
        if (fakeKeycode != 0)
            haveXTest = true;
    }
#endif

It is set up to trigger the following every 55 seconds:

<snip/>
       kdDebug() << "Kaffeine: Fake key press\n";
       XTestFakeKeyEvent(x11Display(), fakeKeycode, true, 0);
       XTestFakeKeyEvent(x11Display(), fakeKeycode, false, 0);
       XFlush(x11Display());
<snip/>

I've disabled this, and have not run into any occurrences so far. This still sounds like a bug somewhere, but at least this way it does not manifest itself.

Stefan's experience with disabling Xst seems to support this as well.

Similarly, Synergy/X2X may be triggering this bug using similar code when injecting key events?
Comment 23 Peter Hutterer 2010-06-08 14:59:29 UTC
On Tue, Jun 08, 2010 at 12:20:46PM -0700, bugzilla-daemon@freedesktop.org wrote:
> <snip/>
>        kdDebug() << "Kaffeine: Fake key press\n";
>        XTestFakeKeyEvent(x11Display(), fakeKeycode, true, 0);
>        XTestFakeKeyEvent(x11Display(), fakeKeycode, false, 0);
>        XFlush(x11Display());
> <snip/>
> 
> I've disabled this, and have not run into any occurrences so far. This still
> sounds like a bug somewhere, but at least this way it does not manifest itself.

hmm, this sounds like a bug in the XTEST server parts. can you knock up a
simple demo program that reproduces this? if you take the 55s delay out and
get that sequence to repeat quickly enough, you might be able to trigger the
bug in seconds which makes it much easier to narrow down.
Comment 24 noordsij 2010-06-08 15:57:19 UTC
Created attachment 36168 [details]
Testcase for sticky shift with XTEST

gcc test.c -o test  -lX11 -lXtst

(You may need to add include/library paths on your system, maybe add unistd.h)

Demonstrates the issue.

Start the application, every 10 seconds, it prints out "Fake key press.."

Now, to reproduce:

1) Press and hold the left shift key
2) Wait for the next "Fake key press.."
3) Release the left shift key
4) Shortly press and release the left shift key
5) From now on, until the next "Fake key press.. " the shift key is stuck

I.e., the point of 1-3 is to have the shift key down during the fake key press.
Note that you must execute steps 4-5 in the 10 second window before the next fake key press, after which things go back to normal.

This reproduces things for me every single time, please let me know if any of this is unclear.
Comment 25 Peter Hutterer 2010-06-09 18:00:12 UTC
verified, thank you.
Comment 26 Peter Hutterer 2010-06-10 19:58:43 UTC
commit dc614484f93b67e8b62dbb1bb2fd247fe5a4c850
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jun 10 12:21:36 2010 +1000

    Xi: don't copy the modifier key count when copying device classes (#25480)


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.