xdotool produces additional {Control,Alt,Shift}_L key presses on key {Control,Alt,Shift}_R

[mxork]

xdotool key Shift_R produces the following log under xev:

KeyPress event, serial 35, synthetic NO, window 0x7200001,
    root 0x240, subw 0x0, time 2102319588, (118,71), root:(1309,713),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x7200001,
    root 0x240, subw 0x0, time 2102319595, (118,71), root:(1309,713),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x7200001,
    root 0x240, subw 0x0, time 2102319603, (118,71), root:(1309,713),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x7200001,
    root 0x240, subw 0x0, time 2102319603, (118,71), root:(1309,713),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

The Shift_L events are not produced when using the keycode directly or when pressing the key on the keyboard.

Confirmed same behavior with Control_R, Alt_R.

[jordansissel]

Oh interesting. I tried reproducing this on XQuartz on my Mac (since that's what I have at the moment) and can confirm your report. Sometimes it shows NoSymbol instead of Shift_L, though this may just be a quirk of XQuartz.

I think I found the issue, though I haven't dug into the related code history nor have I investigated a solution.

The bug, I think: xdotool may be mistakely determining that, in order to press Shift_R, one must also hold Shift_L.

Some background: On startup, xdotool tries to figure out what modifier keys are needed in order to send anything in the current keymap. This is needed for keymaps where certain characters may require holding modifier keys like AltGr or Shift. For example, : (colon) on my keyboard requires holding shift while pressing ; (semicolon). xev output for xdotool key colon is:

KeyPress event, serial 25, synthetic NO, window 0x600001,
    root 0xc0, subw 0x0, time 3556336584, (101,46), root:(1114,240),
    state 0x0, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 25, synthetic NO, window 0x600001,
    root 0xc0, subw 0x0, time 3556336585, (101,46), root:(1114,240),
    state 0x1, keycode 49 (keysym 0x3a, colon), same_screen YES,
    XLookupString gives 1 bytes: (3a) ":"
    XmbLookupString gives 1 bytes: (3a) ":"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x600001,
    root 0xc0, subw 0x0, time 3556336593, (101,46), root:(1114,240),
    state 0x1, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x600001,
    root 0xc0, subw 0x0, time 3556336593, (101,46), root:(1114,240),
    state 0x0, keycode 49 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

It presses shift, then keycode 49 (semicolon), then releases both.

I believe it's doing the same thing (using modifier keys) when instructed to press the Shift_R key and that is a bug.