Defaulting keystroke_sleep_ms to 0?

[Doxmiatoo]

I rapidly press my keys when gaming and I've found when I spam press buttons over and over occasionally if I have a key set to an modified key (ie: Control_L + 3) every now and then it will just press 3. Is there any config or way to set it up where I won't have this happen?

[Doxmiatoo]

It looks like if I spam from one button to another that is using the same modifier it sometimes ignores.

So if I have 1 button set to alt+1 and another to alt+2 if I press the alt+2 binding and then very shortly after use the alt+1 binding it ignores the modifier and instead just sends 1.

[Doxmiatoo]

I think setting keystroke_sleep_ms to 0 seems to have solved it.

[sezanzeb]

let me know if setting this to 0 makes you face any other issues.

This was needed at some point because my environment would ignore the injections otherwise. Maybe this is not an issue anymore.

I need to conduct some more tests.

Maybe I can at least lower the default to 5ms or even less

[sezanzeb]

what is the highest setting that still works for you?

[sezanzeb]

@Doxmiatoo any update, are you facing any issues after setting it to 0?

[sezanzeb]

TODO:

• conduct own tests with 0 on wayland
• conduct own tests with 0 on x11
• if that works fine, remove the keystroke_sleep_ms parameter from as many places as possible, only keep it for key or something
• wait until someone complains
• reduce it until I can't reproduce the problem here anymore and use that as default (migrate all existing presets to use the old value of 10?)

[sezanzeb]

related: #292, there is a sleep for modify, which I think caused the problem there

[Doxmiatoo]

@Doxmiatoo any update, are you facing any issues after setting it to 0?

Zero issues; I’ve also tested it with 2 and had no issues.

[sezanzeb]

Zero issues; I’ve also tested it with 2 and had no issues.

awesome, thanks for letting me know! What does echo $XDG_SESSION_TYPE print? And which desktop environment are you using?

[jonasBoss]

we can set keystroke_sleep_ms to zero on the beta branch. There it is not a global setting but a setting for each mapping individually. So if problems arise it can be set to a different value for only the problematic mapping.

[sezanzeb]

it works perfectly fine with 0 for me, on both gnome on wayland and x11, and xfce on x11. strange

[sezanzeb]

yes, lets set that to 0 on the beta branch please

[ashleywaite]

I spent a while earlier totally confused about why my keys were working inconsistently.

I couldn't see any obvious indicator of why it doesn't work as expected, nor any timing delay on output from evtest either, I tried monitoring the devices input-remapper Logitech G915 WIRELESS RGB MECHANICAL GAMING KEYBOARD forwarded and then input-remapper keyboard to see if the actual outputs were wrong in some way, but they look fine other than being faster...

With delay 20, works for me every time:

Event: time 1652158423.889332, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1
Event: time 1652158423.889332, -------------- SYN_REPORT ------------
Event: time 1652158423.909930, type 1 (EV_KEY), code 2 (KEY_1), value 1
Event: time 1652158423.909930, -------------- SYN_REPORT ------------
Event: time 1652158423.930279, type 1 (EV_KEY), code 2 (KEY_1), value 0
Event: time 1652158423.930279, -------------- SYN_REPORT ------------
Event: time 1652158423.971402, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0
Event: time 1652158423.971402, -------------- SYN_REPORT ------------

With delay 0, does not work ever (in Wine):

Event: time 1652158551.164407, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1
Event: time 1652158551.164407, -------------- SYN_REPORT ------------
Event: time 1652158551.164542, type 1 (EV_KEY), code 2 (KEY_1), value 1
Event: time 1652158551.164542, -------------- SYN_REPORT ------------
Event: time 1652158551.164657, type 1 (EV_KEY), code 2 (KEY_1), value 0
Event: time 1652158551.164657, -------------- SYN_REPORT ------------
Event: time 1652158551.164797, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0
Event: time 1652158551.164797, -------------- SYN_REPORT ------------

As far as I can tell, the keys are leaving the faked device perfectly well, it's probably something external to the program and thus system dependent that causes it to not register correctly. :(

Were you using Wine previously when noticing the issue, because I am, and it works with 0 for me in KWrite, Firefox, and other native apps, but it didn't work in a game running through Wine (specifically, FFXIV in this case).

It turned out that the default of 10ms was long enough for it to work most of the time in Wine, but sometimes the modifier key wouldn't go through in time and the unmodified key went though instead.
I lowered it to 0 and it worked exactly never in Wine but when I raised it to 20 and it worked consistently every single time.

If I hadn't found this thread about this setting and played around with it I very likely never would have known the issue and given up on the approach entirely, because it's a type of silent failure that makes you think it's just incompatible in some way. Because my primary use was for within a game, I didn't even think to test outside the game in native apps until seeing the outputs (above) and realising it probably wasn't input-remapper at fault at all!

Please make this setting visible in the GUI so at least when things don't work people know it's there and can fiddle to find a solution!

As 10 appears to be on the cusp of (not) working in Wine it's probably a poor default. The valuable options might be 0 (I use native apps only), 20 (I need to use Wine), and an option to custom set it?

I'm running a near fresh install of KDE Neon 5.24 on x11.

[sezanzeb]

Thanks a lot for your insight, it's very valuable!

Please make this setting visible in the GUI so at least when things don't work people know it's there and can fiddle to find a solution!

that probably has to happen then, yes

Were you using Wine previously when noticing the issue

Possible. I made this app specifically because of a game I was playing back then that runs in wine. But I don't really remember where I actually encountered the issue to be honest.

[sezanzeb]

Maybe we should ask in the wine forum https://forum.winehq.org/index.php if this is a bug and if other people can reproduce it as well (I'll try it in wine later in the evening probably) and then possibly open a bug report at https://bugs.winehq.org/

[sezanzeb]

I think I'd only add it to the gui after asking around in the forum. Maybe this is a wine problem that can be fixed at some point.

We could start a troubleshooting readme file and mention this

[jonasBoss]

I was just testing to set it to zero on the beta branch. There seems to be a other bug: in the test TestEventPipeline.test_combination_keycode_macro_mix the macro "h(k(a))" gets stuck in an infinite loop. Maybe this is a problem with asyncio being overwhelmed or something. This would need further investigation.

I could set it to 1 without any problem. should I do that for now?

[ashleywaite]

Maybe we should ask in the wine forum https://forum.winehq.org/index.php if this is a bug and if other people can reproduce it as well (I'll try it in wine later in the evening probably) and then possibly open a bug report at https://bugs.winehq.org/

If someone else can replicate the bug also occurring only in Wine then it's probably a good next step!

FWIW, if you have any trouble replicating the issue, exactly what I've done is making my mouse side keys act as a conditional modifier for my keyboard number keys, but not to block clicks otherwise so they still work normally for every other context. This is fine with 0 delay in native apps.

I have on my mouse:
SIDE button - set(modside, 1).if_tap(key(btn_side), hold()).set(modside, 0)
EXTRA button - set(modextra, 1).if_tap(key(btn_extra), hold()).set(modextra, 0)
Then on keyboard on key 1 (and similar for the other numbers):

if_eq($modextra, 1, m(KEY_LEFTCTRL, key(1)),
	if_eq($modside, 1, m(KEY_LEFTSHIFT, key(1)),
		key(1)))

[sezanzeb]

the macro "h(k(a))" gets stuck in an infinite loop. Maybe this is a problem with asyncio being overwhelmed or something. This would need further investigation.

yeah, that makes sense. It is an infinite loop after all as long as the key is held down

I could set it to 1 without any problem. should I do that for now?

Or we add a 1 ms sleep to hold, then keystroke_sleep_ms can be safely set to 0

[Doxmiatoo]

Oddly enough I only use it in wine since I remap a gaming Razer Tartarus v2. I play almost exclusively WoW and FFXIV in wine and have had zero issues with it at 0.

[ashleywaite]

Oddly enough I only use it in wine since I remap a gaming Razer Tartarus v2. I play almost exclusively WoW and FFXIV in wine and have had zero issues with it at 0.

It pretty possible that there's some system dependent difference as well that introduces that delay in Wine. Knowing that there's some application dependent factor though means that testing to try to find other apps that may share the same behaviour - or specific Wine or system configurations - is at least a path that can plausibly find a cause!

Knowing that it isn't universal for Wine is helpful to know though, knowing the OSes and system environments in use is probably necessary to narrow it down.

[sezanzeb]

sorry, I forgot about this. I just tried it with 0 in wine and it works for me

I'll do the following later:

• add throttle of 1ms to hold to prevent freezes. Included in this PR: Add toggle macro #427
• post bug report for wine

[sezanzeb]

the wine bug report guidelines want us to try it on the latest development version: https://wiki.winehq.org/Bugs, can you reproduce the problem there?

[sezanzeb]

see gvalkov/python-evdev#187 (comment) and https://gitlab.freedesktop.org/libinput/libinput/-/issues/857

I was able to do ibus exit and experiment with IBus disabled. The amount of keystroke delay I needed to correct the issue went from dozens of milliseconds down to 1ms.