[0.18.27] Cut/copy/paste keyboard macros often fail in game

[LFarquaad]

I have a keyboard¹ which has physical keys for cut/copy/paste. These keys are macros that send shift+delete, control+insert and shift+insert, respectively. I have thus mapped those as secondary bindings for cut/copy/paste tools.

It appears, however, that those shortcuts often fail in game, like 75% of the time, and just do nothing. They work reliably when configuring them in the Control settings gui and making the key combination by hand works fine too. Could it be due to the modifier key sent too close to the insert/delete?

I am quite confident that this used to work fine in the past, but I must admit I hadn't played in over a year. The issue is already present in 0.17.79 though.

Related, but for text boxes: [0.17.33] Copy with Insert key (these shortcuts are known to be non-working in text boxes)


¹ two actually: a TypeMatrix and an Ergodox EZ, and I tested this with both of them

[LFarquaad]

I see this was moved to Technical Help. I believe this is a bug but if I can fix this issue thanks to some help that would be nice.

I forgot to mention I am playing on Linux. I can test it on Windows too if desired.

However, on Linux I can also use xev to give you the output of this macro, which I guess is useful as well. So here it is:
Outside Factorio: xev -event keyboard
Key press:

Code: Select all

KeyPress event, serial 30, synthetic NO, window 0xb800001,
    root 0x190, subw 0x0, time 1357894501, (379,319), root:(407,404),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0xb800001,
    root 0x190, subw 0x0, time 1357894509, (379,320), root:(407,405),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Key released:

Code: Select all

KeyRelease event, serial 30, synthetic NO, window 0xb800001,
    root 0x190, subw 0x0, time 1357894717, (391,338), root:(419,423),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0xb800001,
    root 0x190, subw 0x0, time 1357894725, (391,338), root:(419,423),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

In Factorio: xev -event keyboard -id 0xbe00014
An instance where the shortcut failed:

Code: Select all

KeyRelease event, serial 18, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1358759121, (1317,483), root:(1317,483),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 18, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1358759121, (1317,483), root:(1317,483),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1358759129, (1317,483), root:(1317,483),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1358759129, (1317,483), root:(1317,483),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1358759233, (1317,483), root:(1317,483),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1358759241, (1317,483), root:(1317,483),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

(for some reason when capturing a window (not Factorio specifically), every KeyPress is preceded by a KeyRelease. I suppose these can be ignored)

An instance where the shortcut worked (triggered a blueprint copy):

Code: Select all

KeyRelease event, serial 18, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1359702990, (1308,400), root:(1308,400),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 18, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1359702990, (1308,400), root:(1308,400),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1359702998, (1308,400), root:(1308,400),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1359702998, (1308,400), root:(1308,400),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1359703110, (1308,400), root:(1308,400),
    state 0x14, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0xbe00014,
    root 0x190, subw 0x0, time 1359703118, (1308,400), root:(1308,400),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

I don't see much difference… There are 8ms between pressing Control and Insert in both cases, and Insert is held for 104 vs 112ms.

Making the combination by hand, I can easily press & release Insert in less than 100ms and trigger the shortcut, so that does not seem to be the problem.
If I maintain Control before using the macro key, the shortcut works.
This was done with the ErgoDox EZ. With the TypeMatrix, the delay between Control and Insert is 0ms according to xev, and it consistently fails.

It thus seems that the problem is due to the modifier being too close to the other key.
I could also test this by typing the two keys almost simultaneously, manually. It seems there is some rounding involved because I always get differences in multiples of 8ms, however, here is what I find: (I tested with Shift+Delete as it is easier than to use Insert)

• When pressing Shift first, if Delete is pressed…
  • …after more than 16ms, it always succeeds
  • …after between around 8 and 16ms, it's random (same tick?)
  • …at the same time (macro key on TypeMatrix only, Shift reported first in xev), it always fails
• When pressing Delete first, if Shift is pressed…
  • …after more than around 16ms, it always fails
  • …after less than around 16ms, it succeeds (strangely)

This gives something like:

Code: Select all

Press Shift at 0ms
Time:               <---------------|---------------|---------------|--------------->
Press Delete at     past          -16ms            0ms            8-16ms       future
                         failure         success        failure          success

[LFarquaad]

Up! Any chance someone could help me with that, or confirm that it is a bug? (even if it won't get fixed)

[LFarquaad]

Up! Just passing by to say I am still affected by this bug in latest experimental version (1.1.21).

BTW if a mod could move it back to the bug reports, that would be nice. And I would also perfectly accept a “Won't fix” answer. It's just that having this thread in “Technical help” does not, actually, help.