|
06c024e0
|
2025-03-19T13:11:35
|
|
xkbcomp: Fix merge modes
Fix various issues with merge mode handling:
- Invalid initialization
- Invalid merge mode inherited from keymap
- Do not leak local merge mode
|
|
|
0f6ea465
|
2025-03-19T14:12:05
|
|
ci: Enable merge modes tests
|
|
|
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)
|
|
|
216352db
|
2025-04-10T14:58:25
|
|
test: Improve xkeyboard-config script
- Enable setting the XKB root directory. By far the most important
change.
- Enable to pass registry XML files relative to the target rules
directory (with or without the `.XML` extension).
- Enable to set the rules set to use.
- Better JSON/YAML escaping.
- Better error logging.
|
|
|
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
|
|
|
8d380f1b
|
2025-04-11T13:41:37
|
|
rules: Improve bench
|
|
|
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/
|
|
|
dc50603c
|
2025-03-27T14:34:02
|
|
build: Force UTF-8 source files encoding on Windows
Some of our test files (e.g. keysym strings) use UTF-8 encoded
strings that require proper handling by the compiler. Let’s favor
readability using modern compiler settings instead of escape
sequences.
|
|
|
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
|
|
|
08d9a031
|
2025-04-08T06:31:33
|
|
Unicode: Make surrogate handling more explicit
|
|
|
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.
|
|
|
ca798d21
|
2025-04-08T16:21:46
|
|
keysyms: Pad Unicode keysyms only up to 4 digits
Previously there was a distinction between keysyms with code points in
BMP and the others: the former used a 4-padding while the latter used
a 8-padding: e.g `U0001` vs `U00010000`. This is unnecessary and makes
the reading harder.
Let’s use the same padding for all: `U0001` and `U10000`.
Parsing remains unchanged and would parse both paddings.
Also added a test to check no explicit name can clash with Unicode
notation.
|
|
|
47c2c820
|
2025-04-08T18:09:41
|
|
Add internal API to get all explicit names of a keysym
|
|
|
102f4ba1
|
2025-04-06T19:38:53
|
|
Fix integer conversion warnings
|
|
|
3370ead3
|
2025-04-06T06:39:31
|
|
test: Better handling of missing xkbcomp for X11 tests
- meson: Warn if missing xkbcomp for X11 tests;
- test: Better logging to spot missing Xorg executables.
|
|
|
5a32b779
|
2025-04-06T06:16:41
|
|
logging: Handle NULL map name
Display “(unnamed map)” instead of “(null)”.
|
|
|
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.
|
|
|
06394afc
|
2025-04-03T08:49:12
|
|
xkbcomp: Minor parser refactor for keysyms and actions
|
|
|
f348c6e9
|
2025-04-05T12:48:50
|
|
logging: Quote invalid escape sequence
|
|
|
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.
|
|
|
23bbec96
|
2025-03-29T12:33:53
|
|
xkbcomp: Add escape sequence \"
`\"` seems like a very natural extension. However it is not
supported by Xorg xkbcomp, so do not emit it when serializing.
|
|
|
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.
|
|
|
3d026436
|
2025-04-05T14:32:34
|
|
keymap serialization: Fix unchecked allocation failures
The previous commit enabled clang-tidy to detect some missing checks.
|
|
|
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).
|
|
|
39c1bb36
|
2025-03-29T17:47:31
|
|
xkbcomp: Fix static_assert syntax
|
|
|
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.
|
|
|
9b255d1e
|
2025-04-03T07:52:15
|
|
tools: Update bash completion
Handle positional argument as a path for the `compile-*` tools.
|
|
|
028869b1
|
2025-03-31T13:51:19
|
|
doc: Add sections for merge modes and include mechanism
|
|
|
8594adc4
|
2025-03-31T13:52:36
|
|
doc: Mention that `alternate` merge mode is not supported
|
|
|
36bb4fe3
|
2025-04-02T19:10:02
|
|
xkbcomp: Minor renaming
Use the same case for `KeySym` in the parser.
|
|
|
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]
};
```
|
|
|
7dbd2576
|
2025-04-01T19:20:10
|
|
keymap: Use constants for Lock and Control indexes
These indexes are fixed, so there is no need to lookup their name.
|
|
|
fbacdd98
|
2025-03-31T07:58:04
|
|
test: Refactor test_multi_keysyms_actions
- Use less macros
- Add golden tests to check the compilation *result*
|
|
|
55e99f0a
|
2025-04-01T09:03:25
|
|
keymap: refactor ClearLevelInfo
|
|
|
343c49cc
|
2025-03-30T09:54:02
|
|
doc: Optional components
|
|
|
b254cc2e
|
2025-03-30T12:27:15
|
|
test: Remove empty components boilerplate
|
|
|
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.
|
|
|
ecde6ade
|
2025-03-28T10:31:28
|
|
doc: Document floating-point parsing difference with Xorg xkbcomp
|
|
|
500b260b
|
2025-03-28T09:38:58
|
|
xkbcomp: Fix parser failure on floating-point numbers
Before this commit we used `strtold`, which depends on the locale. But
the XKB syntax is fixed and uses a period as decimal separator. So ensure
the syntax is correct without relying on `strtold` and truncate the
result, as the parser does not use floating-point numbers.
|
|
|
d1c279da
|
2025-03-28T07:12:16
|
|
ci: Run Linux test with a non-US locale
Hopefully this will enable us to catch locale-related bugs.
|
|
|
d3188d33
|
2025-03-28T07:11:09
|
|
test: Enable using the user locale
This enable to test different locales easily. Note that the logging
tests requires resetting the locale back to `C`.
|
|
|
d7e112fe
|
2025-03-29T19:44:13
|
|
registry: Added support for libxml2 2.14+
`libxml2-2.14+` now disallows parsing trailing `NULL` bytes, so don’t.
This is backward-compatible with previous versions of the library.
|
|
|
cc95f217
|
2025-03-25T11:15:45
|
|
xkbcomp: Fix whichGroupState serialization
This indicator field was previously looked up in the wrong table,
resulting the erroneous serialization `(null)`.
|
|
|
9a5547ce
|
2025-03-28T11:01:18
|
|
symbols: Fix leak in HandleSymbolsDef
|
|
|
955eef14
|
2025-03-28T06:30:05
|
|
tools: Ensure to honor user locale
This is just good practice, but it is also necessary if we want to
facilitate the discovery of issues with locales in libxkbcommon.
|
|
|
daee709d
|
2025-03-14T13:45:58
|
|
test: Add xkbcli compile-keymap --kccgst tests
|
|
|
47f7f93c
|
2025-03-14T13:52:02
|
|
test: Check mutually exclusive tools options
|
|
|
f01f0d63
|
2025-03-14T16:48:56
|
|
test: Check more tools options combinations
|
|
|
140e2cdd
|
2025-03-14T13:10:52
|
|
test: Make tools options parsing checks faster
|
|
|
275ffa66
|
2025-03-13T21:28:35
|
|
tools: Make --kccgst xkbcli-compile-keymap option public
The new public option `--kccgst` enables to display the result of RMLVO
resolution to KcCGST components.
This option has the same function than `setxkbmap -print`. This is particularly
useful for debugging issues with the rules.
Before this commit it was a private API. This commit enables us to remove
the *internal* version of `xkbcli-compile-keymap`.
|
|
|
8e92f25e
|
2025-03-13T21:26:59
|
|
rules: Added xkb_components_names_from_rules()
This is mainly for debugging purposes and to enable displaying KcCGST
values from RMLVO resolution in `xkbcli compile-keymap --kccgst`.
|
|
|
f3a4eeaa
|
2025-03-26T16:04:39
|
|
symbols: Improve keysym parsing
|
|
|
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`.
|
|
|
920b3d6c
|
2025-03-26T11:43:02
|
|
ci: Revert workaround unavailable gitlab.freedesktop.org
This reverts commit 2b3ffb629231e4fc0c94107a2731c20130913c8f.
|
|
|
70d11abd
|
2025-03-26T07:38:05
|
|
messages: Add file encoding and invalid syntax entries
Added:
- `XKB_ERROR_INVALID_FILE_ENCODING`
- `XKB_ERROR_INVALID_RULES_SYNTAX`
- `XKB_ERROR_INVALID_COMPOSE_SYNTAX`
Changed:
- `XKB_ERROR_INVALID_SYNTAX` renamed to `XKB_ERROR_INVALID_XKB_SYNTAX`.
|
|
|
fe0d3742
|
2025-03-18T14:41:30
|
|
registry: Fix typo in variable declaration
|
|
|
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.
|
|
|
2b3ffb62
|
2025-03-17T07:30:27
|
|
ci: Workaround unavailable gitlab.freedesktop.org
gitlab.freedesktop.org is currently migrated to a new infrastructure,
so use a release tarball of xkeyboard-config instead of cloning its repo.
NOTE: This commit should be reverted once the migration is completed.
|
|
|
4e90cb9c
|
2025-03-17T07:02:07
|
|
xkbcomp: Improve logging of virtual modifiers
When logging about virtual modifier *explicit* mappings, we should
always use only real modifiers or hexadecimal numbers to print the mask.
Consider:
```
virtual_modifiers M1, M2=0x200, M2=0x400;
```
Before this commit we would get the following warning:
```
WARNING: Virtual modifier M2 defined multiple times; Using M2, ignoring M1
```
while we would prefer the less confusing:
```
WARNING: Virtual modifier M2 defined multiple times; Using 0x400, ignoring 0x200
```
|
|
|
b3465081
|
2025-03-12T00:20:39
|
|
Bump version to 1.8.1 and update changelog
|
|
|
02b32244
|
2025-03-10T13:19:37
|
|
registry: Use safer contextual libxml2 functions
Avoid using functions depreacted in 2.13 and 2.14 libxml releases.
Follow-up of: 5f1b06b7497dc0e69ecfef8a934bce01f4f7fe8e.
|
|
|
311c8424
|
2025-03-10T13:18:51
|
|
meson: Fix libxml2 header test
|
|
9953d9f0
|
2025-03-10T21:58:05
|
|
xkbcomp/ast-build: fix possible UB in expr AST node allocations (#659)
The expression AST constructors all return `ExprDef *`. `ExprDef` is a
union of all expr types. As a memory optimization, instead of allocating
`sizeof(ExprDef)`, we only allocate the size of the actual type (e.g.
`sizeof(ExprBinary)`) which is sometimes smaller than `sizeof(ExprDef)`.
This is probably undefined behavior, and gcc (with optimization turned
on) complains about it, for example:
src/xkbcomp/ast-build.c:69:23: warning: array subscript ‘ExprDef[0]’ is partly outside array bounds of ‘unsigned char[24]’ [-Warray-bounds=]
Since it doesn't save that much memory, drop this optimization.
Fix #292.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
cb3565b1
|
2025-03-07T17:59:33
|
|
keymap: Fix segfault due to invalid group wrapping
The modular arithmetic is incorrect for negative values, e.g. for
num_groups = 1. It triggers a segfault for the following settings:
- layouts count (per key or total) N: `N > 0`, and
- layout index n: `n = - k * N` (`k > 0`)
% returns the *remainder* of the division, not the modulus (see C11
standard 6.5.5 “Multiplicative operators”: a % b = a - (a/b)*b. While
both operators return the same result for positive operands, they do
not for e.g. a negative dividend: remainder may be negative (in the
open interval ]-num_groups, num_groups[) while the modulus is always
positive. So if the remainder is negative, we must add `num_groups` to
get the modulus.
Fixes: 67b03cea ("state: correctly wrap state->locked_group and ->group")
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Co-authored-by: Julian Orth <ju.orth@gmail.com>
Co-authored-by: Pierre Le Marre <dev@wismill.eu>
|
|
|
04220319
|
2025-03-08T17:57:56
|
|
doc: Warn about the options order
Options are always applied depending of their order in the relevant
rules files, independently of their order in the relevant RMLVO config.
Since this is counter-intuitive (e.g. when using `xkbcli`), let’s
highlight this in the documentation.
|
![dependabot[bot]](https://secure.gravatar.com/avatar/48ea49be76d0c68403a7f3df87e3487d?s=48 "dependabot[bot]")
|
361b0b09
|
2025-03-01T15:46:45
|
|
build(deps): bump dawidd6/action-download-artifact from 8 to 9
Bumps [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) from 8 to 9.
- [Release notes](https://github.com/dawidd6/action-download-artifact/releases)
- [Commits](https://github.com/dawidd6/action-download-artifact/compare/v8...v9)
---
updated-dependencies:
- dependency-name: dawidd6/action-download-artifact
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
|
b2744402
|
2025-02-15T16:44:44
|
|
doc: Fix cool URIs
|
|
|
aa2928fc
|
2025-02-15T16:33:45
|
|
doc: Fix link to modules
It’s a breaking change of Doxygen. Now it’s called “topics”.
|
|
|
548fc355
|
2025-02-06T09:46:31
|
|
test: Fix inversion of expected/got in log test
|
|
|
c9b0c527
|
2025-02-13T20:26:04
|
|
interactive-wayland: Fix int casts
|
|
|
e1892266
|
2025-02-13T16:57:46
|
|
clang-tidy: Miscellaneous fixes
|
|
|
5cfd36ab
|
2025-02-14T10:35:49
|
|
tools: Do not load names from the environment by default
Our tools are debugging tools and as such we need to have complete
control to be able to reproduce setups. This is not currently the case,
as we do not use `XKB_CONTEXT_NO_ENVIRONMENT_NAMES` by default nor can
we set it.
So it is very easy to forget about the various `XKB_DEFAULT_*`
environement variables for the default RMLVO values, then to get puzzled
by unexpected results.
Added to that, these environment variables do not work correctly in
`xkbcli-compile-xeymap`: calling the tool without RMLVO values will
use these variables only if the RMLVO values are set explicitly empty or
if the various *constants* `DEFAULT_XKB_*` are empty. This is unexpected,
as the environment variables should *always* be used unless:
- `XKB_CONTEXT_NO_ENVIRONMENT_NAMES` is used (not the case here);
- the variable is empty; in this case the constants `DEFAULT_XKB_*` are
used.
Fixed by the following *breaking change*: make the tools use
`XKB_CONTEXT_NO_ENVIRONMENT_NAMES` *by default*, unless the new
`--enable-environment-names` option is used.
We also make `rmlvo` incompatible with `--enable-environment-names` for
now in the public tool, as else it requires a private API.
|
|
|
5ef19bcf
|
2025-02-13T17:58:21
|
|
xkbcomp: Fix incorrect memory comparison
Spotted by clang-tidy:
```
../src/keymap-priv.c:146:16: warning: comparing object representation of
type 'union xkb_action' which does not have
a unique object representation; consider
comparing the members of the object manually
[bugprone-suspicious-memory-comparison]
````
Indeed, from “EXP42-C. Do not compare padding data”[^1]:
> unnamed members of objects of structure and union type do not participate
> in initialization. Unnamed members of structure objects have indeterminate
> representation even after initialization.
Fixed by using a dedicated comparison function for `union xkb_action`.
[^1]: https://wiki.sei.cmu.edu/confluence/display/c/EXP42-C.+Do+not+compare+padding+data
|
|
|
2c10e50c
|
2025-02-07T12:15:39
|
|
tools: Fix compile-keymap default KcCGST values
Values may be read from the environment.
|
|
|
350931ad
|
2025-02-12T14:20:58
|
|
xkbcomp: Fix compat group index
|
|
|
f2dd0302
|
2025-02-12T14:15:26
|
|
xkbcomp: Fix LED index int type
|
|
|
2d111bbe
|
2025-02-12T13:54:51
|
|
xkbcomp: Fix possible overflow in numbers parser
|
|
|
a4038a47
|
2025-02-12T09:50:36
|
|
Miscellaneous int types fixes
|
|
|
e3108182
|
2025-02-12T09:49:25
|
|
Fix int casts related to layout index
- XkbWrapGroupIntoRange
- State
|
|
|
14a816e5
|
2025-02-11T18:41:08
|
|
xkbcomp: Fix int cast
|
|
|
6c9806ae
|
2025-02-12T07:46:07
|
|
xkbcomp: Fix ExprResolveMaskLookup error message
|
|
|
558447d8
|
2025-02-11T17:34:27
|
|
xkbcomp: Explicit vars initialization
The `Resolve*` functions do not always initialize the parameters
that they can modify, so it is safer to always initialize them at the
call site.
|
|
|
97698fca
|
2025-02-11T17:34:23
|
|
xkbcomp: Use explicit int sizes for Expr resolution
|
|
|
2d94da3d
|
2025-02-11T17:34:15
|
|
xkbcomp: Fix the int type of ExprInteger
Avoid implicit conversion from `int64_t`.
|
|
|
befa0cdd
|
2025-02-12T15:38:58
|
|
test: Check integers syntax
|
|
|
4cef822a
|
2025-02-12T07:44:34
|
|
test: Check masks syntax
|
|
|
3a0b77f0
|
2025-02-12T16:41:09
|
|
xkbcomp: Fix parser headers
|
|
|
16e3e3cb
|
2025-02-12T16:12:42
|
|
utils: Fix missing headers
|
|
|
afb9c135
|
2025-02-11T16:24:57
|
|
Update .clang-tidy
|
|
|
ce9bcbe0
|
2025-02-07T16:31:37
|
|
scripts: Rename keysyms-related files
Previous names were too generic. Fixed by using explicit names and add
the `.py` file extension.
|
|
|
945c5e3b
|
2025-02-08T00:03:24
|
|
Add clangd configuration file
It mostly works by default, as long as the meson build directory is
called "build". Just needs a couple of project-specific tweaks.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|