|
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*
|
|
|
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.
|
|
|
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" { … };
};
```
|
|
|
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>
|
|
|
afdc9cee
|
2020-10-19T10:49:37
|
|
xkbcomp: where a keysym cannot be resolved, set it to NoSymbol
Where resolve_keysym fails we warn but use the otherwise uninitialized variable
as our keysym. That later ends up in the keymap as random garbage hex value.
Simplest test case, set this in the 'us' keymap:
key <TLDE> { [ xyz ] };
And without this patch we get random garbage:
./build/xkbcli-compile-keymap --layout us | grep TLDE:
key <TLDE> { [ 0x018a5cf0 ] };
With this patch, we now get NoSymbol:
./build/xkbcli-compile-keymap --layout us | grep TLDE:
key <TLDE> { [ NoSymbol ] };
|
|
|
534e54f6
|
2020-09-07T11:38:00
|
|
test/data: add rule registry files
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
1c352199
|
2020-09-07T11:35:22
|
|
test/data: sync from xkeyboard-config 2.30
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
461d7278
|
2020-09-07T11:15:43
|
|
test/data: change quartz.xkb from CRLF to LF
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
faac4ba7
|
2019-12-28T15:52:20
|
|
test/data: ensure files are checked out with LF, not CRLF
The tests stringcomp and buffercomp do binary comparison on some files;
if the files are changed to CRLF on checkout, the tests fail.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
ca033a29
|
2019-09-03T11:23:14
|
|
rules: add include statements to rules files
The majority use-case for extending XKB on a machine is to override one or a
few keys with custom keycodes, not to define whole layouts.
Previously, we relied on the rules file to be a single file, making it hard to
extend. libxkbcommon parses $XDG_CONFIG_HOME/xkb/ but that only works as long
as there is a rule that matches the user-specified RMLVO. This works for MLV
but not for options which don't have a wildcard defined. Users have to copy
the whole rules file and then work from there - not something easy to extend
and maintain.
This patch adds a new ! include directive to rules files that allows including
another file. The file path must be without quotes and may not start with the
literal "include". Two directives are supported, %H to $HOME and %S for the
system-installed rules directory (usually /usr/share/X11/xkb/rules).
A user would typically use a custom rules file like this:
! option = symbols
custom:foo = +custom(foo)
custom:bar = +custom(baz)
! include %S/evdev
Where the above defines the two options and then includes the system-installed
evdev rule. Since most current implementations default to loading the "evdev"
ruleset, it's best to name this $XDG_CONFIG_HOME/xkb/rules/evdev, but any
valid name is allowed.
The include functionally replaces the line with the content of the included
file which means the behavior of rules files is maintained. Specifically,
custom options must be defined before including another file because the first
match usually wins. In other words, the following ruleset will not assign
my_model as one would expect:
! include %S/evdev
! model = symbols
my_model = +custom(foo)
The default evdev ruleset has wildcards for model and those match before the
my_model is hit.
The actual resolved components need only be in one of the XKB lookup
directories, e.g. for the example above:
$ cat $XDG_CONFIG_HOME/xkb/symbols/custom
partial alphanumeric_keys
xkb_symbols "foo" {
key <TLDE> { [ VoidSymbol ] };
};
partial alphanumeric_keys
xkb_symbols "baz" {
key <AB01> { [ k, K ] };
};
This can then be loaded with the XKB option "custom:foo,custom:bar".
The use of "custom" is just as an example, there are no naming requirements
beyond avoiding already-used ones. Also note the bar/baz above - the option
names don't have to match the component names.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
076047b2
|
2019-10-16T10:32:19
|
|
keymap-dump: use consistent capitalization for "Group<N>"
It's used capitalized everywhere except a couple places.
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
a6ed0304
|
2019-10-16T10:27:12
|
|
keymap-dump: fix invalid names used for levels above 8
xkbcomp only accepts the "Level" prefix for a level name for levels 1 to
8, but the keymap dumping code added it always, e.g. "Level15".
The plain integer, e.g. "8", "15" is always accepted, so just use that.
Fixes https://github.com/xkbcommon/libxkbcommon/issues/113
Signed-off-by: Ran Benita <ran@unusedvar.com>
Reported-by: progandy
|
|
6456835f
|
2017-12-03T13:04:35
|
|
test/data: sync with xkeyboard-config 2.22
Some tweaks to the de(neo) keyseq tests were required. It seems to have
improved.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
74f85d05
|
2015-08-23T23:02:10
|
|
test/x11comp: remove duplicate FOUR_LEVEL_KEYPAD from test keymap
The `test/data/keymaps/host.xkb` file contains a duplicate definition of
this type. On my computer (linux, xkbcomp 1.3.0, xserver 1.17.2), the
test passes as is, but if I remove the duplicate definition, the
roundtrip brings it back and the test fails. I can also reproduce it
without relation to the test, by loading `test/data/keymaps/host.xkb`
(without the duplicate) using
xkbcomp -I $(pwd)/test/data/keymaps/host.xkb $DISPLAY
and downloading it again using
xkbcomp $DISPLAY out.xkb
the duplicate is added. On Mac OS X however, the duplicate is removed
(correctly), so the test fails there.
xkbcommon itself, which was forked from xkbcomp, doesn't have this bug;
in fact, doing
./test/print-compiled-keymap -k keymaps/host.xkb
removes the duplicate if it is present.
This is (probably) a regression in xkbcomp or xserver compared to the
versions used in Mac OS X. Since getting a patch for any of these two is
hopeless from my experience, I did not try to investigate further.
I am not sure why, but if I also add a `PC_SUPER_LEVEL2` type, the
duplicate of `FOUR_LEVEL_KEYPAD` doesn't show up. Hopefully the test
will work on all platforms now.
https://github.com/xkbcommon/libxkbcommon/issues/26
Reported-by: @nuko8
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
312182ce
|
2014-10-16T17:55:46
|
|
test/data: add files for model=applealu_ansi layout=us
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c6ee6371
|
2014-10-16T17:48:00
|
|
test/data: sync to xkeyboard-config 2.13
(Run ./test/data/sync.sh).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
10a7a2bd
|
2013-10-27T20:37:27
|
|
test/compose: add new test
Some results from the benchmark (compilation of en_US.UTF-8/Compose):
$ grep 'model name' /proc/cpuinfo
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
$ uname -a
Linux ran 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux
$ ./test/compose bench
compiled 1000 compose tables in 7.776488331s
So according to the above benchmark and valgrind --tool=massif, an
xkb_compose_table adds an overhead of about ~8ms time and ~130KB
resident memory.
For contrast, a plain US keymap adds an overhead of ~3ms time and 90KB
resident memory.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
68962aa1
|
2014-09-21T23:54:34
|
|
keymap-dump: combine modifier_map's with the same modifier
A bit less efficient, but makes for shorter, nicer output.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
a931740c
|
2014-09-10T13:29:52
|
|
keycodes: fix keymap compilation with no aliases and malloc(0)==NULL
If the keymap doesn't have any key-aliases (which is certainly
possible), the calloc(num_key_aliases, ...) is allowed to return NULL
according to the C standard, but this is not an error.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4df720b4
|
2014-08-09T22:14:34
|
|
test/x11-keyseq: new test
It is like test/stringcomp, only instead of using
xkb_keymap_new_from_string(), it uses xkbcomp to upload the keymap to a
dummy Xvfb X server and then xkb_x11_keymap_new_from_device().
If any of these components are not present or fails, the test is shown
as skipped.
The test is messy, fragile, limited and depends on external tools, but I
will improve on that later -- it's better to have a test.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
40f109af
|
2014-07-27T14:24:20
|
|
ast-build: make sure InterpDef is freeable
With the following two rules:
InterpretDecl : INTERPRET InterpretMatch OBRACE
VarDeclList
CBRACE SEMI
{ $2->def = $4; $$ = $2; }
;
InterpretMatch : KeySym PLUS Expr
{ $$ = InterpCreate($1, $3); }
| KeySym
{ $$ = InterpCreate($1, NULL); }
;
And the fact that InterpCreate doesn't initialize ->def, if the
VarDeclList fails, the %destructor tries to recursively free the
uninitialized ->def VarDef. So always initialize it.
That was the only problematic code in the parser for %destructor (I'm
pretty sure).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
f5182bbd
|
2014-07-26T22:29:22
|
|
test: add file with a syntax error
We didn't really have any. It also a exposes a memory leak, since the
parser doesn't clean up the AST nodes of the discarded symbols.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
11a9f76b
|
2014-02-15T23:27:23
|
|
keymap-dump: don't print "affect=lock" in PtrLock
It's the same as no flags, so might as well not print it.
(In fact it is slightly harmful, because it actively *clears* the affect
flags, which might have been set in some other manner. But in practice
this cannot happen).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
ba7530fa
|
2013-11-27T13:43:57
|
|
scanner: restore lost DIVIDE token
I don't know how this could have happened. Luckily this token is
completely useless.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
65f9980b
|
2013-10-14T19:05:24
|
|
rules: fix scanning of line-continuation without leading space
We were failing to scan something like\
this correctly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9cef902d
|
2013-08-14T11:35:01
|
|
test: make sure keycode 0 works fine
It is a legal keycode but we never tried it actually.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7caa1af2
|
2013-08-13T14:45:33
|
|
scanner: don't fail over unknown escape sequence
This is too strict, and causes symbols/cz to fail parsing. Instead, just
emit a warning (not shown by default):
xkbcommon: WARNING: cz:75:19: unknown escape sequence in string literal
https://bugs.freedesktop.org/show_bug.cgi?id=68056
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e91d2653
|
2013-08-01T23:09:46
|
|
scanner: allow empty key name literals
Some keymaps actually have this, like the quartz.xkb which is tested. We
need to support these.
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
e731b251
|
2013-08-01T20:24:27
|
|
xkbcomp: handle empty keymaps
We should handle empty xkb_keycode and xkb_symbol sections, since
xkbcomp handles them, and apparently XQuartz uses it. There are also
files for it in xkeyboard-config (rules=base model=empty layout=empty,
which translate to keycodes/empty and symbols/empty).
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
0c8e9e0c
|
2013-07-22T18:43:53
|
|
test: sync test/data from xkeyboard-config 2.9
Needed for some tests. The tests need some adjustment, mostly because of
the resolution of xkeyboard-config bug
https://bugs.freedesktop.org/show_bug.cgi?id=50935
Also add the 'ch' symbols file for future tests.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
17a956d8
|
2013-05-09T14:47:09
|
|
Widen keycode range to 8/255 if possible (bug #63390)
If the keycode range is smaller than 8 → 255, artifically widen it when
dumping the keymap as not to displease X.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
e95dac76
|
2013-02-25T12:03:06
|
|
keymap-dump: don't indent after xkb_keymap {
xkbcomp doesn't indent there, so it's easier to diff.
Also saves some horizontal space which is sorely needed when looking at
these files (especially the xkb_symbols).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4a59c84e
|
2013-02-25T12:09:17
|
|
keymap-dump: remove some ugly empty lines
xkbcomp prints them too, but that's just annoying. Also xkb_keycodes
doesn't have it already.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c7aef166
|
2013-02-19T15:57:14
|
|
keysym: print unicode keysyms uppercase and 0-padded
Use the same format as XKeysymToString.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
089c3a18
|
2013-02-17T14:59:50
|
|
state: fix unbound virtual modifier bug
Recent xkeyboard-config introduced the following line in symbols/level3:
vmods = LevelThree,
However, the XKM format which xkbcomp produces for the X server can't
handle explicit virtual modifiers such as this:
https://bugs.freedesktop.org/show_bug.cgi?id=4927
So by doing the following, for example:
setxkbmap -layout de (or another 3-level layouts)
xkbcomp $DISPLAY out.xkb
xkbcomp out.xkb $DISPLAY
The modifier is lost and can't be used for switching to Level3 (see the
included test).
We, however, are affected worse by this bug when we load the out.xkb
keymap. First, the FOUR_LEVEL_ALPHABETIC key type has these entries:
map[None] = Level1;
map[Shift] = Level2;
map[Lock] = Level2;
map[LevelThree] = Level3;
[...]
Now, because the LevelThree virtual modifier is not bound to anything,
the effective mask of the "map[LevelThree]" entry is just 0. So when
the modifier state is empty (initial state), this entry is chosen, and
we get Level3, instead of failing to match any entry and getting the
default Level1.
The difference in behavior from the xserver stems from this commit:
acdad6058d52dc8a3e724dc95448300850d474f2
Which removed the entry->active field. Without bugs, this would be
correct; however, it seems in this case we should just follow the
server's behavior.
The server sets the entry->active field like so in XKBMisc.c:
/* entry is active if vmods are bound */
entry->active = (mask != 0);
The xkblib spec explains this field, but does not specify how to
initialize it. This commit does the same as above but more directly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
40581106
|
2013-02-17T11:22:41
|
|
Sync test data from xkeyboard-config
Sync the files again from xkeyboard-config 2.8, since there have been
some changes we should test against.
Also added a script test/data/sync.sh if we want to do it again in the
future.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
22684cd1
|
2012-09-30T10:50:38
|
|
parser: remove XkbCompMapList rule
This rule allows you to put several xkb_keymaps in one file.
This doesn't make any sense: only the default/first can ever be used,
yet the others are fully parsed as well.
Different keymaps should just be put in different files.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
92e07726
|
2012-09-27T20:16:12
|
|
test: add keycodes files which map directly to evdev codes
This is a proof-of-concept for the long key names. The keycodes in the
file evdev-xkbcommon are autogenerated from linux/input.h, and uses the
names given there; all of the previous names are aliased to the new
names, so they continue to work with the symbols files, etc.
You can try it with 'sudo ./test/interactive -r evdev-xkbcommon -n 0'
The -n 0 means that we don't offset the evdev scan codes - just feed
them directly. The -r evdev-xkbcommon just means to use a new rules file
which makes us use the new keycodes file. (The only problem I can see is
with the MENU and LSGT names which has some conflicts).
Maybe some day xkeyboard-config could ship something similar, so that
the 8 offset is unneeded.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
32c19f4b
|
2012-09-27T21:30:29
|
|
keymap-dump: make it look better with long key names
Not worth messing around with too much, just make it legible.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
4b69d6f7
|
2012-09-15T02:09:34
|
|
keycodes: ignore explicit minimum/maximum statements
These statements are pretty pointless for us; we don't restrict keycodes
like X does, and if someone writes e.g. maximum = 255 but only has 100
keys, we currently happily alloc all those empty keys. xkbcomp already
handles the case when these statements aren't given, and uses a computed
min/max instead. We should just always use that.
(Of course since keycodes/evdev currently uses almost all of the
keycodes in the range it declares, including 255, this doesn't save any
memory for the common user right now).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
a9fa3739
|
2012-09-12T16:39:54
|
|
keymap-dump: don't write spaces between multiple-syms-per-level
This can get a bit unwieldy.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
7f04ffc4
|
2012-08-29T12:10:28
|
|
rules: fix check for appending '|' character when applying
There are two ways to separate multiple files in XKB include statements:
'+' will cause the later file to override the first in case of conflict,
while '|' will cause it augment it (this is done by xkbcomp). '!' is
unrelated here.
Since '|' is practically never used, this wasn't noticed.
In the modified test, the '|some_compat' previously was just ignored.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
2a026f6f
|
2012-08-28T15:55:35
|
|
test/data/symbols: keypad can only have one default section
Avoids a warning, from xkeyboard-config:
commit 6676053f2c93596c2aaa9905151a5c76355a1540
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Fri Jun 29 09:53:45 2012 +1000
symbols: keypad can only have one default section
Warning: Multiple default components in keypad
Using x11, ignoring pointerkeys
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9de067aa
|
2012-08-27T21:31:18
|
|
compat: ignore "group" (compatibility) statements
Group compatibility statements are like the following:
group 3 = AltGr;
This currently results in:
keymap->groups[2].mask = <real mod mapped from AltGr vmod>
And we don't do any thing with this value later. The reason it exists in
XKB is to support non-XKB clients (i.e. XKB support disabled entirely in
the server), which do not know the concept of "group", and use some
modifier to distinguish between the first and second keyboard layouts
(usually with the AltGr key). We don't care about all of that, so we can
forget about it.
One artifact of this removal is that xkb_map_num_groups no longer
works, because it counted through keymap->groups (this wasn't entirely
correct BTW). Instead we add a new num_groups member to the keymap,
which just hold the maximum among the xkb_key's num_groups. This also
means we don't have to compute anything just to get the number of
groups.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
16f2de8b
|
2012-08-14T16:26:30
|
|
compat: ignore "locking" field in sym interprets
This field is used in conjunction with key behaviors, which we don't
support since c1ea23da5. This is also unused in xkeyboard-config.
Signed-off-by: Ran Benita <ran234@gmail.com>
|