This repository has been archived by the owner on Nov 1, 2021. It is now read-only.
rootston: xkb/keyboard handling for keybinds is wonky to broken. #393
Comments
|
Ok, so after I took a look at the keycodes that result in my keysyms, they are way to different to just mash the keybinds together. To support both approaches (which IMO would be the way to go) can't be done by just matching them over the same set of keybinds without causing false positive troubles. This looks like we need 2 sets of keybinds for this, which isn't really user friendly 👎 |
|
So after @emersion brought up the idea of a secondary state on irc, I digged into xkb-common docs and found: xkb_keymap_key_get_syms_by_level. |
Ongy
pushed a commit
to Ongy/wlroots
that referenced
this issue
Nov 7, 2017
As mentioned in swaywm#393 keybinds did't trigger / were checked with "odd" keys and modifiers. This commit sends the keycode through two paths, one to get the keycode and modifiers *after* xkb handles them, a secondary path to get a "raw" keysym without modifiers and then add the modifiers rootston knows about. This will result in the `[Alt]+[Shift]+2` combination I mention earlier going through the keybind detection twice. 1) `[Alt]+[at]` 2) `[Alt]+[Shift]+2` When either combination is found, the appropriate keybind is executed. The xkb handled version will be prefered over the "raw" version.
Ongy
pushed a commit
to Ongy/wlroots
that referenced
this issue
Nov 7, 2017
As mentioned in swaywm#393 keybinds did't trigger / were checked with "odd" keys and modifiers. This commit sends the keycode through two paths, one to get the keycode and modifiers *after* xkb handles them, a secondary path to get a "raw" keysym without modifiers and then add the modifiers rootston knows about. This will result in the `[Alt]+[Shift]+2` combination I mention earlier going through the keybind detection twice. 1) `[Alt]+[at]` 2) `[Alt]+[Shift]+2` When either combination is found, the appropriate keybind is executed. The xkb handled version will be prefered over the "raw" version.
Merged
ddevault
pushed a commit
to swaywm/rootston
that referenced
this issue
Aug 8, 2019
As mentioned in swaywm/wlroots#393 keybinds did't trigger / were checked with "odd" keys and modifiers. This commit sends the keycode through two paths, one to get the keycode and modifiers *after* xkb handles them, a secondary path to get a "raw" keysym without modifiers and then add the modifiers rootston knows about. This will result in the `[Alt]+[Shift]+2` combination I mention earlier going through the keybind detection twice. 1) `[Alt]+[at]` 2) `[Alt]+[Shift]+2` When either combination is found, the appropriate keybind is executed. The xkb handled version will be prefered over the "raw" version.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The keyboard handling in rootston is a bit weird.
I added my own debug output which can be seen at xkb_debug.
When I press
[Alt]+[Shift]+2I get the output:The mods here are the modifiers used. 8 is Alt, 1 is Shift, and they are xored, so 9 is both.
This prevents binding to the example key combiniation I pressed, since there's never a
2pressed for the keybinds.A workaround could be to bind to
[Alt]+[Shift]+[at]. But from how I understand xkb docs consumed modifiers should be removed before binding, so we could bind[Alt]+[at].Another way to go about this, would be to use the modifiers kept in
wlr_keyboardand the event keycode directly.The main issue with this I can see is that e.g. the [at] here could not be used (or more serious the SWITCH_VT would have to be hardcoded).
Maybe the best approach would be to go through both approaches to figure out what to match.
Edit: I tested this with rootston and waymonad on X backend and waymonad on DRM. My code in waymonad is mostly a translation of the rootston code into Haskell, so I doubt rootston behaves any different on the other backend.
The text was updated successfully, but these errors were encountered: