If our current approch without xkbcommon translation does not match any
mapping on a key event attempt to match the translated keysym as well.
This makes e.g. the keypad number keys (e.g. KP_1) work intuitively as
they may require translation with numlock active.
The reason we stopped doing this in I7c02ebcbc was due to layout where
e.g. Super+Shift+Space is translated as Space with the Shift modifier
consumed, thereby conflicting with a separate mapping for Super+Space.
This should not be a issue anymore though as we now only run a maximum
of one mapping per key event and we attemt to match mappings without
xkbcommon translation before attempting with translation.
When checking keys for matching mappings, previously we did two checks:
1. Keysyms translated by xkb.
2. Raw keysyms
This commit removes the first check, so only the second is checked.
We're doing this because of strange behavior that xkb shows for some
layouts and keys. When pressing `Shift Space` on some layouts (Swedish
among others), xkb reports `Shift` as consumed. This leads to the case
that we cannot distinguish between `Space` and `Shift Space` presses
when doing a correct translation with xkb.
e.g. `riverctl map -layout 0 normal Super Y spawn foot`
When this mapping is checked against a pressed key, layout 0 will be used to translate the pressed key instead of the currently active layout.
The number denotes to an index of the layouts set with
`XKB_DEFAULT_LAYOUT`.
Repeating mappings are created using the -repeat option to the map
command:
% riverctl map normal $mod+Mod1 K -repeat move up 10
- repeating is only supported for key press (not -release) mappings
- unlike -release, -repeat does not create distinct mappings: mapping a
key with -repeat will replace an existing bare mapping and vice-versa
Resolves#306
Isaac Freund
Peter Kaplan
Keith Hubbard
Isaac Freund
Marten Ringwelski
Marten Ringwelski