|
7a7a3b38
|
2024-02-14T09:47:15
|
|
keymap: Canonically map unmapped virtual modifiers
Traditionally, *virtual* modifiers were merely name aliases for *real*
modifiers (X *core* modifiers), e.g. `NumLock` was usually mapped to
`Mod2` (see `modifier_map` statement). Virtual modifiers that were never
mapped to a real ones had no effect on the keymap state.
xkbcommon already supports the concept of “pure” virtual modifiers, i.e.
virtual modifiers that are *encoded* using the full 32-bit range, not
just the first 8 bits corresponding to the real modifiers.
But until this commit, one had to declare such mapping *explicitly*:
e.g. `virtual_modifiers M = 0x100;`. This has at least two drawbacks:
- Numerical values may look quite arbitrary and are not user-friendly.
It’s OK in the resulting compiled keymap, but it requires careful sync
between sections when developing KcCGST files.
- If the modifier is *also* mapped *implicitly* using the traditional
`vmodmap`/`modifier_map`, then both mappings are OR-combined.
This patch enables to automatically map unmapped virtual modifiers to
their *canonical* mapping, i.e. themselves: their corresponding virtual
and real modifier masks are identical: `1u << mod_index`.
Since this feature is incompatible with X11, this is guarded by requiring
at least keymap text format **v2**.
Note that for now, canonical virtual modifiers cannot be used in an
interpret action’s `AnyOf()`. An interpret action for a canonical virtual
modifier must be `AnyOfOrNone()` to take effect:
virtual_modifiers APureMod, …;
interpret a+AnyOfOrNone(all) {
virtualModifier= APureMod;
action= SetMods(modifiers=APureMod);
};
The above adds a virtual modifier `APureMod` for keysym `a`. It will be
canonical iff it is not mapped implicitly.
|
|
0f89ad97
|
2025-06-09T19:26:13
|
|
dump: Always use numeric group indexes
The upcoming raise of the maximum groups count will require to use
numeric group indexes instead of the syntax `GroupN` if groups > 8.
Let’s not bother with handling two cases (group count ≤ 8 or > 8) and
always serialize group indexes as numeric values.
|
|
|
636b8b97
|
2025-03-19T14:11:52
|
|
test: Add merge mode tests for all the sections
The merge modes tests C file is now only generated locally, because it
is too large. The generator Python script requires Jinja2, so the test
is optional and depends on Jinja22 availability.
The test aim to be exhaustive with various combinations of a base and
an update:
- plain base + plain update, for every mode
- plain base + include (for every mode) update (every mode)
- single include (base +| update)
|
|
|
e09cbe66
|
2025-04-02T10:46:06
|
|
symbols: Fix handling of empty keys
Before this commit, the following symbols:
```c
xkb_symbols {
virtual_modifiers M1, M2;
key <A> {};
key <B> { [] };
key.vmods = M1;
key <C> {};
key <D> { vmods = M2 };
};
```
would be equivalent to:
```c
xkb_symbols {
virtual_modifiers M1,M2;
key <B> { [ NoSymbol ] };
};
```
`<B>` entry could be skipped but is harmless. However, `<C>` and `<D>`
are missing, which would lead to the mapping resolution of `M1` and
`M2` failing.
After this commit, it is equivalent to:
```c
virtual_modifiers M1,M2;
key <C> { vmods = M1 };
key <D> { vmods = M2 };
```
Empty keys are skipped entirely, but any explicit field:
- is taken into account: previously they would be skipped if there
were no group;
- forces the key to be printed at serialization.
|
|
|
6881fb32
|
2025-04-01T08:28:02
|
|
xkbcomp: Drop trailing NoSymbol and NoAction()
This brings us closer to what `xkbcomp` outputs. One should use
the explicit `VoidSymbol` instead of `NoSymbol`, in order to avoid
dropping empty levels.
This may affect keys that rely on an *implicit* key type. Example:
- Input:
```c
key <> { [a, A, NoSymbol] };
```
- Compilation with xkbcommon \< 1.9.0:
```c
key <> {
type= "FOUR_LEVEL_SEMIALPHABETIC",
[a, A, NoSymbol, NoSymbol]
};
```
- Compilation with xkbcommon ≥ 1.9.0:
```c
key <> {
type= "ALPHABETIC",
[a, A]
};
```
|
|
|
8ba5c453
|
2025-03-30T10:07:10
|
|
xkbcomp: Use section reference as default section name
Before this commit the following keymap:
```c
xkb_keymap {
xkb_keycode {};
};
```
would result in (boilerplate removed):
```c
xkb_keymap {
xkb_keycode "(unnamed)" {};
};
```
This is both useless and wasting allocation: section names are optional,
so we should just remove this default name altogether and keep it
undefined, as in the original keymap.
The situation is a bit different if there is an include, as for keymaps
created from RMLVO names. Before this commit, the following keymap:
```c
xkb_keymap {
xkb_keycode { include "evdev+aliases(qwerty)" };
};
```
would result in (boilerplate removed):
```c
xkb_keymap {
xkb_keycode "(unnamed)" { … };
};
```
With this commit we now follow the Xorg xkbcomp style by using the
section reference (the include string) as the *default* section name. So
the previous example would now result in:
```c
xkb_keymap {
xkb_keycode "evdev_aliases(qwerty)" { … };
};
```
which is useful to give a hint of the original include.
Note that if the original section had a name, it would preserve it:
```c
xkb_keymap {
xkb_keycode "test" { include "evdev+aliases(qwerty)" };
};
```
would compile to:
```c
xkb_keymap {
xkb_keycode "test" { … };
};
```
|
|
|
c85c9bdc
|
2025-01-27T17:15:06
|
|
symbols: Allow levels with different keysyms and actions counts
Contrary to groups, there is no reason for levels to restrict the same
count of keysyms and actions.
|
|
|
7036e46c
|
2025-01-13T15:20:47
|
|
symbols: Add tests for key merge modes (keysyms/actions)
This commit adds tests for merging various key configurations:
- With/without keysyms/actions
- Single/multiple keysyms/actions per level
We test all the merge modes for including a map (global) as well as
directly on the keys (local):
- default (global: include, local: implicit)
- augment
- override
- replace
The tests data are generated with:
- A Python script `scripts/update-merge-modes-tests.py` for keycodes
and symbols data. Use `--debug` for extra comments to help debugging.
The script can optionally generate C headers for alternative key
sequence tests, that were used before implementing golden tests.
The latter tests are not used anymore (duplicate with golden tests)
but their generator is kept for now, as they can still be useful for
debugging or writing similar tests.
- The `merge-modes` test generates its own keymap files for golden
tests, using: `build/test-merge-modes update`. It can also replace
them with the obtained output rather than the expected one using
`build/test-merge-modes update-obtained`, which is very useful for
debugging.
|