|
ac9cd053
|
2025-06-11T19:00:47
|
|
test: Check extended layout indexes
|
|
|
7f39be25
|
2025-06-10T15:46:45
|
|
test: Use explicit keymap output format for test_compile_output()
|
|
|
0f89ad97
|
2025-06-09T19:26:13
|
|
dump: Always use numeric group indexes
The upcoming raise of the maximum groups count will require to use
numeric group indexes instead of the syntax `GroupN` if groups > 8.
Let’s not bother with handling two cases (group count ≤ 8 or > 8) and
always serialize group indexes as numeric values.
|
|
|
9951184e
|
2025-05-10T10:15:54
|
|
actions: Properly reset type to NoAction on error
If we do not reset the type, the action may lready have been initialized
to with a default action and thus will not be ignored.
|
|
|
22d27277
|
2025-05-10T10:12:31
|
|
actions: Reject arguments if they are not expected
`NoAction`, `VoidAction` and `TerminateServer` do not accept arguments.
|
|
|
d239a3f0
|
2025-05-11T11:42:20
|
|
actions: Improve unsupported legacy X11 actions handling
- Display a warning
- Document drawbacks of degrading to `NoAction()`
|
|
|
b4c89600
|
2025-05-09T15:15:10
|
|
actions: Add VoidAction(), mirroring NoSymbol/VoidSymbol.
Added `VoidAction()` action to match the keysym pair
`NoSymbol` / `VoidSymbol`.
It enables overriding a previous action and breaks latches.
This is a libxkbcommon extension. When serializing it will be converted to
`LockControls(controls=none,affect=neither)` for backward compatibility.
We cannot serialize it to `NoAction()`, as it would be dropped in e.g.
the context of multiple actions.
|
|
|
e00a5e83
|
2025-05-07T16:10:04
|
|
Add tests for pure virtual modifiers
|
|
|
c2d3694b
|
2025-05-06T07:01:01
|
|
xkbcomp: Do not discard extra bits in vmod masks
Since we accept numeric values for the vmod mask in the keymap, we may
have extra bits set that encode *no* real/virtual modifier. Keep them
unchanged for consistency.
E.g. the following keymap:
xkb_keymap {
xkb_keycodes { <a> = 38; };
xkb_symbols {
virtual_modifiers X = 0xf0000000;
key <a> { [ SetMods(mods = 0x00001100) ] };
};
};
would compile to:
xkb_keymap {
xkb_keycodes { <a> = 38; };
xkb_symbols {
virtual_modifiers X = 0xf0000000;
// Internal state
key <a> { [ SetMods(mods = 0xf0001000) ] };
// Serialization
key <a> { [ SetMods(mods = 0x00001100) ] };
};
};
|
|
|
d5b779e1
|
2025-05-06T21:07:28
|
|
keymap: Fix empty compat interpretation map serialization
X11’s `xkbcomp` requires at least one compat interpretation entry.
|
|
|
87f9ac76
|
2025-05-06T21:02:23
|
|
keymap: Fix empty compat interpretation statement serialization
Statements such as `interpret VoidSymbol {};` can cannot be parsed by
X11’s `xkbcomp`.
Fixed by using a dummy action.
|
|
|
cd512b8f
|
2025-05-02T19:21:09
|
|
x11: Fix capitalization transformation
|
|
|
9b0b8c68
|
2025-04-15T19:53:28
|
|
xkbcomp: Stricter handling of default map include
Before this commit, including a *default* map, i.e. without an explicit
section name (e.g. `include "au"` vs `include "au(basic)"`) would match
the first section of the first matching file in the XKB include paths,
even if this section is not an *explicit* default map (i.e. tagged with
`default`) but an *implicit* default map (i.e. the first map of the
file, i.e. a weak match).
It makes user configuration risky: say a user wants to create a custom
version `au(custom)` of the `au` layout:
- `./config/xkb/symbols/au`: custom layout in section “custom”.
- `/usr/share/X11/xkb/symbols/au`: system layout, with *default* section
“basic”.
In this setup *any* layout that imports the default map from `au` would
in fact import the *implicit* default map `au(custom)` instead of the
*explicit* default map `au(basic)`.
This incorrect behavior may thus break setups with multiple layouts.
This is especially true for symbols files such as: `pc`, `us` or `latin`.
Fixed by trying harder to found the exact default map, defaulting to the
old behavior (weak match) only if no *explicit* default map (exact match)
has been found in the XKB include paths.
|
|
|
636b8b97
|
2025-03-19T14:11:52
|
|
test: Add merge mode tests for all the sections
The merge modes tests C file is now only generated locally, because it
is too large. The generator Python script requires Jinja2, so the test
is optional and depends on Jinja22 availability.
The test aim to be exhaustive with various combinations of a base and
an update:
- plain base + plain update, for every mode
- plain base + include (for every mode) update (every mode)
- single include (base +| update)
|
|
|
66f71890
|
2025-03-31T08:01:29
|
|
symbols: Enable writing keysyms list as UTF-8 strings
Each Unicode code point of the string will be translated to their
respective keysym, if possible. An empty string denotes `NoSymbol`.
When such conversion is not possible, this will raise a syntax error.
This introduces the following syntax:
```c
// Empty string = `NoSymbol`
key <1> {[""]}; // NoSymbol
// Single code point = single keysym
key <2> {["é"]}; // eacute
// String = translate each code point to their respective keysym
key <3> {["sßξك🎺"]}; // {s, ssharp, Greek_xi, Arabic_kaf, U1F3BA}
// Mix string and keysyms
key <4> {[{"ξ", Greek_kappa, "β"}]}; // { Greek_xi, Greek_kappa, Greek_beta}
```
It can also be used wherever a keysym is required, e.g. in `interpret`
and `modifier_map` statements. In these cases a single keysym is expected,
so the string should contain *exactly one* Unicode code point.
|
|
|
ead3ce77
|
2025-03-28T21:44:27
|
|
scanner: Enable LRM and RLM marks for BiDi text
Enable displaying bidirectional text in XKB files using:
- U+200E LEFT-TO-RIGHT MARK
- U+200F RIGHT-TO-LEFT MARK
We now parse these marks as white space. As such, they are dropped;
note that a later serialization may not display correctly without
the marks, although it will parse.
References:
- https://www.w3.org/International/articles/inline-bidi-markup/uba-basics
- https://www.w3.org/International/questions/qa-bidi-unicode-controls
- https://www.unicode.org/reports/tr31/#Whitespace
- https://www.unicode.org/reports/tr55/
|
|
|
bc3e464b
|
2025-04-09T12:35:05
|
|
keysyms: Fix Unicode handling
- `xkb_utf32_to_keysym`: Allow [Unicode noncharacters]. There is no
requirement to drop them and this would be the only function of our
API doing so.
From the Unicode Standard 16.0, section 23.7 “Noncharacters”:
> Applications are free to use any of these noncharacter code points
> internally. They have no standard interpretation when exchanged
> outside the context of internal use. However, they are not illegal
> in interchange, nor does their presence cause Unicode text to be
> ill-formed.
> If a noncharacter is received in open interchange, an application is
> not required to interpret it in any way. It is good practice,
> however, to recognize it as a noncharacter and to take appropriate
> action, such as replacing it with `U+FFFD` REPLACEMENT CHARACTER,
> to indicate the problem in the text.
The key part is:
> an application is not required to interpret it in any way
Since we handle the reverse conversion with `xkb_keysym_to_utf32` just
fine, I do not see a good motivation to keep this asymmetry. This is
the only function with a special case for these code points.
- `xkb_keysym_from_name`:
- Unicode format `UNNNN`: allow control characters C0 and C1 and use
`xkb_utf32_to_keysym` for the conversion when `NNNN < 0x100`, for
backward compatibility.
- Numeric hexadecimal format `0xNNNN`: *unchanged*. Contrary to the
Unicode format, it does not normalize any keysym values in order to
enable roundtrip with `xkb_keysym_get_name`.
Also added tests to ensure various properties and consistency.
Note about *surrogates*: they are valid valid *code points* but invalid
Unicode *scalar values*, i.e. they cannot be encoded in any Unicode
encoding form (UTF-8, UTF-16, UTF-32). So their corresponding Unicode
keysyms are valid, but:
- cannot be used as input of `xkb_keysym_to_utf32` nor `xkb_keysym_to_utf8`
- cannot result as output of `xkb_utf32_to_keysym`.
Otherwise they are valid e.g. in the Unicode keysym notation.
[Unicode noncharacters]: https://en.wikipedia.org/wiki/Universal_Character_Set_characters#Noncharacters
|
|
|
5e557040
|
2025-04-09T11:17:00
|
|
xkbcomp: Fix Unicode escape sequence
While the previous code correctly rejected malformed sequences such as
`\u{` (incomplete) or `\u{123x}`, it should try to consume as much input
as possible until reaching the corresponding closing `}` within the
string. Else we can get leftovers and the error message does not
reference the whole malformed sequence.
Also added further tests with surrogates and noncharacters.
|
|
|
36442baa
|
2025-04-03T15:01:46
|
|
xkbcomp: Support multiple actions in interpret
Before this commit we supported multiple actions per level, but not in
*interpret* statements. Let’s fix this asymmetry, so we can equivalently
assign all actions sets either implicitly or explicitly.
|
|
|
6d4cc135
|
2025-04-05T13:39:30
|
|
xkbcomp: Escape ASCII control characters
|
|
|
3d79f459
|
2025-03-29T11:46:34
|
|
xkbcomp: Add Unicode code point escape sequence \u{NNNN}
Unicode code point escape sequences `\u{NNNN}` are replaced with the
UTF-8 encoding of their corresponding code point `U+NNNN`, if legal.
Supported Unicode code points are in the range `1‥0x10ffff`.
Note that we will reject the `U+0000` NULL code point, as we reject it
in the octal escape sequence `\0`.
This is intended mainly for the upcoming feature to write keysyms as
UTF-8 encoded strings. It can be used for various reasons:
- avoid encoding issues;
- avoid issue with font rendering (e.g. Asian scripts);
- make white space or zero-width characters more readable.
|
|
|
7d91a753
|
2025-03-29T12:24:39
|
|
xkbcomp: Enable xkbcomp-style octal escape sequences
Xorg xkbcomp only parses octal sequences with `\0`, while xkbcommon
does not force the `0` prefix of the numeric part. However, we only
parsed up to to 3 digits, which does not allow to parse e.g. `\0377`
while `\377` parses fine.
Fixed by parsing up to 4 octal digits, while checking the result fits
into a byte.
|
|
|
aa8b572e
|
2025-03-29T12:04:26
|
|
keymap serialization: Ensure escaping relevant chars
Previously we would write characters without any escaping in some
cases (e.g.: names of indicators, types and groups). E.g. the string
"new\nline"
would be serialized as:
"new
line"
which would raise a syntax error if parsed.
Fixed by escaping any string that was not escaped after parsing (e.g.
the section names are safe already).
|
|
|
d5a91fa9
|
2025-04-04T16:38:16
|
|
xkbcomp: Use custom parsers instead of strtol*
The use of `strtol*` functions was already restricted due to its
slowness and its capacity to parse other stuff than digits (e.g.
signs and spaces).
There is also another *big* limitation: it requires a NULL-terminated
string. This is incompatible with our functions that work on buffers,
because we cannot guarantee this. This may lead to a memory violation
if the last token is a number.
We now roll out our own parsers, which are more efficients and
compatible with buffers.
|
|
|
44480f7c
|
2025-04-01T08:28:02
|
|
xkbcomp: Enable lists of keysyms and actions {} and {a}
Motivations:
- Follow the principle of least astonishment;
- Ensure consistency;
- Enhance the use of custom defaults;
- Facilitate the tests.
There is some ambiguity because we use `{}` to denote both an empty list of
keysyms and an empty list of actions. But as soon as we get a keysym or an
action, we know whether it is a `MultiKeySymList` or a `MultiActionList`.
So we just count the `{}` at the *beginning* using `NoSymbolOrActionList`,
then replace it by the relevant count of `NoSymbol` or `NoAction()` once the
ambiguity is solved. If not, this is a list of empties of *some* type: we
drop those empties and delegate the type resolution using `ExprEmptyList()`.
|
|
|
e09cbe66
|
2025-04-02T10:46:06
|
|
symbols: Fix handling of empty keys
Before this commit, the following symbols:
```c
xkb_symbols {
virtual_modifiers M1, M2;
key <A> {};
key <B> { [] };
key.vmods = M1;
key <C> {};
key <D> { vmods = M2 };
};
```
would be equivalent to:
```c
xkb_symbols {
virtual_modifiers M1,M2;
key <B> { [ NoSymbol ] };
};
```
`<B>` entry could be skipped but is harmless. However, `<C>` and `<D>`
are missing, which would lead to the mapping resolution of `M1` and
`M2` failing.
After this commit, it is equivalent to:
```c
virtual_modifiers M1,M2;
key <C> { vmods = M1 };
key <D> { vmods = M2 };
```
Empty keys are skipped entirely, but any explicit field:
- is taken into account: previously they would be skipped if there
were no group;
- forces the key to be printed at serialization.
|
|
|
2e0245f8
|
2025-04-02T10:45:44
|
|
xkbcomp: Enable more empty lists
- Empty `interpret`
- Empty key `type`
- Empty `indicator`
Motivations:
- Follow the principle of least astonishment;
- Ensure consistency;
- Enhance the use of custom defaults;
- Facilitate the tests.
|
|
|
6881fb32
|
2025-04-01T08:28:02
|
|
xkbcomp: Drop trailing NoSymbol and NoAction()
This brings us closer to what `xkbcomp` outputs. One should use
the explicit `VoidSymbol` instead of `NoSymbol`, in order to avoid
dropping empty levels.
This may affect keys that rely on an *implicit* key type. Example:
- Input:
```c
key <> { [a, A, NoSymbol] };
```
- Compilation with xkbcommon \< 1.9.0:
```c
key <> {
type= "FOUR_LEVEL_SEMIALPHABETIC",
[a, A, NoSymbol, NoSymbol]
};
```
- Compilation with xkbcommon ≥ 1.9.0:
```c
key <> {
type= "ALPHABETIC",
[a, A]
};
```
|
|
|
fbacdd98
|
2025-03-31T07:58:04
|
|
test: Refactor test_multi_keysyms_actions
- Use less macros
- Add golden tests to check the compilation *result*
|
|
|
8ba5c453
|
2025-03-30T10:07:10
|
|
xkbcomp: Use section reference as default section name
Before this commit the following keymap:
```c
xkb_keymap {
xkb_keycode {};
};
```
would result in (boilerplate removed):
```c
xkb_keymap {
xkb_keycode "(unnamed)" {};
};
```
This is both useless and wasting allocation: section names are optional,
so we should just remove this default name altogether and keep it
undefined, as in the original keymap.
The situation is a bit different if there is an include, as for keymaps
created from RMLVO names. Before this commit, the following keymap:
```c
xkb_keymap {
xkb_keycode { include "evdev+aliases(qwerty)" };
};
```
would result in (boilerplate removed):
```c
xkb_keymap {
xkb_keycode "(unnamed)" { … };
};
```
With this commit we now follow the Xorg xkbcomp style by using the
section reference (the include string) as the *default* section name. So
the previous example would now result in:
```c
xkb_keymap {
xkb_keycode "evdev_aliases(qwerty)" { … };
};
```
which is useful to give a hint of the original include.
Note that if the original section had a name, it would preserve it:
```c
xkb_keymap {
xkb_keycode "test" { include "evdev+aliases(qwerty)" };
};
```
would compile to:
```c
xkb_keymap {
xkb_keycode "test" { … };
};
```
|
|
|
3150bca8
|
2025-03-30T09:54:02
|
|
xkbcomp: Make all components optional
We already accept *empty* components, such as: `xkb_compat {};`. Let’s
accept missing components as well, so that we can reduce the boilerplate
in our tests.
Note that we will still explicitly serialize empty components for
compatibility with previous xkbcommon versions and Xorg xkbcomp.
|
|
|
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
|
|
|
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.
|
|
|
b0d9a790
|
2025-01-15T12:03:10
|
|
vmods: Fix explicit vmods not dumped
|
|
|
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.
|
|
|
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
|
|
|
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
|
|
|
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) ]
};
```
|
|
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
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
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>
|
|
|
461d7278
|
2020-09-07T11:15:43
|
|
test/data: change quartz.xkb from CRLF to LF
Signed-off-by: Ran Benita <ran@unusedvar.com>
|
|
|
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
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
93f6517c
|
2012-08-03T04:07:33
|
|
stringcomp: Make test more punishing
Recreate the old test/dump scenario, where we test the following map:
- rules: evdev
- model: pc104
- layout #1: us
- layout #2: ru
- layout #3: ca(multix)
- layout #4: de(neo)
This is ever so slightly altered from the xkbcomp output; running the
following:
setxkbmap -rules evdev -model pc105 -layout us,ru,ca,de -variant
,,multix,neo -print | xkbcomp -xkb - -
will give you a map with RCTL added to the modifier_map for both Control
and Mod3. Running the output through xkbcomp -xkb - - again, will give
you RCTL only added to Mod3.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
6701fb5f
|
2012-08-03T03:54:44
|
|
stringcomp: Remove unnecessary Level1 mappings
As a map will implicitly go to level one unless explicitly mentioned
otherwise, remove all explicit =Level1 mappings, except for those with
preserve entries.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
e756e9b5
|
2012-08-03T04:02:31
|
|
test/dump: Remove superfluous test
No longer necessary now we have stringcomp doing a full round-trip test
for us.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
39da9274
|
2012-08-03T03:38:46
|
|
stringcomp: Update input file for output changes
Bring the input file into line with recent changes to the dump output,
so we're as close as we can get to a round trip.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
a681c624
|
2012-08-07T08:17:26
|
|
types: remove DeleteLevel1MapEntries
If there is no map entry for some modifier combination, the default is
to use level 1. The removed code is an optimization to save some space
by removing these entries. But it doesn't actually save any space, and
did not in fact remove all level 1 entries (it walks the array while
modifying it so there's an off-by-one error).
We can instead keep them in the types but just not print them in
keymap-dump.c, to get about the same behavior.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
b0b11c4e
|
2012-08-02T00:29:07
|
|
types: don't use canonical/required types
Xkb required every keymap to have at least the four following canonical
types: ONE_LEVEL, TWO_LEVEL, ALPHABETIC, KEYPAD. This is specified in
e.g. the kbproto spec and XkbKeyTypesForCoreSymbols(3) man page.
If these types are not specified in the keymap, the code specifically
checks for them and adds them to the 4 first places in the types array,
such that they exist in every keymap. These are also the types (along
with some non-required 4-level ones) that are automatically assigned to
keys which do not explicitly declare a type (see FindAutomaticType in
symbols.c, this commit doesn't touch these heuristics, whcih are also not
very nice but necessary).
The xkeyboard-config does not rely on the builtin xkbcomp definitions of
these types and does specify them explicitly, in types/basic and
types/numpad, which are virtually always included.
This commit removes the special behavior:
- The code is ugly and makes keytypes.c harder to read.
- The code practically never gets run - everyone who uses
xkeyboard-config or a keymap based upon it (i.e. everyone) doesn't need
it. So it doesn't get tested.
- It mixes policy with implementation for not very good reasons, it
seems mostly for default compatibility with X11 core.
- And of course we don't need to remain compatible with Xkb ABI neither.
Instead, if we read a keymap with no types specified at all, we simply
assign all keys a default one-level type (like ONE_LEVEL), and issue
plenty of warnings to make it clear (with verbosity >= 3). Note that
this default can actually be changed from within the keymap, by writing
something like
type.modifier = Shift
type.whatever_field = value
in the top level of the xkb_types section. (This functionality is
completely unused as well today, BTW, but makes some sense).
This change means that if someone writes a keymap from scratch and
doesn't add say ALPHABETIC, then something like <AE11> = { [ q Q ]; }; will
ignore the second level. But as stated above this should never happen.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c6279b8b
|
2012-07-23T21:21:03
|
|
expr: don't divide by zero
Calculator parser 101.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
3640e14d
|
2012-07-13T00:39:34
|
|
Add multiple-keysyms-per-level to test data
Make sure this keeps on working.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
a77e9a92
|
2012-07-13T00:12:57
|
|
tests: Update dump.data for recent fixes
Makes the test pass again.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
f0599675
|
2012-07-11T16:16:20
|
|
dump: add back kccgst names
Readd the component names to the keymap->names struct. This is used when
printing the component, e.g.
xkb_keymap {
xkb_keycodes "evdev+aliases(qwerty)" {
instead of
xkb_keymap {
xkb_keycodes {
This makes diffing against xkbcomp $DISPLAY a bit easier and is kind of
useful anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
fe5bfdf9
|
2012-07-11T16:35:43
|
|
dump: a few more tweaks to match xkbcomp output
Only uppercase / lowercase stuff.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
9e505225
|
2012-07-12T19:28:52
|
|
symbols: fix bug in modifier_map handling
The code used to match a keysym to a keycode (see added comment)
differed in behavior from xkbcomp, always taking the first key it found.
This caused some incorrect interpretation of the xkeyboard-config data,
for example the one corrected in dump.data (see the diff): since the
de-neo layout sets the both_capslock option, the Left Shift key (LFSH)
has the Caps_Lock keysym in group 4 level 2; now since
keycode(Left Shift) = 50 < keycode(Caps Lock) = 64
the Left Shift one was picked, instead of the Caps Lock one which is
group 1 level 1. The correct behavior is to pick according to group,
level, keycode.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
62deaeb5
|
2012-07-12T14:42:31
|
|
Import dataset into test/data/
Use a self-contained dataset instead of relying on a globally-installed
set. Data taken from xkeyboard-config 2.5.1.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
|
059c1842
|
2012-07-12T12:02:19
|
|
Move test data files to test/data/keymaps
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|