Binds consume keyup of other keys in game windows

[raku-cat]

Not really sure which part of the stack the issue is coming from, but to reproduce:

• Bind F3 to pass dispatcher for discord like so: bindn = , F3, pass, class:^(equibop)$

1. Walk around/move map/etc in a game holding W key (can be any key technically)
2. Press and release F3
3. Release W key
4. You are stuck walking forward or whatever action was caused by holding W or whatever other key you held until you press the key again

Could technically work with any bind and any input in the game, for example if I hold W and then press mod+r which is bound to open rofi, the same thing happens, the game acts as if the last input was held down until you click it again.

I've tested with wev and xev, wev shows the keyup happening on the w, xev shows repeated keydown and keyrelease for when a key is held so its a bit hard to tell, sometimes when you press F3 it shows the last line as keydown or keyrelease for W, but the line stops repeating in any case. It seems like a quirk with how games consume inputs, and possibly xwayland only.

Searching around the best I could find was this commit f242f94 though I'm not sure if its related.

[raku-cat]

Okay so on further investigation I found that this is actually a very narrowly scoped issue.
Discord desktop running wayland native of course is unable to do keybinds at all, as the wiki notes, one has to run it under xwayland, any binds passed to it DO NOT cause any games to miss the keyup, it works fine.
On the other hand, vesktop and its derivatives (equibop etc), when ran in wayland native mode are able to receive keybinds from pass, but cause the above mentioned issue. When ran under xwayland, it no longer is able to receive any binds from the pass dispatcher, and attempting to use those binds even though they don't work, doesn't cause the issue.

To summarize(edited):
Discord desktop running wayland native - binds don't work in the app/NA
Discord Desktop running under xwayland - is able to receive pass dispatcher binds without causing games to not receive a keyup.
Vesktop running wayland native - is able to receive pass dispatcher binds but causes xwayland games to not receive a keyup. Wayland native games or ones using proton wayland, even with a bindn band, will immediately get a keyup for whatever the last key was, so the character will instantly stop walking the direction you held until you release the direction key and press it again.
Vesktop running under xwayland - doesn't react to pass dispatcher binds, required use of sendshortcut, when pass dispatcher is used it doesn't cause any issues with games but doesn't work, sendshortcut works but only within wayland windows/wayland native games, and pressing the bind while walking again makes you stop in place, seeming to send an immediate keyup until the directional key is released and pressed again.

I'll have to potentially test with more apps like OBS and see how consistent the issue is, but it seems like an issue isolated to just vesktop it would seem.

[raku-cat]

Okay, after additional testing, my first thought was maybe vesktop was doing something weird with window focusing since it doesn't have global shortcuts available, but I've just tested with obs and it actually exhibits the same exact behavior BUT only in wayland mode (QT_QPA_PLATFORM=wayland) If I changed to x11 mode (QT_QPA_PLATFORM=xcb), it was again able to work without causing the issue described above.
Testing more with bind flags, I found that neither n or p had an impact on the issue, though n was needed for it to work in some instances.
Something I hadn't tried before was to run vesktop in x11 mode (ELECTRON_OZONE_PLATFORM_HINT= vesktop), the pass dispatcher doesn't work with it at all, though I suppose that can't be helped, the sendshortcut one does though, but only when the mouse is focused on a wayland client window, anything running in xwayland doesn't pass the input, I still haven't gotten a chance yet to test a game with proton wayland enabled.

[raku-cat]

Done more testing with wayland/xwayland games, and vesktop wayland/xwayland, etc etc, first comment is edited with summary of interactions.

[raku-cat]

Okay well I've tested more and realized I've been wrong about a few things in the last couple post that I are a little important, so I feel it necessary to re-summarize here:

• Case 1:
  • OBS running under xwayland with QT_QPA_PLATFORM=xcb, proton game running under xwayland, bound with bind = , F1, pass, class:^(obs)$
    • Keybind works without issue, passes to obs and doesn't disrupt game walking
    • bind with or without n does not seem to make much difference, makes things act a little inconsistent when game or other apps have something that uses F1, but it does work with or without it.
    • Behaves the same using sendshortcut dispatcher.
• Case 2:
  • OBS running under xwayland, proton game running under wayland with PROTON_ENABLE_WAYLAND=1, bound with bind = , F1, pass, class:^(obs)$
    • Keybind works, passes to obs, but causes character to stop walking the direction held in place and doesn't move in the direction again until you release the direction key you were holding and press it again.
    • bind with or without n does not seem to make much difference, makes things act a little inconsistent when game or other apps have something that uses F1, but it does work with or without it.
    • Behaves the same using sendshortcut dispatcher.
• Case 3:
  • OBS running under wayland with QT_QPA_PLATFORM=wayland, proton game running under xwayland, bound with bind = , F1, pass, class:^(com.obsproject.Studio)$
    • Keybind works, passes to obs but causes character to continue walking the direction held even after key release, and doesn't stop until you press and release the direction key you were holding.
    • bind with or without n does not seem to make much difference, makes things act a little inconsistent when game or other apps have something that uses F1, but it does work with or without it.
    • Behaves the same using sendshortcut dispatcher.
• Case 4:
  • OBS running under wayland with QT_QPA_PLATFORM=wayland, under wayland with PROTON_ENABLE_WAYLAND=1, bound with bind = , F1, pass, class:^(com.obsproject.Studio)$
    • Keybind works, passes to obs, but causes character to stop walking the direction held in place and doesn't move in the direction again until you release the direction key you were holding and press it again.
    • bind with or without n does not seem to make much difference, makes things act a little inconsistent when game or other apps have something that uses F1, but it does work with or without it.
    • Behaves the same using sendshortcut dispatcher.

Discord desktop is pretty straightforward, binds don't work at all when ran under wayland, even with the window directly focused, as noted in the wiki, running under xwayland allows them to work at all, the rest of it lines up pretty closely to the above cases, games under xwayland have 0 issue at all, games running under wayland you stop moving in place.

Vesktop is its own bag of worms, you need to actually in the app rebind your key you use between running under wayland and xwayland, perhaps the scancode reads different, I don't know.
The only dispatcher that works consistently at all is sendshortcut, when you use pass it doesn't work at all initially, you have to be using sendshortcut first, send it the key a couple times while the mouse is focused on wayland clients, and then if you switch the bind to using pass, it works until the second you focus an xwayland client, and then you have to repeat the process.
The sendshortcut dispatcher, while it does work without shenanigans, does not work when focused on an xwayland client, but resumes working once you focus another wayland client.
Given that xwayland vesktop binds don't function with xwayland clients at all, the only test case to be had is with running games wayland native, and it does the same thing as in Case 4 and Case 2 with both sendshortcut and when I do the trick to get pass working.
Vesktop running under wayland with a game running under xwayland, when using pass or sendshortcut falls under Case 3, and if the game is running under wayland native, falls under Case 4 and Case 2.

Basically, pass/sendshortcut binds only work properly with games with xwayland -> xwayland and even then it's a a bit of a crapshoot, with some xwayland clients (vekstop) not being able to read pass binds while focused on another xwayland client making that pointless anyway, and any other interaction inconsistent at best.