Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent behaviour with --hook and --withhold with repeated presses #46

Open
masnax opened this issue Sep 4, 2024 · 2 comments
Open

Comments

@masnax
Copy link

masnax commented Sep 4, 2024

Take the following configuration:

evsieve \
--input /dev/input/event9 grab domain=k1 \
--hook key:leftmeta key:m sequential breaks-on=key::1 send-key=key:leftctrl send-key=key:o exec-shell="echo something" \
--withhold \
--output @k1

Which is intended to passthrough all inputs to @k1 except leftmeta+m, which will instead send leftctrl+o, and execute a script.

However, if leftmeta is held down while m is pressed and unpressed repeatedly, the --withhold seems to no longer work properly:

# Press "leftmeta", then "m"
KeyPress    keycode 37   Control_L
KeyPress    keycode 32   o

# Release only "m"
KeyRelease  keycode 32   o
KeyRelease  keycode 37   Control_L

# Press "m" again, with "leftmeta" held down.
KeyPress    keycode 58   m  <-- should not be sent
KeyPress    keycode 37   Control_L
KeyPress    keycode 32   o

# Release only "m"
KeyRelease  keycode 32   o
KeyRelease  keycode 37   Control_L
KeyRelease  keycode 58   m <-- should not be sent
KarsMulder added a commit that referenced this issue Sep 5, 2024
In further news, loosen the time constraints on one unittest and make the reported errors more detailed.
@KarsMulder
Copy link
Owner

Thanks for the bug report!

The good news is that I have managed to reproduce the bug and have figured out what causes it.
The bad news it that it isn't easy to fix and requires me to completely rethink how --withhold works.

I'm currently working on a solution.

KarsMulder added a commit that referenced this issue Sep 9, 2024
The code compiles and all unittests now pass, including the new
unittest from issue #46, but I still need to comb through the code
once more; too much got rewritten to have confidence that the
untouched parts of the code still function as they are supposed to.
@KarsMulder
Copy link
Owner

This issue is now most likely fixed on the main branch.

I'm going to skip making a 1.4.1 patch and will instead try to officially release version 1.5.0 somewhere in the next couple of weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants