For the sake of compatibility, this reintroduce some deleted keysyms and
postpone the effective deprecation of others.
xorgproto commit: fe12c5102762afcbf852e50dcbbdea2ef625570c
Also added tests for some canonical names.
- Update keymap to use reference keysym names.
- Fix x11comp test by handling old x11proto.
We need xkbcomp to be compiled with at least x11proto-dev 2023.2.
So we replace the unsupported keysyms with supported ones not
already in the keymap. This is kind of ugly, but it works. If we
ever want to restore the original keysyms with their supported names,
the substitute keysyms will be easy to spot.
xkbcomp only accepts the "Level" prefix for a level name for levels 1 to
8, but the keymap dumping code added it always, e.g. "Level15".
The plain integer, e.g. "8", "15" is always accepted, so just use that.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/113
Signed-off-by: Ran Benita <ran@unusedvar.com>
Reported-by: progandy
It's the same as no flags, so might as well not print it.
(In fact it is slightly harmful, because it actively *clears* the affect
flags, which might have been set in some other manner. But in practice
this cannot happen).
Signed-off-by: Ran Benita <ran234@gmail.com>
If the keycode range is smaller than 8 → 255, artifically widen it when
dumping the keymap as not to displease X.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
xkbcomp doesn't indent there, so it's easier to diff.
Also saves some horizontal space which is sorely needed when looking at
these files (especially the xkb_symbols).
Signed-off-by: Ran Benita <ran234@gmail.com>
These statements are pretty pointless for us; we don't restrict keycodes
like X does, and if someone writes e.g. maximum = 255 but only has 100
keys, we currently happily alloc all those empty keys. xkbcomp already
handles the case when these statements aren't given, and uses a computed
min/max instead. We should just always use that.
(Of course since keycodes/evdev currently uses almost all of the
keycodes in the range it declares, including 255, this doesn't save any
memory for the common user right now).
Signed-off-by: Ran Benita <ran234@gmail.com>
Group compatibility statements are like the following:
group 3 = AltGr;
This currently results in:
keymap->groups[2].mask = <real mod mapped from AltGr vmod>
And we don't do any thing with this value later. The reason it exists in
XKB is to support non-XKB clients (i.e. XKB support disabled entirely in
the server), which do not know the concept of "group", and use some
modifier to distinguish between the first and second keyboard layouts
(usually with the AltGr key). We don't care about all of that, so we can
forget about it.
One artifact of this removal is that xkb_map_num_groups no longer
works, because it counted through keymap->groups (this wasn't entirely
correct BTW). Instead we add a new num_groups member to the keymap,
which just hold the maximum among the xkb_key's num_groups. This also
means we don't have to compute anything just to get the number of
groups.
Signed-off-by: Ran Benita <ran234@gmail.com>
This field is used in conjunction with key behaviors, which we don't
support since c1ea23da5. This is also unused in xkeyboard-config.
Signed-off-by: Ran Benita <ran234@gmail.com>
Recreate the old test/dump scenario, where we test the following map:
- rules: evdev
- model: pc104
- layout #1: us
- layout #2: ru
- layout #3: ca(multix)
- layout #4: de(neo)
This is ever so slightly altered from the xkbcomp output; running the
following:
setxkbmap -rules evdev -model pc105 -layout us,ru,ca,de -variant
,,multix,neo -print | xkbcomp -xkb - -
will give you a map with RCTL added to the modifier_map for both Control
and Mod3. Running the output through xkbcomp -xkb - - again, will give
you RCTL only added to Mod3.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
As a map will implicitly go to level one unless explicitly mentioned
otherwise, remove all explicit =Level1 mappings, except for those with
preserve entries.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Bring the input file into line with recent changes to the dump output,
so we're as close as we can get to a round trip.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Pierre Le Marre
Ran Benita
Ran Benita
Daniel Stone