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
Reassigning to XKB, my bet is it's a race condition in the repeat code.
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.
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?
An upgrade between 1.6.4 and -1.7.1 will probably not help us at all...
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.
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.
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.
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}
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}}
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?
(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.
(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.
(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.
I have uninstalled Xtst, and I have not yet experienced any incident.
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.
Oh, there are reports that evdev does not have the stuck key problem.
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
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.
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.)
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?)
(In reply to comment #20) > * No synergy, no X2X, nothing special, just plain X Check if libXtst is installed.
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?
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.
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.
verified, thank you.
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.