|
45a118d5
|
2025-10-23T07:30:40
|
|
x11: Ensure LED and modifier counts are valid
|
|
|
f6429933
|
2025-10-20T09:29:05
|
|
context: Add legacy X11 include path for misconfigured setups
Some setups use the assumption that the canonical XKB root is always
the legacy X11 one, but this is no longer true since xkeyboard-config
2.45, where the X11 path is now a mere symlink to a dedicated data
directory for xkeyboard-config.
Fixed by using a fallback to the legacy X11 path for misconfigured
setups where the canonical XKB root is not available.
This fallback can still be skipped if the environment variable
`XKB_CONFIG_ROOT` is deliberately set to an empty string.
|
|
|
c11c19fa
|
2025-10-20T11:10:55
|
|
context: Comment handling of empty include paths
|
|
|
6d64fc5b
|
2025-10-20T09:02:58
|
|
context: Raise the log level of include path addition to info
This information is quite important to investigate bugs and should not
require the bloat of the debug log level.
Also report include paths additions attempts in registry.
|
|
|
d2d40ec8
|
2025-10-20T11:14:44
|
|
context: Minor refactor
|
|
|
9dd55436
|
2025-10-20T11:13:02
|
|
context: Fix NULL include path
- Fix an unlikely addition of a NULL include path in case of
a failed allocation.
- Fix displaying this NULL value.
|
|
|
6822fa0e
|
2025-10-16T08:11:27
|
|
x11: Fix parsing key types level names
Fixed handling missing or incomplete key types level names.
|
|
|
939bf0e1
|
2025-10-17T11:57:53
|
|
xkbcomp: Never drop X11 canonical key types
There are 4 mandatory *canonical key types* in the XKB protocol:
- `ONE_LEVEL`
- `TWO_LEVEL`
- `ALPHABETIC`
- `KEYPAD`
They are always present in the keymap generated from xkeyboard-config.
But since 31900860c65b88e4d10ad7dd00377e2815cca0f6 we drop unused key
types by default, which may happen for the types hereinabove with e.g.
4+ level layouts like `es`.
In theory these types are automatically filled by libX11 if missing,
but there are some bugs in the X11 ecosystem that prevents the keymap
to be properly uploaded in the X server, leading to errors when
retrieving it with libxkbcommon-x11. See:
https://gitlab.archlinux.org/archlinux/packaging/packages/libxkbcommon/-/issues/3
The following fixes were filed to fix the issues:
- https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/292
- https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2082
- https://github.com/xkbcommon/libxkbcommon/pull/871
However it’s not clear when new versions of libX11 and xserver will be
released. So this commit is a hack to ensure that we do not drop the
XKB canonical key types, as an effort to reduce breakage.
WARNING: contrary to `xkbcomp`, we do not supply these types if they
are missing, because a keymap that uses them (explicitly `type="…"` or
implicitly with automatic types) without providing them is considered
buggy. The only exception is if no key type is provided, a default one-
level type `ONE_LEVEL` is provided and assigned to all keys.
|
|
|
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.
|
|
|
837dbb46
|
2025-10-09T18:10:22
|
|
Fix C11 syntax
Label followed by declaration requires C23.
|
|
|
6876e99d
|
2025-10-09T11:27:18
|
|
keymap: Fixed action comparison
Before this commit there were 2 issues in action comparison:
- Private actions comparison wrongly compared pointers;
- Custom action types were mistakenly interpreted as errors and thus
always failed comparison.
Also added assertions on the action type enum so that the relevant code
must be updated when the enum changes.
|
|
|
b9b244e2
|
2025-10-09T11:25:28
|
|
keymap: Add function to compare keymaps
- Added private API `xkb_keymap_compare()`
- Added corresponding tests
|
|
|
584e0690
|
2025-10-08T11:55:22
|
|
keysyms: Update using latest xorgproto
xorgproto commit: 81931cc0fd4761b42603f7da7d4f50fc282cecc6
Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/103
|
|
|
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`.
|
|
|
9131711a
|
2025-08-21T13:09:04
|
|
keymap: Add xkb_keymap_get_as_string2()
Enable to configure the keymap serialization.
|
|
|
e3ef7a47
|
2025-09-24T20:29:22
|
|
keymap: Warn for numeric keysyms only at high verbosity
Now that the default serialization uses the numeric format for keysyms,
the warning should be enabled only at maximum verbosity.
|
|
|
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.
|
|
|
4421a358
|
2025-09-22T10:49:18
|
|
xkbcomp: Use keycode name LUT for xkb_symbols
Replace linear search with O(1).
On my setup I get 1.05x speedup compared to previous commit and
1.09x speedup compared to 44fad8a067d221ec0365455bc00c4c3c94bca0ad
(no keycode name LUT).
|
|
|
79741554
|
2025-09-20T15:21:16
|
|
xkbcomp: Enable aliases to override keys
Contrary to Xorg’s xkbcomp, keys and aliases share the same
namespace. So we need to resolve name conflicts as they arise,
while xkbcomp will resolve them just before copying aliases into
the keymap.
The following example:
xkb_keycodes {
<A> = 8;
<B> = 9;
alias <B> = <A>;
};
will resolve in libxkbcommon to:
xkb_keycodes {
<A> = 8;
alias <B> = <A>;
};
while in Xorg’s xkbcomp:
xkb_keycodes {
<A> = 8;
<B> = 9;
};
The former does result in the intended mapping.
In practice, there is no such conflict in xkeyboard-config.
Another corner case is that now an alias can override a key even if
proved invalid aftwerwards, e.g.:
xkb_keycodes {
<A> = 1;
<B> = 2;
alias <B> = <C>; /* Override key, even if invalid entry */
};
results in:
xkb_keycodes {
<A> = 1;
};
This should be considered a bug in either the keycodes or rules files,
not libxkbcommon.
|
|
|
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.
|
|
|
f1376a2a
|
2025-09-15T19:33:26
|
|
context: Fix xkb_atom_t definition
`xkb_atom_t` is in fact an index in a `darray`, so ensure the types
match. This is unlikely to have any impact on modern systems.
|
|
|
3203a010
|
2025-08-13T17:06:20
|
|
tools: Add internal introspection
This tool enables simple analysis of XKB files with a YAML or DOT output:
- resolve XKB paths;
- list sections of a file;
- list the includes of each section;
- optionally process each include recursively.
Additionally, the RDF Turtle output enables to query using the powerful
SPARQL language.
The tool is for internal use only for now, so that we can test it in
various use cases before deciding if making it public.
|
|
|
38a2081f
|
2025-09-17T16:17:55
|
|
utils: Add strcpy_safe
This is a safe version of strcpy.
|
|
|
0a874a3a
|
2025-08-13T17:02:21
|
|
include: Enable to return the resolved path
|
|
|
44fad8a0
|
2025-09-14T10:29:41
|
|
keysyms: Update to Unicode 17.0
See: https://www.unicode.org/versions/Unicode17.0.0/
|
|
|
87042776
|
2025-08-21T19:30:37
|
|
logging: Encode verbosity values in an enum
This enables to provide semantics and to ensure we use the values
uniformly in the code base.
While one could expect that verbosity `0` silences the logging, it
is actually our default verbosity level for a long time. So this
commit does not change that in order to avoid possible breakage.
Silencing the logging is achieved by using a negative value for the
verbosity level.
|
|
|
135b3204
|
2025-08-16T12:59:20
|
|
compose: Add fallback for custom locales
Before this commit, loading a Compose file based on the locale would fail
if the locale is not in the X11 Compose locale registry. While there are
workarounds (e.g. `~/.XCompose` file or `$XCOMPOSEFILE`), it does not
work if the corresponding file has `include "%L"`.
This commit adds the fallback `en_US.UTF-8` in case the locale is
installed but not registered in the X11 Compose locale registry. The
choice is motivated by the fact that most locales use `en_US.UTF-8`
anyway.
Ideally we should have a mechanism to extend the Compose locale registry
at the *system* level. Mechanisms at the user level (e.g. custom Compose
file, environment variable) are deemed sufficient.
We could still improve it by first trying to fallback to the locale
without the country bits, but there is no function to do such function
in the stdlib and we do not want to mess with locales manually.
Unfortunately is not possible to test it in our test suite. One can
still check it works following these instructions:
1. Create a custom locale, e.g. `en_XX.UTF-8`. `glibc-i18ndata` or
similar package may be required to get the required files in
`/usr/share/i18n/`.
`sudo localedef -i en_US -f UTF-8 en_XX.UTF-8`
2. `xkbcli compile-compose --verbose --locale en_XX.UTF-8`
|
|
|
3449f69f
|
2025-08-16T12:57:49
|
|
doc: Add new message XKB_ERROR_INVALID_COMPOSE_LOCALE
|
|
|
b5d969dd
|
2025-08-06T17:22:38
|
|
compose: Move constants to dedicated header
|
|
|
39726cac
|
2025-08-06T20:29:26
|
|
Add xkb_keymap_mod_get_mask2()
Retrospectively, `xkb_keymap_mod_get_mask()` should have used a
modifier index rather that a modifier name in its type. Since we
already published a version with this API, it’s too late to change
that, so instead add a new function `xkb_keymap_mod_get_mask2()`.
|
|
|
6fac73f3
|
2025-08-02T09:49:44
|
|
log: Fix NULL string
Fixed regression introduced in 05d13d5f41d94c7776456d856fccb5969e8f5b0a.
|
|
|
1e0c5790
|
2025-07-23T12:09:32
|
|
keysyms: Fix XF86MediaSelectAuxiliary typo
|
|
|
e9fd95a5
|
2025-07-23T10:01:45
|
|
keysyms: Update using latest xorgproto
xorgproto commit: 7fc33fe6d9cf0abc9b62ee976e5cb7ddcd050d1f
Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/93
|
|
|
d60b3213
|
2025-07-16T08:00:30
|
|
Make the ref counting invariants explicit with assertions
|
|
|
93818226
|
2025-07-15T11:34:06
|
|
Add xkb_rmlvo_builder_ref()
|
|
|
dc63e5f8
|
2025-07-07T12:28:24
|
|
Ensure config.h is always included first
While `config.h` may not be necessary in every file, it ensures
consistency and makes code refactoring safer.
|
|
|
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.
|
|
|
64b1b9d7
|
2025-07-01T13:03:59
|
|
utils: Optimize istreq_prefix
|
|
|
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.
|
|
|
58373807
|
2025-06-27T18:21:19
|
|
keysym: Do not convert UTF-32 to deprecated keysyms
Before this commit, some code points could be converted to deprecated
keysym. This is incorrect, because the relevant keysyms are all
deprecated because their mapping to Unicode is uncertain!
Ensure that `xkb_utf32_to_keysym()` never returns deprecated keysyms,
because there is either another non-deprecated keysym or in last resort
we always have the correct keysym available in the Unicode keysym range.
|
|
|
05d13d5f
|
2025-06-26T16:58:50
|
|
include: Fix infinite loop
Fixed including an absolute path with no default map triggering an
infinite loop.
|
|
|
c4f4ba41
|
2025-06-23T18:15:18
|
|
state: Fix modifier and group latch
Prior to this commit, the sequences:
- 1. latch A ↓
2. latch B ↓
3. latch B ↑
4. latch A ↑
- 1. latch A ↓
2. latch B ↓
3. latch A ↑
4. latch B ↑
would result in only B being latched, because the XKB protocol specifies
that latches are triggered only if keys are *sequentially* tapped, i.e.
a strict sequence of press and release of each key.
It seems an unnecessary limitation:
- `SlowKeys` and `XkbAX_TwoKeys` are the proper accessibility features
to control accidental key presses, not latches nor `StickyKeys`.
- Latches are also used outside their original accessibility role.
A user may activate multiple latch keys simultaneously:
- same hand: two latch keys being close to each other;
- different hand: two keys being activated independently.
Changed the latching behavior so that the rules used to break a latch
are the same than those used to prevent it. Depressing and releasing two
latching keys simultaneously will now activate both latches, as expected.
Since this is a breaking change, it is enabled only by the keymap format
`XKB_KEYMAP_FORMAT_TEXT_V2`.
|
|
|
3d00222e
|
2025-06-21T18:26:34
|
|
keymap: Add option `unlockOnPress` for LatchMods()
It mirrors the feature of `SetMods()`, so that `StickyKeys` can be
implemented.
|
|
|
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`.
|
|
|
94d8e341
|
2025-06-21T13:17:16
|
|
state: Fix LatchMods mutation to SetMods or LockMods
Previously we use inlined version of the corresponding filter functions
of the `SetMods()` and `LockMods()` actions, but they were incomplete
and did not set some fields (`priv`, `refcnt`) properly. Also, it is
error-prone: it requires discipline to keep it in sync.
E.g. before this commit, converting to `LockMods()` would always try to
unlock `CapsLock` due to the wrong value of the `priv` field.
Fixed by using the corresponding filter functions directly, so that we
always mutate the filter properly, as in `xkb_filter_group_latch_func`.
|
|
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.
|
|
|
4f2fa718
|
2025-06-17T16:47:20
|
|
dump: Fix typo
Fixed copy-paste error. It worked for now, as both struct have the
same first fields, but it is obviously semantically incorrect and
not future-proof.
|
|
|
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
|
|
|
c2896b32
|
2025-06-12T09:16:54
|
|
messages: Add new error "incompatible-keymap-text-format"
|
|
|
0106b357
|
2025-06-17T12:06:32
|
|
registry: Add rxkb_option_is_layout_specific()
Enable to query if an option accepts layout index specifiers to restrict
its application to the corresponding layouts.
|
|
|
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.
|
|
|
fab9d25b
|
2025-06-17T11:43:22
|
|
rules: Add support for layout-specific options
Enabled specifying a layout index for each option, so that it applies
only if the layout matches. The layout index is specified by appending
immediately after the option name the `!` specifier delimiter and then
the layout index, in decimal form and 1-indexed.
Note that `!` was chosen instead of the usual `:` specifier delimiter,
because some options contains `:`, e.g. `grp:menu_toggle`. `!` *cannot*
clash with component names, because `!` is a token in the rules files
and thus cannot be used as in component names. It is also vaguely similar
to `:`, compared to e.g. `@` or `#`.
Example: given the following rules:
! layout[any] option = symbol
* opt1 = +s1:%i
l2 opt2 = +s2:%i
it may result in the following configurations:
| Layout | Option | Symbols |
| -------- | -------- | ------------ |
| `l1` | `opt1` | `+s1:1` |
| `l2` | `opt1` | `+s1:1` |
| `l1` | `opt2` | `` |
| `l2` | `opt2` | `+s2:1` |
| `l1,l2` | `opt1` | `+s1:1+s1:2` |
| `l1,l2` | `opt1!1` | `+s1:1` |
| `l1,l2` | `opt1!2` | `+s1:2` |
| `l1,l2` | `opt2` | `+s2:2` |
| `l1,l2` | `opt2!1` | `` |
| `l1,l2` | `opt2!2` | `+s2:2` |
|
|
|
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.
|
|
|
ef6a550f
|
2025-06-16T15:48:25
|
|
Add xkb_keymap_new_from_rmlvo()
Use the new RMLVO builder API to compile keymaps.
|
|
|
da5caabb
|
2025-06-16T15:45:42
|
|
Add RMLVO builder API
Before this commit, the API to work with RMLVO was quite minimal: it
only uses raw strings from the `xkb_rule_names` struct. However:
- it forces the users to deal with error-prone string formatting;
- it does not enforce tying together layouts and variants;
- it limits adding new features by requiring defining delimiter
characters and the corresponding parsing.
Added the following API:
- `xkb_rmlvo_builder_new()`
- `xkb_rmlvo_builder_append_layout()`
- `xkb_rmlvo_builder_append_option()`
- `xkb_rmlvo_builder_unref()`
There is no intermediate `layout` nor `option` object, in order to
to keep the API simple. The only foreseen extension is enabling
configuring layout-specific options.
|
|
|
2906c7ec
|
2025-06-14T13:19:41
|
|
rules: Fix parsing group index
There was a typo that made parsing hexadecimal instead of the expected
decimal format.
|
|
|
80b8d9d1
|
2025-06-10T17:34:15
|
|
dump: Adapt groups count to keymap format
|
|
|
62fe73cb
|
2025-06-10T17:33:14
|
|
parser: Raise the layout limit to 32
|
|
|
2535a3f9
|
2025-06-11T15:55:25
|
|
rules: Convert macros into enums & inline functions
This provides semantics and better type-check.
|
|
|
9f3078eb
|
2025-06-10T15:46:31
|
|
dump: Use explicit format
|
|
|
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.
|
|
|
44c8deb2
|
2025-05-07T10:20:25
|
|
Introduce keymap format v2 and make it the default for parsing
- Added `XKB_KEYMAP_FORMAT_TEXT_V2`.
- Made `xkb_keymap_new_from_names()` use the new keymap format.
- Made the tools default to the new keymap format for input.
This is in preparation for changes in the parsing & state handling.
For now it changes nothing.
|
|
|
08149dae
|
2025-05-06T16:23:04
|
|
Add internal API to query and parse supported keymap formats
|
|
|
1a10f858
|
2025-05-06T18:05:06
|
|
Add xkb_keymap_new_from_names2
This is just `xkb_keymap_new_from_names()` with an explicit keymap
format.
|
|
|
16c079d6
|
2025-06-06T20:27:45
|
|
chore: Rename is_absolute to is_absolute_path
|
|
|
39b4b670
|
2025-06-06T18:40:29
|
|
Support including keymap components using %-expansion and absolute path
Enable to use the same `include` features than *rules* files in
*keymap components*:
- *`%`-expansion*: `%H` home directory, `%S` sytem root and `%E` extra.
- absolute file paths.
This is useful if one wants to overwrite the system file with a user
config (i.e. same name, but in `~/.config/xkb`), but still include the
system file:
```
// File: ~/.config/xkb/symbols/de
xkb_symbols "basic" {
include "%S/de(basic)"
key <AB01> { [z, Z] };
key <AD06> { [y, Y] };
}
````
Without the commit, using a mere `include "de(basic)"` would result in
an include loop.
Refactored by using the same code for rules and keymap components.
|
|
|
324984f1
|
2025-05-17T06:49:49
|
|
xkbcomp: Fix log for unknown default field
|
|
|
e9394b9f
|
2025-05-13T10:47:22
|
|
utils: Use explicit cast to prevent warnings
|
|
|
fb9fec18
|
2025-05-10T10:18:38
|
|
xkbcomp: Checked arithmetic
Use a polyfill for C23 checked arithmetic. This is a bit paranoid, as we
expect the user to use only 32 bit integers, so the signed 64 bit integer
we use to store the result should be more than enough.
Use jtckdint v1.0:
- repository: https://github.com/jart/jtckdint
- commit: 339450d13d8636f05dcb71ba36efddb226db481e
- removed all C++-specific code
|
|
7a2aa9c9
|
2024-12-20T22:53:11
|
|
Always retain later Compose sequence in case of conflict
This ensures that it is always possible to override previous definitions,
for example when `include`ing the system Compose file.
Signed-off-by: Jules Bertholet <julesbertholet@quoi.xyz>
|
|
|
3a8bb1a1
|
2025-05-16T13:13:55
|
|
compose: Fix sequence not fully overriden
Previously if a new sequence did not produce a keysym or a string, the
corresponding property was not overriden, possibly leaking the previous
entry.
- Fixed by always writting all the properties.
- Also try to reuse the previous string entry, if possible, so that we
avoid allocating.
|
|
|
61d8ec67
|
2025-05-12T18:20:47
|
|
misc: Fix string format specifiers
Ensure better portability.
|
|
|
3031f6c3
|
2025-05-12T10:38:15
|
|
misc: Always use `unsigned` with `int`
Better semantics & facilitate search.
|
|
|
01742b77
|
2025-05-12T20:40:59
|
|
misc: Ensure explicit conversion in gperf code
|
|
|
556d00a0
|
2025-05-12T17:52:12
|
|
keymap: Ensure proper type for layouts count
|
|
|
3bfc1bc1
|
2025-05-12T18:52:05
|
|
misc: Ensure proper type for darray size
|
|
|
1d361b8f
|
2025-05-12T10:01:10
|
|
scanner: Ensure proper type for string length
|
|
|
13e7114d
|
2025-05-12T09:08:49
|
|
rules: Ensure proper type of MLVO and KcCGST indexes
|
|
|
ac2aa2df
|
2025-05-12T07:47:03
|
|
keymap: Ensure proper type for LEDs count
|
|
|
903c16da
|
2025-05-12T07:42:32
|
|
keymap: Ensure proper type for key types counts
|
|
|
c3953a96
|
2025-05-12T07:37:29
|
|
keymap: Ensure proper type for key codes aliases
|
|
|
2617ebc5
|
2025-05-12T07:32:04
|
|
keymap: Ensure proper type for modifiers count
|
|
|
41bb797d
|
2025-05-12T07:31:33
|
|
symbols: Ensure proper type for keysyms count
|
|
|
f7c94bfc
|
2025-05-12T07:08:11
|
|
symbols: Ensure proper type for levels count
|
|
|
2f4d30c2
|
2025-05-12T07:07:50
|
|
context: Ensure proper type for include paths count
|
|
|
10457563
|
2025-05-12T06:41:28
|
|
keymap: Ensure proper type for actions count
|
|
|
3911f786
|
2025-05-12T07:06:42
|
|
keymap: Ensure proper type for num_sym_interprets
|
|
|
8f5270c0
|
2025-05-12T07:07:57
|
|
utils: Improve darray
- Introduce `darray_size_t`
- Document struct fields: the `alloc` field may be particularly confusing
|
|
|
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()`
|
|
|
137c5e90
|
2025-05-11T12:37:23
|
|
actions: Improve unknown action logging
|