Meta/Modifier keys stick in XTEST injection (x2x or synergy)

[Chad Miller]

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 preee+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 Lucid, and are updated occasionally. The problems have been happening since before Karmic, 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.)

[Peter Hutterer (peter-hutterer)]

Reassigning to XKB, my bet is it's a race condition in the repeat code.

[Stefan de Konink (skinkie)]

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.

[Peter Hutterer (peter-hutterer)]

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?

[Stefan de Konink (skinkie)]

An upgrade between 1.6.4 and -1.7.1 will probably not help us at all...

[Stefan de Konink (skinkie)]

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.

[Peter Hutterer (peter-hutterer)]

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.

[Stefan de Konink (skinkie)]

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.

[Stefan de Konink (skinkie)]

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'...

[Stefan de Konink (skinkie)]

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 = ...

[Stefan de Konink (skinkie)]

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?

[Peter Hutterer (peter-hutterer)]

(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.

[Stefan de Konink (skinkie)]

(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.

[Stefan de Konink (skinkie)]

(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.

[Stefan de Konink (skinkie)]

I have uninstalled Xtst, and I have not yet experienced any incident.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

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.

[Bugs-freedesktop-org (bugs-freedesktop-org)]

Oh, there are reports that evdev does not have the stuck key problem.

[Stefan de Konink (skinkie)]

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

[Chad Miller (cmiller)]

Created an attachment (id=33923)
XEV output, with comments inline="###"

Here are my XEV dump results of this problem, which I can reproduce reliably on remote x2x Ctrl press.

[Chad Miller (cmiller)]

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.)

[Chad Miller (cmiller)]

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 preee+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 Lucid, and are updated occasionally. The problems have been happening since before Karmic, 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.)

[Chad Miller (cmiller)]

Attached to Freedesktop-bug#25480 , but as that seems the most likely candidate bug I could find. I am not certain it is exact fit, though.

[Chad Miller (cmiller)]

I can no longer reproduce this as of Lucid update 2010-03-12 or so

[Noordsij (noordsij)]

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?)

[Stefan de Konink (skinkie)]

(In reply to comment #20)
> * No synergy, no X2X, nothing special, just plain X

Check if libXtst is installed.

[Noordsij (noordsij)]

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?

[Peter Hutterer (peter-hutterer)]

On Tue, Jun 08, 2010 at 12:20:46PM -0700, <email address hidden> 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.

[Noordsij (noordsij)]

Created an attachment (id=36168)
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.

[Peter Hutterer (peter-hutterer)]

verified, thank you.

[Peter Hutterer (peter-hutterer)]

commit dc614484f93b67e8b62dbb1bb2fd247fe5a4c850
Author: Peter Hutterer <email address hidden>
Date: Thu Jun 10 12:21:36 2010 +1000

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

[Cinquero (cinquero)]

That is very annoying over here. Not sure what x2x or Synergy is...