keysym --release is unreliable
#6456
Comments
|
I get the same thing. I use bindsym for my Mumble push-to-talk, and my config contains So it uses the button on the side of my mouse. If I hold that button down, left-click the mouse, then release that side button, Mumble keeps my mic activated. |
|
I'm looking through the code, and it appears my problem comes down to how modifiers are handled in bindings. I don't specify any modifiers with my button press, so if I'm holding down shift when I release the mouse button, the binding does not match. I believe the issue comes down to this line sway/sway/input/seatop_default.c Line 127 in 4baf845 Is this the right way to do it? Shouldn't we mask instead, so that a binding that accepts shift works if you're holding down both shift and ctrl, for example? Or that any set of modifiers is allowed if the binding doesn't specify any? |
Fixes swaywm#6456. Using XOR for checking modifiers means the full modifier state must be exactly the same. For example, a binding that requires Shift won't trigger if Shift *and* Ctrl are being pressed. Instead, using masking means a binding requiring Shift will be triggered if Shift is pressed, even if Ctrl is also pressed at the same time.
Fixes swaywm#6456. Using XOR for checking modifiers means the full modifier state must be exactly the same. For example, a binding that requires Shift won't trigger if Shift *and* Ctrl are being pressed. Instead, using masking means a binding requiring Shift will be triggered if Shift is pressed, even if Ctrl is also pressed at the same time.
Closes swaywm#6456. The i3 window manager ignores modifiers when a button is being released. Mimic this behaviour in Sway.
|
As far as pushing keys, it appears this is intended i3 behaviour, however releasing keys ignores modifiers. So combined with #6616, the best way to solve this is to (unfortunately) spam the sway config with every combination of modifier keys that you commonly press. For my mumble PTT use-case: It's not pretty, but it works. |
|
@emersion If I were to create a PR that adds a new flag to bindsym, maybe |
|
Unlikely, in general we're not adding new features unless i3 has them. |
This commit changes the "release binding" behavior to ignore foreign keypresses (pressed keys that are not part of a given release binding's definition) while still triggering the bound action when the original key from the binding is released. This, unless foreign keypresses match a different release binding, in which case the latter binding takes over. For instance, assuming a release binding is configured for <Mod>, a key corresponding to one of the possible modifier keys. The previous behavior for the following sequence was to trigger the action only for the following sequence: - <Mod>(press), <Mod>(release) but *not* in the following case: - <Mod>(press), <Tab>(press), <Tab>(release), <Mod>(release) With this commit both sequences trigger the bound action. This is useful to control external software by triggering possibly repeated actions, e.g. to navigate windows using <Mod> + <Tab> and triggering a final action when the <Mod> key is released (e.g. hiding a UI, reactivating LRU accounting, ...) Closes swaywm#6456
Sway Version: 1.6.1
Description:
bindsym --release Alt_R notify-send foobarIf any key is pressed before releasing the configured key, the bindsym command is not executed. The same bug happens if I bind to e.g. a letter key.
According to the discussion here, a similar issue was fixed back in 2018, so this might be a regression. My use case is that I would like to configure a push-to-talk button through sway that mutes the microphone when let go.
The text was updated successfully, but these errors were encountered: