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.
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.
The current `xkb_compose_table_iterator_next` segfaults when used with an
empty table. Indeed, in this case we initialize cursors in
`xkb_compose_table_iterator_new` with the dummy node and the direction
`NODE_LEFT`, but the dummy node is a leaf!
Fixed by initializing with no cursors when the table is has no non-dummy
nodes.
Fixed the upper case mappings for:
- XKB_KEY_ydiaeresis
- XKB_KEY_mu
- XKB_KEY_ssharp
Note: In Unicode, the upper case of “ß” (U+00DF) is *not* “ẞ” (U+1E9E)
but “SS”. “ẞ” is reserved for text in capitals.
Added tests of the simple case mappings when the ICU library is
available. A warning is raised for missing mappings.
Note: `xkb_keysym_is_upper` is interpreted as matching the disjunction of the
Unicode character properties “Uppercase” or “Titlecase”.
Currently `xkb_keysym_is_modifier` does not detect the following keysyms:
- `XKB_KEY_ISO_Level5_Shift`
- `XKB_KEY_ISO_Level5_Latch`
- `XKB_KEY_ISO_Level5_Lock`
Indeed, there is a mistake in the keysym interval that the code checks.
The reason seems a confusing order of the keysyms in
`xkbcommon-keysyms.h`: the current code has a comment “libX11 only goes
up to XKB_KEY_ISO_Level5_Lock”, but in fact the modifiers keysyms are
listed in a _semantic_ order in `xkbcommon-keysyms.h`, not in the
increasing keysym _value_ order.
Fixed by using the same (correct) code as libX11 and added some tests.
Currently there is no indication of the maximum length of keysym names.
This is statically known, so add the new *internal* following API:
`XKB_KEYSYM_NAME_MAX_SIZE`.
Add an efficient way to iterate over the assigned keysyms.
Currently only provided for testing, so we guard it by
`ENABLE_PRIVATE_APIS` in order to reduce the installed library.
Currently there is no direct way to know the minimum and maximum keysym
values that are assigned, i.e. that have an explicit name or are
Unicode keysyms.
Introduce the new following internal API:
- XKB_KEYSYM_MIN_ASSIGNED
- XKB_KEYSYM_MAX_ASSIGNED
- XKB_KEYSYM_MIN_EXPLICIT
- XKB_KEYSYM_MAX_EXPLICIT
- XKB_KEYSYM_COUNT_EXPLICIT
Also add a bunch of tests to ensure consistant keysyms bounds.
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.
Add excerpt of `util-mem.h` from libei defining the macro `steal`, in
order to improve memory management and the code semantics.
See: 38132d6fc5/src/util-mem.h (L92)
Previously the attribute “popularity” was completely ignored. It also
did not respect the modified DTD, because its default value depends if
we are currently parsing an “extras” rules file.
Fixed:
- Always parse the popularity attribute.
- Change the DTD to reflect that the default value is implied.
Current options to set the locale are convoluted:
- An explicit locale *must* be given, while a sane default would be
to use the user environment.
- Then there are two options that were useful while testing locale
handling: read environment variables or use `setlocale`. But the
program has already called:
```
setlocale(LC_ALL, "");
```
so it turns out the two options lead to the same results.
Remove options `--locale-from-env` and `--locale-from-setlocale`
and make the locale default to the user environment.
- 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.
The string `buf` was not freed after each call to `asprintf_safe`.
Avoid allocating and introduce the new message: `XKB_ERROR_INSUFFICIENT_BUFFER_SIZE`.
When there is no error the types are “stolen” and copied to the keymap.
But when there is an error, `MergeIncludedKeyTypes` just return without
“stealing” nor freeing the types.
Fixed by explicitly freeing the key types.
Fixed another leak in `HandleKeyTypeDef` that may occur if there is an
error in parsing a type definition.
GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
src/state.c:589:9: warning: allocation of insufficient size ‘1’ for type ‘struct xkb_state’ with size ‘128’ [-Walloc-size]
```
The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```
So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct xkb_state)`. GCC then sees we're not
doing anything wrong.
Signed-off-by: Sam James <sam@gentoo.org>
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.
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.
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.
The handling of keysym name guards (e.g. `#ifndef XK_Ydiaeresis`) was
incomplete and led to a missing keysym.
Make `sripts/makeheader` more robust to C macros handling.
Peter Hutterer
Pierre Le Marre
Yuichiro Hanada
Brendan Le Foll
ppw0
Sam James
Ran Benita