|
fcc95275
|
2025-10-17T11:56:48
|
|
xkbcomp: Rename fallback key type to ONE_LEVEL
This is the name of this canonical key type in the XKB protocol.
|
|
|
31900860
|
2025-09-30T13:05:43
|
|
keymap: Make serialization of unused items optional
When compiling a keymap from text, some items may be unnecessary in the
final keymap, i.e. they do not affect the keymap behavior:
- unused key types;
- unused keysym interpretations.
Deactivate the serialization of these items *by default* and add a new
flag to enable it for debugging.
|
|
|
345f0c67
|
2025-09-24T20:28:00
|
|
keymap: Make pretty-printing optional
This greatly improves the keymap serialization: 1.22× speedup and
about 5% less allocations. The resulting keymap is also a bit faster
to parse.
Another improvement is that it eases keysym names migrations (removal
and additions) by using only keysym numeric values. This requires some
care, i.e. `NoSymbol` must be serialized with its name and not its
value 0x0, because xkbcomp and libxkbcommon < 1.12 would interpret the
numeric value as `XKB_KEY_0`.
|
|
|
181bc9ec
|
2025-09-24T20:10:00
|
|
xkbcomp: Fix numeric keysym parsing
Keysyms written as single decimal digits are interpreted in the range
`XKB_KEY_0`..`XKB_KEY_9`, consistent with the general interpretation
`<name>` -> `XKB_KEY_<name>`, e.g.:
- `1` → `XKB_KEY_1`
- `a` → `XKB_KEY_a`
However, before this commit integers in the range 0..9 in *any format*
were treated as digit keysyms, which is wrong if the number is written
with 2+ characters. E.g. the following were wrongly treated as the
keysym digit `XKB_KEY_1`: `01`, `0x1`.
Fixed by introducing a new token type to handle this corner case.
This is a preparatory work to enable serializing keysyms as numbers.
|
|
|
b09aa7c6
|
2025-09-21T19:05:27
|
|
xkbcomp: Drop the key name LUT after compilation
Since it is not usual to lookup for keys by their names, we can drop it
to save allocations (about 2KiB on usual keymaps).
We use an union of the LUT with the aliases array and try to reuse the
memory allocated by the LUT. We only do so if the space is trivially
available: either before the first alias entry or after the last entry,
which is possible in practice, so that we get the best performance. Else
we allocate a new array.
|
|
|
b833d193
|
2025-09-15T14:07:05
|
|
xkbcomp: Use keycode name LUT for xkb_keycodes
Replace linear search of keycode names with O(1).
Given that:
- the number of atoms is usually < 1k;
- the keycode section usually appears first;
then the first atoms will be mostly the keycodes and their aliases,
so we can achieve O(1) lookup of the key names by using a simple
atom → keycode array.
The LUT will be used also to process `xkb_symbols` for further speedup.
On my setup I get a 1.039x speedup at the costs of less than 1%
additional allocations.
|
|
|
1eb34399
|
2025-08-20T22:52:17
|
|
xkbcomp: Enable using the whole keycode range
In 502e9e5bff3781cba09f3b33ec030522b549f4e5 we restricted the supported
keycode range in order to avoid memory exhaustion and inefficient storage
in sparse arrays. This solution enabled keycodes up to 0xfff, which
seemed good enough at the time.
However there are huge keycodes in use in the wild, e.g. in WebOS.
So let’s enable the whole keycode range by using 2 methods of storage:
- “Low” keycodes (≤ 0xfff): stored contiguously as before at indexes
[0..num_keys_low); fast O(1) access.
- “High” keycodes (> 0xfff): stored noncontiguously at indexes
[num_keys_low..num_keys); slow access via binary search.
|
|
|
b21a58d0
|
2025-07-01T14:52:11
|
|
Add support for all level indices to LevelN constants
Note that serialization must use numbers instead of names for levels > 8,
to ensure backward compatibility.
|
|
|
e73d1a4d
|
2025-07-01T13:05:44
|
|
Add support for all layout indices to GroupN constants
This commit enables to use the pattern `Group<INDEX>` for any valid
group index `<INDEX>`.
Note that the original code in xkbcomp allows constants up to
`Group8`, but then will fail if the resulting group is > 4.
There does not seem to be any use case for this for such “feature”;
it seems rather to be a relic from times were the 4-groups limit
was not hopelessly fixed in X.
So for consistency in our code base, starting with this commit we now
disallow `Group5`..`Group8` for keymap format v1, since it is limited
to 4 groups.
Also fixed a regression in the serialization of group action, when
the group is relative.
|
|
|
84914512
|
2025-07-01T18:37:22
|
|
chore: Rename indexes to indices
Before this commit there was a mix between the two forms.
While “indexes” is correct, “indices” is more usual and also
the historical form used in this project.
|
|
|
05d13d5f
|
2025-06-26T16:58:50
|
|
include: Fix infinite loop
Fixed including an absolute path with no default map triggering an
infinite loop.
|
|
|
d192b3b6
|
2025-06-19T21:57:46
|
|
keymap: Add option `unlockOnPress` for SetMods()
It enables e.g. to deactivate `CapsLock` *on press* rather than on
release, as in other platforms such as Windows.
It fixes a [18-year old issue] inherited from the X11 ecosystem, by
extending the [XKB protocol key actions].
As it is incompatible with X11, this feature is available only using the
keymap text format v2.
[18-year old issue]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/74
[XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
|
|
|
ee87f6ed
|
2025-06-21T19:28:53
|
|
state: Fix broken latch not honoring clearLocks=no
Before this commit, breaking a latch (modifier & group) would always
clear locks, even if `clearLocks=no`.
|
|
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.
|
|
|
69c3d257
|
2025-06-17T16:43:05
|
|
keymap: Add parameter `latchOnPress` for LatchMods()
Some keyboard layouts use `ISO_Level3_Latch` or `ISO_Level5_Latch` to
define “built-in” dead keys:
- they do not rely on the installation of custom Compose file;
- they do not clash with other layouts.
However, layout projects usually want the exact same behavior on all OS,
but the XKB latch behavior (often misunderstood) also acts as a *set*
modifier, which is not expected.
The usual behavior of a dead key on Linux, macOS and Windows is:
- latch on press;
- deactivate as soon as another (non-modifier) key is pressed.
Added the parameter `latchOnPress` to `LatchMods()` to enable the
aforementioned behavior.
As it is incompatible with X11, this feature is available only using the
keymap text format v2.
[XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
|
|
|
c58c7df1
|
2025-06-17T21:05:08
|
|
Serialize multiple actions per level to VoidAction() in v1 format
When using `XKB_KEYMAP_FORMAT_TEXT_V1`, multiple actions per level are now
serialized using `VoidAction()`, in order to maintain compatibility with X11.
|
|
|
ee50e0c9
|
2025-06-12T20:14:50
|
|
keymap: Add option `unlockOnPress` for LockMods()
It enables e.g. to deactivate CapsLock on press rather than
on release, as in other platforms such as Windows.
The specification of `LockMods()` is changed to:
- On key *press*:
- If `unlockOnPress` is true and some of the target modifiers were
*locked* before the key press, then unlock them if `noUnlock` false.
- Otherwise:
- add target modifiers to *depressed* modifiers;
- if `noLock` is false, add target modifiers to the *locked*
modifiers.
- On key *release*:
- If `unlockOnPress` is true and triggered unlocking on key press, do
nothing.
- Otherwise:
- remove modifiers from the *depressed* modifiers, if no
other key that affect the same modifiers is down;
- if `noUnlock` is false and if any target modifiers was locked before
the key press, *unlock* them.
It fixes a [12-year old issue] inherited from the X11 ecosystem,
by extending the [XKB protocol key actions].
As it is incompatible with X11, this feature is available only using the keymap
text format v2.
[12-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/312
[XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
|
|
|
d9d82355
|
2025-06-12T09:13:27
|
|
keymap: Add option `lockOnRelease` for LockGroup()
It enables to use e.g. the combination `Control + Shift` *alone* to
switch layouts, while keeping the use of `Control + Shift + other key`
(typically for keyboard shortcuts).
The specification of `LockGroup()` is changed to:
- On key *press*:
- If `lockOnRelease` is set, then key press has no effect.
- Otherwise:
- if the `group` is absolute, key press sets the *locked* keyboard group to
`group`;
- otherwise, key press adds `group` to the *locked* keyboard group.
In either case, the resulting *locked* and *effective* group is brought back
into range depending on the value of the `GroupsWrap` control for the keyboard.
- On key *release*:
- If `lockOnRelease` is not set, then key release has no effect.
- Otherwise, if any other key was *pressed* after the locking key, then
key release has no effect.
- Otherwise, it has the same effect than a key press *without* `lockOnRelease`
set.
This is really useful for people coming from other platforms, such as
Windows.
It fixes a [20-year old issue] inherited from the X11 ecosystem, by
extending the [XKB protocol key actions].
As it is incompatible with X11, this feature is available only using the keymap
text format v2.
[20-year old issue]: https://gitlab.freedesktop.org/xorg/xserver/-/issues/258
[XKB protocol key actions]: https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Key_Actions
|
|
|
c4c531da
|
2025-06-17T11:43:50
|
|
rules: Add layout-specific options for RMLVO builder
Change the signature of `xkb_rmlvo_builder_append_layout()` to accept
an array of options.
Also add tests for layout-specific options.
|
|
|
52a4d9b0
|
2025-06-17T11:03:12
|
|
rules: Require layout or variant to enable %i expansion
Before this commit, the following rule would always match:
! model = symbols
* = s:%i
and set symbols to `s:1`, but the `:%i` is aimed to be used only when
the rules header specifies the layout or the variant.
Let’s be strict and disallow matching this kind of buggy rule. Emit
an error message so that we can detect it.
|
|
|
ac9cd053
|
2025-06-11T19:00:47
|
|
test: Check extended layout indexes
|
|
|
7f39be25
|
2025-06-10T15:46:45
|
|
test: Use explicit keymap output format for test_compile_output()
|
|
|
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.
|
|
|
9951184e
|
2025-05-10T10:15:54
|
|
actions: Properly reset type to NoAction on error
If we do not reset the type, the action may lready have been initialized
to with a default action and thus will not be ignored.
|
|
|
22d27277
|
2025-05-10T10:12:31
|
|
actions: Reject arguments if they are not expected
`NoAction`, `VoidAction` and `TerminateServer` do not accept arguments.
|
|
|
d239a3f0
|
2025-05-11T11:42:20
|
|
actions: Improve unsupported legacy X11 actions handling
- Display a warning
- Document drawbacks of degrading to `NoAction()`
|
|
|
b4c89600
|
2025-05-09T15:15:10
|
|
actions: Add VoidAction(), mirroring NoSymbol/VoidSymbol.
Added `VoidAction()` action to match the keysym pair
`NoSymbol` / `VoidSymbol`.
It enables overriding a previous action and breaks latches.
This is a libxkbcommon extension. When serializing it will be converted to
`LockControls(controls=none,affect=neither)` for backward compatibility.
We cannot serialize it to `NoAction()`, as it would be dropped in e.g.
the context of multiple actions.
|
|
|
551cca2a
|
2024-12-03T10:12:03
|
|
state: Add server API for updating latched and locked mods & layout
Up to now, the “server state” `xkb_state` API only offered one entry
point to update the server state – `xkb_state_update_key`, which reflects
the direct keyboard keys state. But some updates come out-of-band from
keyboard input events stream, for example, a GUI layout switcher.
The X11 XKB protocol has a request which allows for such updates,
`XkbLatchLockState`[^1], but xkbcommon does not have similar
functionality. So server applications ended up using
`xkb_state_update_state` for this, but that’s a function intended for
client applications, not servers.
Add support for updating the latched & locked state of the mods and
layout. Note that the depressed states cannot be updated in this way --
XKB does not expect them to be updated out of band.
[^1]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Querying_and_Changing_Keyboard_State
Fixes: #310
Signed-off-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Ran Benita <ran@unusedvar.com>
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
|
|
|
e00a5e83
|
2025-05-07T16:10:04
|
|
Add tests for pure virtual modifiers
|
|
|
c2d3694b
|
2025-05-06T07:01:01
|
|
xkbcomp: Do not discard extra bits in vmod masks
Since we accept numeric values for the vmod mask in the keymap, we may
have extra bits set that encode *no* real/virtual modifier. Keep them
unchanged for consistency.
E.g. the following keymap:
xkb_keymap {
xkb_keycodes { <a> = 38; };
xkb_symbols {
virtual_modifiers X = 0xf0000000;
key <a> { [ SetMods(mods = 0x00001100) ] };
};
};
would compile to:
xkb_keymap {
xkb_keycodes { <a> = 38; };
xkb_symbols {
virtual_modifiers X = 0xf0000000;
// Internal state
key <a> { [ SetMods(mods = 0xf0001000) ] };
// Serialization
key <a> { [ SetMods(mods = 0x00001100) ] };
};
};
|
|
|
d5b779e1
|
2025-05-06T21:07:28
|
|
keymap: Fix empty compat interpretation map serialization
X11’s `xkbcomp` requires at least one compat interpretation entry.
|
|
|
87f9ac76
|
2025-05-06T21:02:23
|
|
keymap: Fix empty compat interpretation statement serialization
Statements such as `interpret VoidSymbol {};` can cannot be parsed by
X11’s `xkbcomp`.
Fixed by using a dummy action.
|
|
|
230b6a6a
|
2025-05-06T14:35:26
|
|
Fix key type map entry with unbound vmod not ignored
Currently we only ignore key type map entries with non-zero mods and
with a zero modifier mask. However, the XKB protocol states ([source]):
> Map entries which specify unbound virtual modifiers are not considered.
So we currently handle `map[Unbound]` key type map entries (all modifiers
unbound) but not `map[Bound+Unbound]` entries (mix of bound and unbound
modifiers).
Fixed by properly checking unbound modifiers on each key type map entry.
This also fixes a test that was accidentally passing.
[source]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#:~:text=Map%20entries%20which%20specify%20unbound%20virtual%20modifiers,not%20considered
|
|
|
cd512b8f
|
2025-05-02T19:21:09
|
|
x11: Fix capitalization transformation
|
|
|
9b0b8c68
|
2025-04-15T19:53:28
|
|
xkbcomp: Stricter handling of default map include
Before this commit, including a *default* map, i.e. without an explicit
section name (e.g. `include "au"` vs `include "au(basic)"`) would match
the first section of the first matching file in the XKB include paths,
even if this section is not an *explicit* default map (i.e. tagged with
`default`) but an *implicit* default map (i.e. the first map of the
file, i.e. a weak match).
It makes user configuration risky: say a user wants to create a custom
version `au(custom)` of the `au` layout:
- `./config/xkb/symbols/au`: custom layout in section “custom”.
- `/usr/share/X11/xkb/symbols/au`: system layout, with *default* section
“basic”.
In this setup *any* layout that imports the default map from `au` would
in fact import the *implicit* default map `au(custom)` instead of the
*explicit* default map `au(basic)`.
This incorrect behavior may thus break setups with multiple layouts.
This is especially true for symbols files such as: `pc`, `us` or `latin`.
Fixed by trying harder to found the exact default map, defaulting to the
old behavior (weak match) only if no *explicit* default map (exact match)
has been found in the XKB include paths.
|
|
|
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)
|
|
|
a1e595e7
|
2025-04-11T11:13:25
|
|
rules: Fix merging KcCGST values in layout order
When using layout index ranges (e.g. special indexes “any” or “later”),
the rules still match following the order in the rules file, so layout
indexes may match without following their natural order. So the resulting
KcCGST value should not be merged with the output until reaching the end
of the rule set.
Because the rule set may also involve options, it may match multiple
times for the *same* layout index. So these multiple matches should not
be merged together either, until reaching the end of the rule set.
When reaching the end of the rule set, for each KcCGST component the
pending values are then merged: for each layout, for each KcCGST value
in the corresponding sequence, merge with the output.
---
Example:
! model = symbols
* = pc
! layout[any] option = symbols
C 1 = +c1:%i
C 2 = +c2:%i
B 3 = skip
B 4 = +b:%i
The result of RMLVO
{layout: "A,B,C", options: "4,3,2,1"}
is:
symbols = pc+b:2+c1:3+c2:3
- `skip` was dropped because it has no explicit merge mode;
- although every rule was matched in order, the resulting order of the
symbols follows the order of the layouts, so `+b` appears before `+c1`
and `+c2`.
- the relative order of the options for layout C follows the order
within the rule set, not the order of RMLVO.
Before this commit, the result would have been:
symbols = pc+c1:3+c2:3+b:2
|
|
|
66f71890
|
2025-03-31T08:01:29
|
|
symbols: Enable writing keysyms list as UTF-8 strings
Each Unicode code point of the string will be translated to their
respective keysym, if possible. An empty string denotes `NoSymbol`.
When such conversion is not possible, this will raise a syntax error.
This introduces the following syntax:
```c
// Empty string = `NoSymbol`
key <1> {[""]}; // NoSymbol
// Single code point = single keysym
key <2> {["é"]}; // eacute
// String = translate each code point to their respective keysym
key <3> {["sßξك🎺"]}; // {s, ssharp, Greek_xi, Arabic_kaf, U1F3BA}
// Mix string and keysyms
key <4> {[{"ξ", Greek_kappa, "β"}]}; // { Greek_xi, Greek_kappa, Greek_beta}
```
It can also be used wherever a keysym is required, e.g. in `interpret`
and `modifier_map` statements. In these cases a single keysym is expected,
so the string should contain *exactly one* Unicode code point.
|
|
|
ead3ce77
|
2025-03-28T21:44:27
|
|
scanner: Enable LRM and RLM marks for BiDi text
Enable displaying bidirectional text in XKB files using:
- U+200E LEFT-TO-RIGHT MARK
- U+200F RIGHT-TO-LEFT MARK
We now parse these marks as white space. As such, they are dropped;
note that a later serialization may not display correctly without
the marks, although it will parse.
References:
- https://www.w3.org/International/articles/inline-bidi-markup/uba-basics
- https://www.w3.org/International/questions/qa-bidi-unicode-controls
- https://www.unicode.org/reports/tr31/#Whitespace
- https://www.unicode.org/reports/tr55/
|
|
|
bc3e464b
|
2025-04-09T12:35:05
|
|
keysyms: Fix Unicode handling
- `xkb_utf32_to_keysym`: Allow [Unicode noncharacters]. There is no
requirement to drop them and this would be the only function of our
API doing so.
From the Unicode Standard 16.0, section 23.7 “Noncharacters”:
> Applications are free to use any of these noncharacter code points
> internally. They have no standard interpretation when exchanged
> outside the context of internal use. However, they are not illegal
> in interchange, nor does their presence cause Unicode text to be
> ill-formed.
> If a noncharacter is received in open interchange, an application is
> not required to interpret it in any way. It is good practice,
> however, to recognize it as a noncharacter and to take appropriate
> action, such as replacing it with `U+FFFD` REPLACEMENT CHARACTER,
> to indicate the problem in the text.
The key part is:
> an application is not required to interpret it in any way
Since we handle the reverse conversion with `xkb_keysym_to_utf32` just
fine, I do not see a good motivation to keep this asymmetry. This is
the only function with a special case for these code points.
- `xkb_keysym_from_name`:
- Unicode format `UNNNN`: allow control characters C0 and C1 and use
`xkb_utf32_to_keysym` for the conversion when `NNNN < 0x100`, for
backward compatibility.
- Numeric hexadecimal format `0xNNNN`: *unchanged*. Contrary to the
Unicode format, it does not normalize any keysym values in order to
enable roundtrip with `xkb_keysym_get_name`.
Also added tests to ensure various properties and consistency.
Note about *surrogates*: they are valid valid *code points* but invalid
Unicode *scalar values*, i.e. they cannot be encoded in any Unicode
encoding form (UTF-8, UTF-16, UTF-32). So their corresponding Unicode
keysyms are valid, but:
- cannot be used as input of `xkb_keysym_to_utf32` nor `xkb_keysym_to_utf8`
- cannot result as output of `xkb_utf32_to_keysym`.
Otherwise they are valid e.g. in the Unicode keysym notation.
[Unicode noncharacters]: https://en.wikipedia.org/wiki/Universal_Character_Set_characters#Noncharacters
|
|
|
5e557040
|
2025-04-09T11:17:00
|
|
xkbcomp: Fix Unicode escape sequence
While the previous code correctly rejected malformed sequences such as
`\u{` (incomplete) or `\u{123x}`, it should try to consume as much input
as possible until reaching the corresponding closing `}` within the
string. Else we can get leftovers and the error message does not
reference the whole malformed sequence.
Also added further tests with surrogates and noncharacters.
|
|
|
36442baa
|
2025-04-03T15:01:46
|
|
xkbcomp: Support multiple actions in interpret
Before this commit we supported multiple actions per level, but not in
*interpret* statements. Let’s fix this asymmetry, so we can equivalently
assign all actions sets either implicitly or explicitly.
|
|
|
6d4cc135
|
2025-04-05T13:39:30
|
|
xkbcomp: Escape ASCII control characters
|
|
|
3d79f459
|
2025-03-29T11:46:34
|
|
xkbcomp: Add Unicode code point escape sequence \u{NNNN}
Unicode code point escape sequences `\u{NNNN}` are replaced with the
UTF-8 encoding of their corresponding code point `U+NNNN`, if legal.
Supported Unicode code points are in the range `1‥0x10ffff`.
Note that we will reject the `U+0000` NULL code point, as we reject it
in the octal escape sequence `\0`.
This is intended mainly for the upcoming feature to write keysyms as
UTF-8 encoded strings. It can be used for various reasons:
- avoid encoding issues;
- avoid issue with font rendering (e.g. Asian scripts);
- make white space or zero-width characters more readable.
|
|
|
7d91a753
|
2025-03-29T12:24:39
|
|
xkbcomp: Enable xkbcomp-style octal escape sequences
Xorg xkbcomp only parses octal sequences with `\0`, while xkbcommon
does not force the `0` prefix of the numeric part. However, we only
parsed up to to 3 digits, which does not allow to parse e.g. `\0377`
while `\377` parses fine.
Fixed by parsing up to 4 octal digits, while checking the result fits
into a byte.
|
|
|
aa8b572e
|
2025-03-29T12:04:26
|
|
keymap serialization: Ensure escaping relevant chars
Previously we would write characters without any escaping in some
cases (e.g.: names of indicators, types and groups). E.g. the string
"new\nline"
would be serialized as:
"new
line"
which would raise a syntax error if parsed.
Fixed by escaping any string that was not escaped after parsing (e.g.
the section names are safe already).
|
|
|
d2f7b9cd
|
2025-04-04T17:29:35
|
|
rules: Do not use strto* parsers
|
|
|
d5a91fa9
|
2025-04-04T16:38:16
|
|
xkbcomp: Use custom parsers instead of strtol*
The use of `strtol*` functions was already restricted due to its
slowness and its capacity to parse other stuff than digits (e.g.
signs and spaces).
There is also another *big* limitation: it requires a NULL-terminated
string. This is incompatible with our functions that work on buffers,
because we cannot guarantee this. This may lead to a memory violation
if the last token is a number.
We now roll out our own parsers, which are more efficients and
compatible with buffers.
|
|
|
44480f7c
|
2025-04-01T08:28:02
|
|
xkbcomp: Enable lists of keysyms and actions {} and {a}
Motivations:
- Follow the principle of least astonishment;
- Ensure consistency;
- Enhance the use of custom defaults;
- Facilitate the tests.
There is some ambiguity because we use `{}` to denote both an empty list of
keysyms and an empty list of actions. But as soon as we get a keysym or an
action, we know whether it is a `MultiKeySymList` or a `MultiActionList`.
So we just count the `{}` at the *beginning* using `NoSymbolOrActionList`,
then replace it by the relevant count of `NoSymbol` or `NoAction()` once the
ambiguity is solved. If not, this is a list of empties of *some* type: we
drop those empties and delegate the type resolution using `ExprEmptyList()`.
|
|
|
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.
|
|
|
2e0245f8
|
2025-04-02T10:45:44
|
|
xkbcomp: Enable more empty lists
- Empty `interpret`
- Empty key `type`
- Empty `indicator`
Motivations:
- Follow the principle of least astonishment;
- Ensure consistency;
- Enhance the use of custom defaults;
- Facilitate the tests.
|
|
|
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]
};
```
|
|
|
fbacdd98
|
2025-03-31T07:58:04
|
|
test: Refactor test_multi_keysyms_actions
- Use less macros
- Add golden tests to check the compilation *result*
|
|
|
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" { … };
};
```
|
|
|
3150bca8
|
2025-03-30T09:54:02
|
|
xkbcomp: Make all components optional
We already accept *empty* components, such as: `xkb_compat {};`. Let’s
accept missing components as well, so that we can reduce the boilerplate
in our tests.
Note that we will still explicitly serialize empty components for
compatibility with previous xkbcommon versions and Xorg xkbcomp.
|
|
|
23598fa1
|
2025-03-25T22:52:06
|
|
Enable merge mode “replace” in include statements
Previously only the merge modes “override” and “augment” were available
in include statements, using the prefix ‘+’ and ‘|’ respectively. While
on one hand `replace` include statement can be used in keymap files, on
the other hand *rules* files have no way to express the *replace* mode.
This commit enables the merge mode “replace” using the prefix `^`. This
prefix was chosen due to its similarity with the `XOR` bit operator,
which convey *mutual exclusion*.
Other candidates:
- `!` conveys some kind of higher precedence, akin to CSS `!important`.
But it conflicts with the section header `!`, which is a token in the
current parser. It would require special handling, not worth it. It
also convey the meaning of negation, which is confusing.
- `&` has the advantage of not corresponding to a token in the rules
parser. `^` seems however to stand out more and it is less likely to
trigger erroneous comparison with `|` and `&` bit operators.
|
|
|
6fc6e64b
|
2025-03-26T10:35:22
|
|
rules: Added extended wild cards <none>, <some> and <any>
Added the following wild cards to the rules file syntax, in addition
to the current `*` legacy wild card:
- `<none>`: Match *empty* value.
- `<some>`: Match *non-empty* value.
- `<any>`: Match *any* (optionally empty) value. Its behavior does not
depend on the context, contrary to the legacy wild card `*`.
This will enable writing much simpler rules, see [!764] for an example
of tricky rules in the `xkeyboard-config` project, that would benefit
from the new wild cards.
[!764]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/764
The verbose wild cards are preferred to single characters:
- More intuitive: self-explanatory.
- Does not steal syntax from other token.
- Extensible syntax, should we need it.
A previous proposal used the characters (`!`, `+`, `?`) for their
similarity with the corresponding syntax of regular expressions
(negative assertion & quantifiers), in line with `*`. But `!` is not
that intuitive after all and conflict with its role as section header.
Furthermore, `+` is also used as a merge mode. Finally, nothing beats
whole short words for readability.
|
|
|
e5401b07
|
2025-03-26T16:02:58
|
|
symbols: Improve Modmap parsing
Parse, dont’t validate: ensure *at parsing* that `modifier_map`
definitions use a list of keys and keysyms.
This enables to remove the redundant `ExprResolveKeySym` and have keysym
parsing exclusively in handled in `parser.y`.
|
|
|
e8561909
|
2025-03-18T14:34:10
|
|
xkbcomp: Fix keycodes bounds
- Refactor to check conflicts first for the key names and then for the
keycodes. This seems more useful for the user and enable further
memory optimizations.
- Do not allocate until we are sure to add the keycode. The bounds are
only updated afterwards, so the call to `FindKeyByName` should be
more efficient.
- Fixed keycodes bounds not shrunk correctly when an existing keycode
is overridden.
- Do not prepare keyname strings for logging if we are not going to
use them.
|
|
|
befa0cdd
|
2025-02-12T15:38:58
|
|
test: Check integers syntax
|
|
|
4cef822a
|
2025-02-12T07:44:34
|
|
test: Check masks syntax
|
|
|
ff2ac493
|
2025-01-29T06:59:48
|
|
tests: Fix deprecated keysyms in Compose data
The data set is big enough so we can just drop most sequences with
deprecated keysyms and fix most keysyms an alternative non-deprecated
name.
We keep a handful of them for testing purpose.
|
|
|
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.
|
|
|
7a08b145
|
2025-01-24T11:10:17
|
|
tests: Modifier and group latch
- Added a big bunch of tests for modifier latch. No yet exhaustive,
but should cover the most usual use cases.
- Added missing test cases for breaking the group latch. Ideally, more
tests should be added to match the coverage of modifiers latches.
WARNING: it is ambiguous what prevents a latch when multiple keys are
*simultenously* operated together. We currently assuming that
any action that is not identical to the considered latch
prevents it.
|
|
|
b0d9a790
|
2025-01-15T12:03:10
|
|
vmods: Fix explicit vmods not dumped
|
|
3fdd822d
|
2025-01-16T02:21:29
|
|
state: Fix mods not being independently cleared (#584)
The modifiers filters should ensure minimal interaction between them,
but currently the Latch mod filters are overzealous and mess with the
mods from other filters set to be cleared, resulting in some modifiers
permanently set.
Fixed by clearing mods properly with `OR` rather than direct setting
of `state::clear_mods`.
While we are at it, `state::set_mods` should be `OR`ed as well. This
should not have any impact for now, but this is more future-proof.
Fixes #583
Co-authored-by: Jules Bertholet <julesbertholet@quoi.xyz>
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
|
|
|
dfa286b2
|
2025-01-15T13:56:36
|
|
compat: Fix Interp & LED merge modes
|
|
|
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.
|
|
|
7d08bf43
|
2025-01-07T18:33:21
|
|
state: Add test for LEDs driven by the group state
|
|
|
93b75c63
|
2024-12-22T17:49:24
|
|
x11: Keep level when the keysym is undefined but not the action
When getting the keymap from X11, the following:
```
key <AD01> { actions=[SetGroup(2)] };
```
is currently converted to:
```
key <AD01> { };
```
This commit fixes dropping a defined action when the keysym is undefined
|
|
|
d523fd56
|
2025-01-11T08:53:22
|
|
test: Do not include extra numpad in the base one
This allow to load only the minimal key types required by the protocol:
`basic+numpad`.
|
|
|
0dc39650
|
2025-01-02T18:45:15
|
|
test: Declare virtual modifiers explicitly
This is required in order to use the sections in isolation.
|
|
|
31a841ae
|
2024-10-14T16:05:35
|
|
state: support querying whether virtual modifiers are active
Previously it was not possible to query the status of virtual modifiers
with the following functions:
- `xkb_state_mod_index_is_active`
- `xkb_state_mod_indices_are_active`
- `xkb_state_mod_name_is_active`
- `xkb_state_mod_names_are_active`
Note that it may *overmatch* if some modifier mappings overlap. For
example, the default “us” PC layout maps both “Alt” and “Meta” to the
real modifier “Mod1”; thus “Mod1”, “Alt” and “Meta” modifiers will
return the same result with these functions.
|
|
|
71d64df3
|
2024-10-08T18:45:18
|
|
symbols: Add tests for multiple actions per level
|
|
|
fdf2c525
|
2024-10-08T19:43:30
|
|
actions: Add support for multiple actions per level
This makes 1 keysym == 1 action holds also for multiple keysyms per level.
The motivation of this new feature are:
- Make multiple keysyms per level more intuitive.
- Explore how to fix the issue with shortcuts in multi-layout settings
(see the xkeyboard-config issue[^1]). The idea is to use e.g.:
```c
key <LCTL> {
symbols[1] = [ {Control_L, ISO_First_Group } ],
actions[1] = [ {SetMods(modifiers=Control), SetGroup(group=-4) } ]
};
```
in order to switch temporarily to a reference layout in order to get
the same shortcuts on every layout.
When no action is specified, `interpret` statements are used to find
an action corresponding for *each* keysym, as expected.
For an interpretation matching Any keysym, we may get the same
interpretation for multiple keysyms. This may result in unwanted
duplicate actions. So set this interpretation only if no previous
keysym was matched with this interpret at this level, else set the
default interpretation.
For now, at most one action of each following categories is allowed
per level:
- modifier actions: `SetMods`, `LatchMods`, `LockMods`;
- group actions: `SetGroup`, `LatchGroup`, `LockGroup`.
Some examples:
- `SetMods` + `SetGroup`: ok
- `SetMods` + `SetMods`: error
- `SetMods` + `LockMods`: error
- `SetMods` + `LockGroup`: ok
[^1]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/416
|
|
|
7c4c718b
|
2024-09-30T06:13:38
|
|
Allow only the first group in symbols sections when using RMLVO
Currently `xkb_keymap_num_layouts` may return a greater number than the
number of layouts configured using RMLVO, because we allow symbols
sections to define various groups per key.
This is unintuitive and kind of buggy: groups should be added via rules
by setting an explicit `:n` modifier.
Fix: when parsing a keymap using RMLVO resolution:
- Get the expected layouts count from the resulting KcCGST.
- Drop the groups after the first one in included symbols sections. This
will ensure that a symbol section can only define one group per key.
Notes:
- Compiling a keymap string directly is unaffected.
- RMLVO resolution may still produce more groups than the input layouts.
Indeed, some legacy rules in xkeyboard-config rely on this to insert
automatically a US layout before the given non-Latin one, resulting
in two layouts while only one was given.
|
|
|
948f7a59
|
2024-10-09T08:34:27
|
|
symbols: Skip interprets only for groups with explicit actions
Previously setting explicit actions for a group in symbols files made
the parser skip compatibility interpretations for the corresponding
*whole* key, so the other groups with *no* explicit actions could result
broken on some levels.
In the following example, `<RALT>` would have an action on group 2,
because it is explicit, but none on group 1 because interpretation are
also skipped there as a side effect:
```c
key <RALT> {
symbols[1]= [ ISO_Level3_Shift ],
symbols[2]= [ ISO_Level3_Shift ],
actions[2]= [ SetMods(modifiers=LevelThree) ]
};
```
Fixed by skipping interpretations *only* for groups with explicit actions.
We still set `key->explicit |= EXPLICIT_INTERP` if at least one group
has explicit actions. In such case, when dumping a keymap, we will
write explicit actions for *all* groups, in order to ensure that X11 and
previous versions of libxkbcommon can parse the keymap as intended. One
side effect is that no interpretation will be run on this key anymore,
so we may have to set some extra fields explicitly: repeat, virtualMods.
Thus the previous example would be bumped as:
```c
key <RALT> {
repeat= No,
symbols[1]= [ ISO_Level3_Shift ],
actions[1]= [ SetMods(modifiers=LevelThree,clearLocks) ],
symbols[2]= [ ISO_Level3_Shift ],
actions[2]= [ SetMods(modifiers=LevelThree) ]
};
```
|
|
|
4ea9d431
|
2023-11-16T17:12:03
|
|
rules: Add support for :all qualifier
Some layout options require to be applied to every group to maintain
consistency (e.g. a group switcher). Currently this must be done manually
for all layout indexes. This is error prone and prevents the increase of
the maximum group count.
This commit introduces the `:all` qualifier for KcCGST values. When a
rule with this qualifier is matched, it will expands the qualified
value (and its optional merge mode) for every layout, e.g.
`+group(toggle):all` (respectively `|group(toggle)`) would expand to
`+group(toggle):1+group(toggle):2` (respectively
`|group(toggle):1|group(toggle):2`) if there are 2 layouts, etc.
If there is no merge mode, it defaults to *override* `+`, e.g. `x:all`
expands to `x:1+x:2+x:3` for 3 layouts.
Note that only the qualified *value* is expanded, e.g. `x+y:all` expands
to `x+y:1+y:2` for 2 layouts.
`:all` can be used in combination with special layout indexes. Since
this can lead to an unexpected behaviour, a warning will be raised.
|
|
|
cdafba4f
|
2024-09-24T15:23:16
|
|
rules: Add support for index ranges
There is a lot of repetition in the current rules files provided by
xkeyboard-config, because the MLVO mappings need to match on the exact
layout/variant index. This also prevents to increase the number of
maximum groups, because it does not scale.
We introduces the following new special layout/variant indexes:
- “single”: matches a single layout; same as with no index.
- “first”: matches the first layout/variant, no matter how many layouts
are in the RMLVO configuration. It allows to merge `layout` and
`layout[1]` patterns.
- “later”: matches all but the first layout. This is an index range.
- “any”: matches layout at any position. This is an index range.
We also introduces the new `%i` expansion, which correspond to the index
of the matched layout in a mapping with an index range. Example:
layout[later] = symbols
my_layout = +my_symbols:%i
* = +%l[%i]:%i
Let’s have a look at concrete examples from xkeyboard-config:
! model layout = symbols
* * = pc+%l%(v)
! model layout[1] = symbols
* * = pc+%l[1]%(v[1])
! model layout[2] = symbols
* * = +%l[2]%(v[2])
! model layout[3] = symbols
* * = +%l[3]%(v[3])
! model layout[4] = symbols
* * = +%l[4]%(v[4])
! layout option = symbols
* grp:toggle = +group(toggle)
! layout[1] option = symbols
* grp:toggle = +group(toggle):1
! layout[2] option = symbols
* grp:toggle = +group(toggle):2
! layout[3] option = symbols
* grp:toggle = +group(toggle):3
! layout[4] option = symbols
* grp:toggle = +group(toggle):4
With this commit we can now simplify it into:
! model layout[first] = symbols
* * = pc+%l[%i]%(v[%i])
! model layout[later] = symbols
* * = +%l[%i]%(v[%i]):%i
! layout[any] option = symbols
* grp:toggle = +group(toggle):%i
The latter rule will work even if we increase XKB_MAX_GROUPS, whereas
the former would require to add the missing entries for the new groups.
In order to maintain consistent rules, we now disallow layout and
variant to have different indexes. For example, the following mapping
are now invalid:
- layout variant[1]
- layout[1] variant[2]
- layout[1] variant
- layout[first] variant[1]
- layout[first] variant
- layout variant[any]
- etc.
|
|
|
7697c712
|
2024-09-16T16:09:11
|
|
rules: Resolve relative include statements using XKB paths
Contrary to keymap files, the `! include` statement in rules does not
lookup include paths added to `xkb_context`. So it is not possible e.g.
to import another file in the same folder without using an absolute path.
- Added path utils: `is_absolute(path)`.
- Added XKB paths lookup to enable e.g. `! include evdev` to work.
- Added test.
|
|
|
05ba96db
|
2024-08-20T16:41:38
|
|
rules: Fix wild card handling
The handling of wild card `*` is different in libxkbfile and X server:
wild card matches empty strings for model and option but not for layout
nor variant, while in libxkbcommon wild cards always match empty strings.
See:
- https://gitlab.freedesktop.org/xorg/lib/libxkbfile/-/blob/bf985c68acb1244f51ec91414532a2347fbc1c4c/src/maprules.c#L687
- https://gitlab.freedesktop.org/xorg/lib/libxkbfile/-/blob/bf985c68acb1244f51ec91414532a2347fbc1c4c/src/maprules.c#L712
The difference of handling between the components is unfortunately not
documented, but we should follow the behavior of the original
implementations for consistency.
- Fixed by implementing the same behavior than libxkbfile.
- Added tests and fixed failing tests.
- Improve the documentation of rules to highlight the special behavior.
|
|
|
e9bd7de4
|
2024-07-04T16:22:13
|
|
state: Add support for group latch action
Surprisingly, the latch group action was not yet implemented.
Added tests to ensure we get the tricky bits right.
|
|
ba76ec16
|
2024-03-01T15:02:42
|
|
Global default statement: Fix types
Do not accept statements like garbage.level_name in types files
Fix parser accepting clearly nonsensical type definitions like
type "ONE_LEVEL" {
garbage.modifiers = None;
garbage.map[None] = Level1;
garbage.level_name[Level1] = "Any";
};
and ignoring the garbage part.
Co-authored-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
|
|
|
24f69645
|
2024-03-01T15:02:42
|
|
Global default statement: Fix symbols
|
|
|
d21645be
|
2024-02-18T13:57:15
|
|
xkbcomp: Require newline after !include line in rules files
Rules file parser allows constructs like
!include "foo" !include "bar" !layout = symbols
This is most likely an oversight in original code.
Closes #452
|
|
|
382f6d2d
|
2024-02-05T08:57:35
|
|
Keysyms: Update using latest xorgproto
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.
|
|
efdb05d1
|
2024-01-27T23:00:28
|
|
parser: Do now allow the empty symbol declaration
An empty element is allowed in SymbolsBody definition, so the following
keymap is gramatically correct.
```
xkb_keymap {
...
xkb_symbols "sym" {
key <SPC> {, [Space] };
};
};
```
However, the current parser crashes with the keymap due to null pointer
access.
This change fixes it by changing the parser not to allow it.
|
|
|
31ebe003
|
2023-12-19T09:15:14
|
|
test: add a test for multiple keysyms (and some minimal docs)
I couldn't find any reference to *how* the keymap format actually needs to look
like if you want multiple keysyms per level. So let's add a test for it and a
minimal documentation entry.
|
|
|
00e3058e
|
2023-11-06T21:53:51
|
|
Prevent recursive includes of keymap components
- Add check for recursive includes of keymap components. It relies on
limiting the include depth. The threshold is currently to 15, which
seems reasonable with plenty of margin for keymaps in the wild.
- Add corresponding new log message `recursive-include`.
- Add tests for recursive includes.
|
|
|
3aaa4e2a
|
2023-10-30T15:51:34
|
|
rules: early detection of invalid encoding
|
|
|
9e887180
|
2023-10-29T07:44:39
|
|
rules: skip heading UTF-8 encoded BOM (U+FEFF)
Leading BOM is legal and is used as a signature — an indication that
an otherwise unmarked text file is in UTF-8.
See: https://www.unicode.org/faq/utf_bom.html#bom5 for further details.
|
|
|
87dcf301
|
2023-09-28T09:51:25
|
|
Fix trailing whitespaces in XKB files
|
|
|
0d454115
|
2023-09-28T07:18:56
|
|
Keysyms: Fix failing tests
- 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.
|
|
|
0038c866
|
2023-09-26T17:05:14
|
|
Prevent overflow of octal escape sequences
The octal parser accepts the range `\1..\777`. The result is cast to
`char` which will silently overflow.
This commit prevents overlow and will treat `\400..\777` as invalid
escape sequences.
|
|
|
ca7aa69c
|
2023-09-26T17:05:05
|
|
Disallow producing NULL character with escape sequences
NULL usually terminates the strings; allowing to produce it via escape
sequences may lead to undefined behaviour.
- Make NULL escape sequences (e.g. `\0` and `\x0`) invalid.
- Add corresponding test.
- Introduce the new message: XKB_WARNING_INVALID_ESCAPE_SEQUENCE.
|
|
|
a4c08526
|
2023-07-04T09:23:24
|
|
Improved tests related to keysyms
- Add a keymap test with decimal and hexadecimal keysyms.
- Reorganize code in `test/keysym.c` by parsing type: name, Unicode and
hexadecimal.
- Add more tests for edge cases. In particular:
- test decimal format (currently not supported);
- test the Unicode and hexadecimal ranges more thoroughly;
- test with wrong case without the XKB_KEYSYM_CASE_INSENSITIVE flag;
- test surrounding spaces.
- Document the tests.
|
|
|
5b5b67f2
|
2023-05-01T22:30:41
|
|
Add support for modmap None (#291)
Unlike current xkbcommon, X11’s xkbcomp allows to remove entries in
the modifiers’ map using “modifier_map None { … }”.
“None” is translated to the special value “XkbNoModifier” defined in
“X11/extensions/XKB.h”. Then it relies on the fact that in "CopyModMapDef",
the following code:
1U << entry->modifier
ends up being zero when “entry->modifier” is “XkbNoModifier” (i.e. 0xFF).
Indeed, it relies on the overflow behaviour of the left shift, which in
practice resolves to use only the 5 low bits of the shift amount, i.e.
0x1F here. Then the result of “1U << 0xFF” is cast to “char”, i.e. 0.
This is a good trick but too magical, so in libxkbcommon we will use
an explicit test against our new constant XKB_MOD_NONE.
|
|
e2465c2a
|
2021-05-22T19:55:04
|
|
tests/data: add files needed to fully test compose
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
fbf087ea
|
2020-11-23T19:51:04
|
|
keymap-dump: follow xkbcomp in printing affect=both in pointer actions
It is equivalent to nothing but good to match up.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
95f8ff83
|
2020-11-23T18:35:27
|
|
test/data: update host.xkb to match keymap-dump style
This is needed for fixing the x11comp test.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|