-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
Hitting keys in the wrong order causes keys to be infinitely re-emitted #166
Comments
I'm not exactly sure what even causes this issue, but I'm quite curious if you could point me in the right direction. We do have a fork for our Any help, even just a hint of what to look into to get started on fixing this bug would be much appreciated. Thanks for your incredible work, y'all! |
Thanks for the report! I think Lines 341 to 343 in fdf5e10
Basically, this checks that all modifier keys are pressed and that the keysym is also being pressed. Lines 277 to 284 in fdf5e10
Is triggering the hotkey on The second part of your issue seems pretty bad still. I will take a look as soon as possible. |
Unfortunately, I cannot reproduce the issue. I used a slightly different config to test your issue, on the latest git version of swhkd:
Pressing Could you give a bit more info about your environment? |
Never mind, I managed to trigger the bug you mentioned. I will investigate what's happening. |
Here are my findings: When first pressing a key ( To avoid killing the daemon during testing, you can just tap the key (without any modifier) to trigger a key press and key release event. |
The issue here is that, for example, Due to that behavior in other applications, it makes the "reverse key combo still being triggered" an issue, since now the I don't see a way to combine solving this issue with the current architecture for the following reason: We cannot send out a key release event for every key in a pressed key binding; this could cause even more weird edge cases. (Side note: I don't know why an application would do something on a key release instead of a press, but it would certainly break those theoretical applications to have key bindings sending false events like this.) If the key bindings were to be ordered, where Unless you can think of a better solution, I think ordered key bindings make the most sense here. It solved the other issue I'm having and adheres more closely to how most other applications handle keybindings. Thoughts? |
Could you please test branch key_release_events_fix (in PR #167) and tell me if it solves your issue? (at least the second part). As for ordered key bindings: making modifiers ordered might be hard (and I would find this pretty unintuitive to use personally), but triggering a hotkey only if the latest key press (/release) event is from a non-modifier key might be feasible. We could also add new syntax for the config to tell that a keybind must be ordered. For instance:
Or we could make ordered keybinds the default and unordered a special case. I think it would be better to keep it unordered by default to avoid breaking users' existing workflows and expectations. |
Checked out the branch. This does fix the issue of the key perpetually repeating itself even after the key is released. However, now the key combo is passed through, in full, to the underlying application as if I had pressed the keys the other way around. For example, in Firefox, pressed |
Version Information:
Describe the bug:
If keys are pressed in the reverse order specified in the config file, the event will still be triggered. In addition, the first key in the sequence will be repeated infinitely.
For example, if setting up the key combo like so:
When pressing the key combination
p + ctrl
, thectrl + p
command will be run. After the command is run, thep
key will continue to type itself infinitely.Expected behavior:
The
ctrl + p
command should not be triggered by ap + ctrl
key combo. In addition, thep
key should not continue to type itself infinitely.Actual behavior:
See above.
To Reproduce:
Setup a config file like the following:
Now start
swhkd
andswhks
normally:Now attempt to use the correct ordering of the key combo:
ctrl + p
; you should hear your system speak the work "hello". Conversely, try to press the keys in the opposite orderp + ctrl
, and notice what happens.First, the command will still be triggered.
Second, your
p
key will now type itself over and over and over again until you kill the process.Additional information:
N/A
The text was updated successfully, but these errors were encountered: