kc3-lang/libxkbcommon/include

include

Branch

Log

Author Commit Date CI Message
Pierre Le Marre 22799562 2025-10-20T13:07:58 compose: No fallback if no missing locale detection Do not use `newlocale()` if it accepts missing locales. It happens with muslc, while glibc works as expected. It fixes the incorrect behavior of the fallback introduced in 135b3204a15838205c97e793cd41faa742d429e2.
Pierre Le Marre 33dc9844 2025-10-17T16:10:28 doc: Advise XKB_CONTEXT_NO_DEFAULT_INCLUDES for clients
Pierre Le Marre 584e0690 2025-10-08T11:55:22 keysyms: Update using latest xorgproto xorgproto commit: 81931cc0fd4761b42603f7da7d4f50fc282cecc6 Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/103
Pierre Le Marre 31900860 2025-09-30T13:05:43 keymap: Make serialization of unused items optional When compiling a keymap from text, some items may be unnecessary in the final keymap, i.e. they do not affect the keymap behavior: - unused key types; - unused keysym interpretations. Deactivate the serialization of these items *by default* and add a new flag to enable it for debugging.
Pierre Le Marre 345f0c67 2025-09-24T20:28:00 keymap: Make pretty-printing optional This greatly improves the keymap serialization: 1.22× speedup and about 5% less allocations. The resulting keymap is also a bit faster to parse. Another improvement is that it eases keysym names migrations (removal and additions) by using only keysym numeric values. This requires some care, i.e. `NoSymbol` must be serialized with its name and not its value 0x0, because xkbcomp and libxkbcommon < 1.12 would interpret the numeric value as `XKB_KEY_0`.
Pierre Le Marre 9131711a 2025-08-21T13:09:04 keymap: Add xkb_keymap_get_as_string2() Enable to configure the keymap serialization.
Pierre Le Marre 44fad8a0 2025-09-14T10:29:41 keysyms: Update to Unicode 17.0 See: https://www.unicode.org/versions/Unicode17.0.0/
Pierre Le Marre 8a5a3393 2025-09-13T17:44:55 keysyms: Minor header fixes
Pierre Le Marre 39481fec 2025-09-02T10:08:49 doc: Improve include paths
Pierre Le Marre 135b3204 2025-08-16T12:59:20 compose: Add fallback for custom locales Before this commit, loading a Compose file based on the locale would fail if the locale is not in the X11 Compose locale registry. While there are workarounds (e.g. `~/.XCompose` file or `$XCOMPOSEFILE`), it does not work if the corresponding file has `include "%L"`. This commit adds the fallback `en_US.UTF-8` in case the locale is installed but not registered in the X11 Compose locale registry. The choice is motivated by the fact that most locales use `en_US.UTF-8` anyway. Ideally we should have a mechanism to extend the Compose locale registry at the *system* level. Mechanisms at the user level (e.g. custom Compose file, environment variable) are deemed sufficient. We could still improve it by first trying to fallback to the locale without the country bits, but there is no function to do such function in the stdlib and we do not want to mess with locales manually. Unfortunately is not possible to test it in our test suite. One can still check it works following these instructions: 1. Create a custom locale, e.g. `en_XX.UTF-8`. `glibc-i18ndata` or similar package may be required to get the required files in `/usr/share/i18n/`. `sudo localedef -i en_US -f UTF-8 en_XX.UTF-8` 2. `xkbcli compile-compose --verbose --locale en_XX.UTF-8`
Pierre Le Marre 9cdf3af0 2025-08-08T19:31:33 doc: Miscellaneous enhancements - Fix minor tag typos - Add more links to the README
Pierre Le Marre eb8697e2 2025-07-23T15:21:39 doc: Clarify keymap format use in protocols
Pierre Le Marre 39726cac 2025-08-06T20:29:26 Add xkb_keymap_mod_get_mask2() Retrospectively, `xkb_keymap_mod_get_mask()` should have used a modifier index rather that a modifier name in its type. Since we already published a version with this API, it’s too late to change that, so instead add a new function `xkb_keymap_mod_get_mask2()`.
Pierre Le Marre 1e0c5790 2025-07-23T12:09:32 keysyms: Fix XF86MediaSelectAuxiliary typo
Pierre Le Marre e9fd95a5 2025-07-23T10:01:45 keysyms: Update using latest xorgproto xorgproto commit: 7fc33fe6d9cf0abc9b62ee976e5cb7ddcd050d1f Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/93
Pierre Le Marre 93818226 2025-07-15T11:34:06 Add xkb_rmlvo_builder_ref()
Pierre Le Marre 1de49d16 2025-06-25T17:04:46 doc: Fix headers markup - Fixed a lot of broken internal links. - Improved the markup of code items. - Fixed a few typos.
Pierre Le Marre 0106b357 2025-06-17T12:06:32 registry: Add rxkb_option_is_layout_specific() Enable to query if an option accepts layout index specifiers to restrict its application to the corresponding layouts.
Pierre Le Marre c4c531da 2025-06-17T11:43:50 rules: Add layout-specific options for RMLVO builder Change the signature of `xkb_rmlvo_builder_append_layout()` to accept an array of options. Also add tests for layout-specific options.
Pierre Le Marre fab9d25b 2025-06-17T11:43:22 rules: Add support for layout-specific options Enabled specifying a layout index for each option, so that it applies only if the layout matches. The layout index is specified by appending immediately after the option name the `!` specifier delimiter and then the layout index, in decimal form and 1-indexed. Note that `!` was chosen instead of the usual `:` specifier delimiter, because some options contains `:`, e.g. `grp:menu_toggle`. `!` *cannot* clash with component names, because `!` is a token in the rules files and thus cannot be used as in component names. It is also vaguely similar to `:`, compared to e.g. `@` or `#`. Example: given the following rules: ! layout[any] option = symbol * opt1 = +s1:%i l2 opt2 = +s2:%i it may result in the following configurations: | Layout | Option | Symbols | | -------- | -------- | ------------ | | `l1` | `opt1` | `+s1:1` | | `l2` | `opt1` | `+s1:1` | | `l1` | `opt2` | `` | | `l2` | `opt2` | `+s2:1` | | `l1,l2` | `opt1` | `+s1:1+s1:2` | | `l1,l2` | `opt1!1` | `+s1:1` | | `l1,l2` | `opt1!2` | `+s1:2` | | `l1,l2` | `opt2` | `+s2:2` | | `l1,l2` | `opt2!1` | `` | | `l1,l2` | `opt2!2` | `+s2:2` |
Pierre Le Marre ef6a550f 2025-06-16T15:48:25 Add xkb_keymap_new_from_rmlvo() Use the new RMLVO builder API to compile keymaps.
Pierre Le Marre da5caabb 2025-06-16T15:45:42 Add RMLVO builder API Before this commit, the API to work with RMLVO was quite minimal: it only uses raw strings from the `xkb_rule_names` struct. However: - it forces the users to deal with error-prone string formatting; - it does not enforce tying together layouts and variants; - it limits adding new features by requiring defining delimiter characters and the corresponding parsing. Added the following API: - `xkb_rmlvo_builder_new()` - `xkb_rmlvo_builder_append_layout()` - `xkb_rmlvo_builder_append_option()` - `xkb_rmlvo_builder_unref()` There is no intermediate `layout` nor `option` object, in order to to keep the API simple. The only foreseen extension is enabling configuring layout-specific options.
Pierre Le Marre 27ba56ae 2025-05-07T10:55:24 doc: Add initial documention for XKB_KEYMAP_FORMAT_TEXT_V2
Pierre Le Marre 44c8deb2 2025-05-07T10:20:25 Introduce keymap format v2 and make it the default for parsing - Added `XKB_KEYMAP_FORMAT_TEXT_V2`. - Made `xkb_keymap_new_from_names()` use the new keymap format. - Made the tools default to the new keymap format for input. This is in preparation for changes in the parsing & state handling. For now it changes nothing.
Pierre Le Marre 58397e94 2025-05-06T18:05:30 Deprecate xkb_keymap_new_from_names() - Deprecate `xkb_keymap_new_from_names()` in favor of `xkb_keymap_new_from_names2()` - Add new changelog fragment type `deprecated`. - Change documentation to use the new function.
Pierre Le Marre 1a10f858 2025-05-06T18:05:06 Add xkb_keymap_new_from_names2 This is just `xkb_keymap_new_from_names()` with an explicit keymap format.
Jules Bertholet 7a2aa9c9 2024-12-20T22:53:11 Always retain later Compose sequence in case of conflict This ensures that it is always possible to override previous definitions, for example when `include`ing the system Compose file. Signed-off-by: Jules Bertholet <julesbertholet@quoi.xyz>
Pierre Le Marre 551cca2a 2024-12-03T10:12:03 state: Add server API for updating latched and locked mods & layout Up to now, the “server state” `xkb_state` API only offered one entry point to update the server state – `xkb_state_update_key`, which reflects the direct keyboard keys state. But some updates come out-of-band from keyboard input events stream, for example, a GUI layout switcher. The X11 XKB protocol has a request which allows for such updates, `XkbLatchLockState`[^1], but xkbcommon does not have similar functionality. So server applications ended up using `xkb_state_update_state` for this, but that’s a function intended for client applications, not servers. Add support for updating the latched & locked state of the mods and layout. Note that the depressed states cannot be updated in this way -- XKB does not expect them to be updated out of band. [^1]: https://www.x.org/releases/X11R7.7/doc/kbproto/xkbproto.html#Querying_and_Changing_Keyboard_State Fixes: #310 Signed-off-by: Ran Benita <ran@unusedvar.com> Co-authored-by: Ran Benita <ran@unusedvar.com> Co-authored-by: Pierre Le Marre <dev@wismill.eu>
Pierre Le Marre 7cd1180b 2025-05-06T11:07:47 modifiers: Add xkb_keymap_mod_get_mask() Added a dedicated API to query modifier masks rather than relying on a hack using `xkb_state_update_mask` and `xkb_state_serialize_mods`. Furthermore, this hack may not work in the future if we remove virtual mods resolution in `xkb_state_update_mask` to avoid corner-cases issues.
Pierre Le Marre 9fab3948 2025-05-09T00:05:31 doc: Deprecate legacy modifiers names The following modifiers names in `xkbcommon/xkbcommon-names.h` are now deprecated: - `XKB_MOD_NAME_ALT`: use `XKB_VMOD_NAME_ALT` instead. - `XKB_MOD_NAME_LOGO`: use `XKB_VMOD_NAME_SUPER` instead. - `XKB_MOD_NAME_NUM`: use `XKB_VMOD_NAME_NUM` instead.
Pierre Le Marre 51c8c5b5 2025-05-09T00:04:42 doc: Common modifiers & LEDs names
Pierre Le Marre 9ffe3cfc 2025-04-29T12:48:10 doc: Create a FAQ page - Initialize with multiple recurrent questions. - Document how to get the vmod → rmod mapping. Rational: Some applications may need it to interface with legacy code.
Pierre Le Marre 9ede705b 2025-04-13T09:50:18 state: Capitalization transformation in xkb_state_key_get_syms Previously `xkb_state_key_get_syms()` did not perform capitalization tranformation, while `xkb_state_key_get_one_sym()` does perform it. This is unfortunate if we want to promote the use of multiple keysyms per levels. The API make it difficult to change now though: we return a pointer to an immutable array rather than filling a buffer. While we could use an internal buffer in `xkb_state`, this option would limit the API to *sequential* calls of `xkb_state_key_get_syms()` or require some buffer handling (e.g. rotation). Instead we now store the capitalization directly in `xkb_level`. We modified `xkb_level` like so (see below for discussion about the size): ```diff struct xkb_level { - unsigned int num_syms; + uint16_t num_syms; - unsigned int num_actions; + uint16_t num_actions; + union { + /** num_syms == 1: Upper keysym */ + xkb_keysym_t upper; + /** num_syms > 1: Indicate if `syms` contains the upper case + * keysyms after the lower ones. */ + bool has_upper; + }; union { xkb_keysym_t sym; /* num_syms == 1 */ xkb_keysym_t *syms; /* num_syms > 1 */ } s; union { union xkb_action action; /* num_actions == 1 */ union xkb_action *actions; /* num_actions > 1 */ } a; }; ``` - When `level.num_syms` <= 1, we store the upper keysym in `level.upper`. - Else if there no cased syms, we set `level.has_upper` to false. - Else if there are some cased syms, we set `level.has_upper`` to `true` and we double the original size of `level.s.syms`, but *without* modifying `level.num_syms`. We then append the transformed keysyms right after the original ones, so that we can access them by a simple pointer operation: `level.s.syms + level.num_syms`. The memory footprint is *unchanged*, thanks to the reduced fields for actions and keysyms counts.
Pierre Le Marre 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
Pierre Le Marre 8e92f25e 2025-03-13T21:26:59 rules: Added xkb_components_names_from_rules() This is mainly for debugging purposes and to enable displaying KcCGST values from RMLVO resolution in `xkbcli compile-keymap --kccgst`.
Pierre Le Marre f3a4eeaa 2025-03-26T16:04:39 symbols: Improve keysym parsing
Ran Benita 2fb1b2e1 2025-01-25T06:18:59 Make XKB_EXPORT do dllexport on Windows Without this, the test-internal libraries (which don't use the .def file because they contain additional private symbols) can't be made shared. But it also makes sense for consistency with GCC. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita a380ba52 2025-01-25T07:00:43 Move XKB_EXPORT to headers The Windows dllexport annotation wants to be on the declarations, not the definitions. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita e120807b 2025-01-29T15:35:22 Update license notices to SDPX short identifiers + update LICENSE Fix #628. Signed-off-by: Ran Benita <ran@unusedvar.com>
Pierre Le Marre 0c940827 2025-01-22T16:39:35 clang-tidy: Macro arguments should be enclosed in parentheses
Pierre Le Marre b9b4ab47 2024-12-09T09:21:01 keysyms: Add sharp S upper case mapping exception The case mapping `ssharp` ß ↔ `U1E9E` ẞ was added in 13b30f4f0dccc08dfea426d73570b913596ed602 but was broken: - For the lower case mapping it returned the keysym `0x10000df`, which is an invalid Unicode keysym. - For the upper case mapping it returned the upper Unicode code point rather than the corresponding keysym. It did accidentally enable the detection of alphabetic key type for the pair (ß, ẞ) though. However this detection was accidentally removed in 5c7c79970a2800b6248e829464676e1f09c5f43d (v1.7) with an attempt to fix the wrong keysym case mapping. Finally both the *lower* case mapping and the key type detection were fixed for good when we implemented the complete Unicode simple case mappings and corresponding tests in e83d08ddbc9851944c662c18e86d4eb0eff23e68. However, the *upper* case mapping `ssharp` → `U1E9E` remained disabled. Indeed, ẞ is a relatively recent addition to Unicode (2008) and had no official recommendation, until recently. So while the lower mapping ẞ→ß exists in Unicode, its converse upper mapping does not. Yet since 2017 the Council for German Orthography (Rat für deutsche Rechtschreibung) recommends[^1] ẞ as the capitalization of ß. Due to its stability policies, the Unicode Character Database (UCD) that we use to generate our keysym case mappings (via ICU) cannot update the simple case mapping of ß. Discussions are currently ongoing in the Unicode mailing list[^2] and CLDR[^3] about how to deal with the new recommended case mapping. However, the discussions are oriented on text-processing and compatibility mappings, while libxkbcommon is on a rather lower level. It seems that the slow adoption of ẞ is partly due to the difficulty to type it. Since ẞ is used only for ALL CAPS casing, the expectation is to type it using CapsLock. While our detection of alphabetic key types works well[^4] for the pair (ß,ẞ), the *internal capitalization* currently does not work and is fixed by this commit. Added the ß → ẞ upper mapping: - Added an exception in the generation script - Fixed tests - Added documentation of the exceptions in `xkbcommon.h` - Added/updated log entries [^1]: https://www.rechtschreibrat.com/regeln-und-woerterverzeichnis/ [^2]: https://corp.unicode.org/pipermail/unicode/2024-November/011162.html [^3]: https://unicode-org.atlassian.net/browse/CLDR-17624 [^4]: Except libxkbcommon 1.7, see the second paragraph.
Pierre Le Marre e0130e30 2024-11-18T20:08:56 state: Add vmod support for xkb_state_mod_mask_remove_consumed
Pierre Le Marre 5fbc0ec7 2024-10-14T16:05:52 state: Support querying whether virtual mods are consumed Previously it was not possible to query the status of virtual modifiers with the following functions: - `xkb_state_mod_index_is_consumed` - `xkb_state_mod_index_is_consumed2` 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.
Pierre Le Marre 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.
Pierre Le Marre 2ba9daf1 2024-09-23T16:20:37 mods: Add more built-in names Added support for the following virtual modifiers: - `Alt` - `Meta` - `NumLock` - `Super` - `Hyper` - `LevelThree` - `LevelFive` - `ScrollLock`
Pierre Le Marre 086a286a 2024-09-23T16:20:17 mods: Always use constants from xkbcommon-names.h Respect the claim that real modifiers names are built-in: - Add `XKB_MOD_NAME_MOD[1-5]` constants. - Replace modifiers names with their corresponding constants.
Pierre Le Marre 43b26bd7 2024-11-29T08:51:41 keysyms: Update to Unicode 16.0
Pierre Le Marre 1d897502 2024-10-04T08:09:28 keysyms: Update using latest xorgproto xorgproto commit: d7ea44d5f04cc476dee83ef439a847172f7a6bd1 Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/91
Martin Rys 9af1f9f2 2024-09-02T14:18:21 Add XKB_LED_NAME_COMPOSE and XKB_LED_NAME_KANA
Pierre Le Marre e83d08dd 2024-02-23T17:10:15 keysyms: Fast and complete case mappings (Unicode 15.1) The current code to handle keysym case mappings is quite complex and slow. It is also incomplete, as it does not cover recent Unicode database. Finally, it does not handle title case correctly. It would be easier if we were to use only a lookup table, but a trivial implementation would lead to a huge array: the cased characters range from `U+0041` to `U+`1F189, i.e. a span of 127 304 elements. Thus we need some tricks to compress the lookup table. We based our work on the post: https://github.com/apankrat/notes/blob/3c551cb028595fd34046c5761fd12d1692576003/fast-case-conversion/README.md The compression algorithm is roughly: 1. Compute the delta between the characters and their mappings. 2. Split the delta array in chunk of a given size. 3. Rearrange the order of the chunks in order to optimize consecutive chunks overlap. 4. Create a data table with the reordered chunks and an index table that maps the original chunk index to its offset in the data table. The compression algorithm is then applied a second time to the previous index table. The complete algorithm optimizes the two chunk sizes in order to get the lowest total data size. The mappings were generated using CPython 3.12.4, PyICU 2.13, PyYaml 6.0.1 and ICU 75.1. Also: - Added explicit list of named keysyms and their case mappings. - Added benchmark for case mappings. - Rework ICU tests. Note: 13b30f4f0dccc08dfea426d73570b913596ed602 introduced a fix for sharp S `U+00DF`. With the new implementation, the *conversion* functions `xkb_keysym_to_{lower,upper}` leave it *unchanged*, while the *predicate* functions `xkb_keysym_is_{lower,upper_or_title}` produce the expected results: ```c xkb_keysym_to_upper(XKB_KEY_ssharp) == XKB_KEY_ssharp; xkb_keysym_to_lower(XKB_KEY_ssharp) == XKB_KEY_ssharp; xkb_keysym_to_lower(XKB_KEY_Ssharp) == XKB_KEY_ssharp; xkb_keysym_is_lower (XKB_KEY_ssharp) == true; xkb_keysym_is_upper_or_title(XKB_KEY_Ssharp) == true; ```
Pierre Le Marre addf73c5 2024-07-12T09:17:34 keysyms: Require only 5 bytes for UTF-8 encoding Require only 5 bytes for the buffer of `xkb_keysym_to_utf8`, as UTF-8 encodes code points on up to 4 bytes + 1 byte for the NULL-terminating byte. Previous standard [RFC 2279] (1998) required up to 6 bytes per code point, but has been superseded by [RFC 3629] (2003). [RFC 2279]: https://datatracker.ietf.org/doc/html/rfc2279 [RFC 3629]: https://datatracker.ietf.org/doc/html/rfc3629
Pierre Le Marre 53d9881e 2024-03-05T10:28:11 keysyms: Fix inconsistent case-insensitive name lookup `xkb_keysym_from_name` has inconsistent behavior when used with the flag `XKB_KEYSYM_CASE_INSENSITIVE`: ```c xkb_keysym_from_name("a", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_a; xkb_keysym_from_name("A", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_a; xkb_keysym_from_name("dead_a", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_A; xkb_keysym_from_name("dead_A", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_A; xkb_keysym_from_name("dead_o", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_o; xkb_keysym_from_name("dead_O", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_dead_o; xkb_keysym_from_name("KANA_tsu", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_tsu; xkb_keysym_from_name("KANA_TSU", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_tsu; xkb_keysym_from_name("KANA_ya", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_YA; xkb_keysym_from_name("KANA_YA", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_YA; xkb_keysym_from_name("XF86Screensaver", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_XF86ScreenSaver; xkb_keysym_from_name("XF86ScreenSaver", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_XF86ScreenSaver; ``` So currently, if two keysym names differ only by case, then the lower-case *keysym* is returned, not the keysym corresponding to the lower-case keysym *name*. Indeed, `xkb_keysym_from_name` uses `xkb_keysym_is_lower` to test if a keysym is a lower-case keysym. Let’s look at the example for keysyms `a` and `A`: we get the keysym `a` not because its name is lower case, but because `xkb_keysym_is_lower(XKB_KEY_a)` returns true and `xkb_keysym_is_lower(XKB_KEY_A)` returns false. So the results are correct according to the doc: - Katakana is not a bicameral script, so e.g. `kana_ya` is *not* the lower case of `kana_YA`. - As for the `dead_*` keysyms, they are not cased either because they do not correspond to characters. - `XF86ScreenSaver` and `XF86Screensaver` are two different keysyms. But this is also very counter-intuitive: `xkb_keysym_is_lower` is not the right function to use in this case, because one would expect to check only the name, not the corresponding character case: ```c xkb_keysym_from_name("KANA_YA", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_kana_ya; xkb_keysym_from_name("XF86ScreenSaver", XKB_KEYSYM_CASE_INSENSITIVE) == XKB_KEY_XF86Screensaver; ``` Fixed by making the order of the keysyms names consistent in `src/ks_tables.h`: 1. Sort by the casefolded name: e.g. `kana_ya` < `kana_YO`. 2. If same casefolded name, then sort by cased name, i.e for ASCII: upper before lower: e.g `kana_YA` < `kana_ya`. Thus we now have e.g. `kana_YA` < `kana_ya` < `kana_YO` < `kana_yo`. The lookup logic has also been simplified. Added exhaustive test for ambiguous case-insensitive names.
Pierre Le Marre ed2dc978 2024-02-08T07:41:39 keysyms: Update using latest xorgproto This fixes a typo and improves comments. xorgproto commit: cd33097fc779f280925c6d6bbfbd5150f93ca5bc Relevant MR: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/84
Pierre Le Marre 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.
Pierre Le Marre 238d1324 2023-09-29T11:33:28 Keysyms: Fix missing hpYdiaeresis 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.
Pierre Le Marre 49690d93 2023-09-28T07:18:56 Keysyms: Update using latest xorgproto xorgproto commit: 1c8128d72df22843a2022576850bc5ab5e3a46ea.
Ran Benita a1770132 2023-09-25T11:41:48 Compose: add iterator API Allow users to iterate the entries in a compose table. This is useful for other projects which want programmable access to the sequences, without having to write their own parser. - New API: - `xkb_compose_table_entry_sequence`; - `xkb_compose_table_entry_keysym`; - `xkb_compose_table_entry_utf8`; - `xkb_compose_table_iterator_new`; - `xkb_compose_table_iterator_free`; - `xkb_compose_table_iterator_next`. - Add tests in `test/compose.c`. - Add benchmark for compose traversal. - `tools/compose.c`: - Print entries instead of just validating them. - Add `--file` option. - TODO: make this tool part of the xkbcli commands. Co-authored-by: Pierre Le Marre <dev@wismill.eu> Co-authored-by: Ran Benita <ran@unusedvar.com> Signed-off-by: Ran Benita <ran@unusedvar.com>
Pierre Le Marre 8c7076a0 2023-07-04T09:23:23 Improve the documentation of keysyms in xkbcommon.h
Pierre Le Marre e811743f 2023-07-04T09:23:23 Add XKB_KEYSYM_MIN and XKB_KEYSYM_MAX Keysyms are 32-bit integers with the 3 most significant bits always set to zero. See: Appendix A “KEYSYM Encoding” of the X Window System Protocol at https://www.x.org/releases/current/doc/xproto/x11protocol.html#keysym_encoding. Add a new constants XKB_KEYSYM_MIN and XKB_KEYSYM_MAX to make the interval of valid keysyms more obvious in the code.
Wismill 0e9c2ec9 2023-04-30T21:30:36 Improve the doc of the XKB keymap text format, V1 (#321) - Add table of contents - Add terminology section - (WIP) Add Introduction to the format - Improve the keycode section - Improve the interpret section - Add guide to create and use modifiers - (WIP) Add actions documentation - Add cross-references - Add keysyms header to documentation
Ran Benita 003fdee1 2023-04-11T22:49:58 keysyms: add new keysyms XF86EmojiPicker, XF86Dictate Ref: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/914d8f5e0f469cd0416364dd008e9eea752bf703 Ref: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/a839f0c7fc5596d10e786394d3b0953eb8a1731b Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 5ba075ab 2022-12-17T13:51:10 doc: clarify "server state" and "client state" distinction Add a common page for the concept and link to there from the relevant functions. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ronan Pigott b4e81ca1 2022-12-16T01:26:25 context: add XKB_CONTEXT_NO_SECURE_GETENV flag (#312) This flag is useful for clients that may have relatively benign capabilities set, like CAP_SYS_NICE, that also want to use the xkb configuration from the environment and user configs in XDG_CONFIG_HOME. Fixes: https://github.com/xkbcommon/libxkbcommon/issues/308 Fixes: https://github.com/xkbcommon/libxkbcommon/issues/129 Signed-off-by: Ran Benita <ran@unusedvar.com>
Mladen Milinkovic a2507c08 2022-02-24T10:48:50 Improve misleading comments #270
Ran Benita 7062ab97 2021-05-22T19:36:22 xkbcommon: deprecate XK_approxeq and XK_notapproxeq Sync xorg-proto commit https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/commit/25f3278b85ec7d1c78bb150eaea52f9c98294ea4 Fixes: #82 Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita de1b6943 2021-04-27T10:10:26 Move include files to include/ subdirectory This way we don't specify `include_directorories('.')` which brings in more than needed. Signed-off-by: Ran Benita <ran@unusedvar.com>
Ran Benita 5e164ff1 2012-07-23T00:41:27 build: drop the include/ directory The include/ dir is somewhat redundant and makes it just a bit harder to handle the -I directives from out side of automake; without it the default $(top_buildir) just works. Here's also some further justifications I found: http://smcv.pseudorandom.co.uk/2008/09/pc-uninstalled/ Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 9308a460 2012-07-17T10:20:15 Run source tree through uncrustify .uncrustify.cfg committed for future reference also, but had to manually fix up a few things: it really likes justifying struct initialisers. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 1f492901 2012-07-11T18:00:31 Enlarge keysym name buffers and mention in comment The longest keysym is 27 chars long. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 8e2c66e9 2012-06-22T15:27:05 Add xkb_key_repeats Does what it says on the box. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 58b030bb 2012-05-20T20:39:35 Move XKB_KEY_NoSymbol to xkbcommon-keysyms.h This avoids a couple of special cases in the code, and is more consistent. Since anyone who includes xkbcommon.h also gets xkbcommon-keysyms.h, and anyone who include xkbcommon-keysyms.h would want NoSymbol anyway, there's no down side. Signed-off-by: Ran Benita <ran234@gmail.com>
Rob Bradford e0524296 2012-06-08T13:10:28 Add API for getting unicode representation of a keysym This code uses a table and code derived from http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c The added API calls are: xkb_keysym_to_utf32 xkb_keysym_to_utf8 [daniels: Changed API to be more in line with keysym_get_name, added test, changed formatting to 4-space.]
Daniel Stone ebd397e1 2012-05-25T17:05:39 Add xkb_map_get_as_string Returns a newly-allocated string representing the specified keymap. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita b89b8e70 2012-05-13T23:31:59 Change xkb_map_new_from_fd to use FILE* i.e. xkb_map_new_from_file. The reason is that flex only works with FILE's, so we must use fdopen on the file descriptor; but to avoid a memory leak, we must also fclose() it, which, in turn, closes the file descriptor itself. Either way is not acceptable, so we can either: * dup() the fd and use fdopen on that, or * have the user call fdopen on his own, and accept a FILE* instead of an fd. The second one seems better, and is standard C, so why not. We must add stdio.h to xkbcommon.h though, which is regrettable, but not a big deal. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 7b00485a 2012-05-11T15:03:43 Rename 'ctx' back to 'context' in external API Still keep things as 'ctx' internally so we don't have to worry about typing it too often, but rename the user-visible API back as it was kinda ugly. This partially reverts e7bb1e5f. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 471e1122 2012-05-09T20:52:33 Document that xkb_state_get_map doesn't take a ref Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 7a1201bd 2012-05-09T20:51:37 Change xkb_key_get_syms to just return a bare int Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 46441b11 2012-05-09T20:49:04 Move KcCGST API to internal-only And don't export it. We don't need it for X11 support, let alone anything else. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 2761b1a3 2012-05-09T20:20:12 Rename serialise to serialize Yes, British English is correct, but unfortunately we've lost that battle. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 5a3771d1 2012-05-09T20:18:30 Add common LED names to xkbcommon-names.h Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 693d0578 2012-05-09T20:17:13 Include xkbcommon-names.h from xkbcommon.h So clients only have one file to include. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 3e3ddd43 2012-05-09T20:12:18 Remove keycode_range_is_legal It was a pretty pointless check. Also sanitise the _x11 variant to actually do what it says on the box. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 6433d72e 2012-05-09T20:12:12 Merge remote-tracking branch 'krh/keysyms' Conflicts: src/keysym.c src/misc.c src/text.h src/xkbcomp/expr.c src/xkbcomp/parser.y src/xkbcomp/parseutils.c src/xkbcomp/symbols.c Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Kristian Høgsberg ace1e5df 2012-05-09T09:05:00 Use our own keysyms
Kristian Høgsberg c6897d26 2012-05-09T08:33:04 Add XKB version of X11 keysyms With this we're now completely standalone. add vendor keysyms
Ran Benita e7bb1e5f 2012-05-09T15:03:11 Shorten context to ctx (This breaks the API.) "context" is really annoying to type all the time (and we're going to type it a lot more :). "ctx" is clear, concise and common in many other libraries. Use it! Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Fix for xkb -> keymap change.]
Daniel Stone 38cb6390 2012-05-09T15:15:30 Change all 'xkb' xkb_keymap names to 'keymap' To make it a bit more clear what it actually is. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone e1af48bc 2012-05-09T13:22:34 Rename keysym <-> string API Change them to refer to the string representation of the keysym's name as a name rather than a string, since we want to add API to get the Unicode printable representation as well. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 124e62e4 2012-05-09T01:06:10 Add multiple modifier state matching API Two new calls allow users to test the exact modifier state, including verifying that no other modifiers but the ones you wanted are down. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 74a197d2 2012-05-08T17:59:35 Add pre-defined names database xkbcommon-names.h right now just contains a set of hardcoded modifier strings that are most commonly used for the usual modifiers. Provide definitions of these so people don't have to worry about typoing a string or mixing up Mod1 and Mod4. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 2a0f1780 2012-05-08T17:52:45 Add context flag to inhibit default include paths Which will make the context start with no include paths at all. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone c3584280 2012-05-08T17:51:16 Add flags to context creation None defined as yet, but why not. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone b537b552 2012-05-08T17:48:29 Add flags to keymap compilation entrypoints No use as yet, but might as well ... Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita b41c77f8 2012-05-07T14:54:12 Revert "Unconstify xkb_rules_names" This reverts commit d007cd0a1f3f4b9c927175771ff79aae6fe4ab8b. This is in fact more restrictive, because it breaks the (common) case where the strings are const themselved, e.g. "evdev", "us", etc. As is you must either duplicate the strings or suppress the warnings. If the user needs to retain the non-const strings, he should instead just keep them in some other struct and use xkb_rules_names just as a temporary parameter for xkb_map_new_from_names. Mildly annoying but acceptable.
Ran Benita 1b9635df 2012-04-08T02:08:37 Add xkb_state_get_map() This is very useful because it avoids redundent pointers in structs and/or parameter passing in the application. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 18e6a6a4 2012-04-05T10:47:43 Remove Xfuncproto.h and XKB.h from xkbcommon/xkbcommon.h The kbproto header is already not needed here anymore. Move the _X_EXPORT's to the corresponding function definitions, and use straight extern "C" clauses instead of _XFUNCPROTOBEGIN/END. It also makes more sense to have the EXPORT's in the source files, as it provides some documentation to the reader, whereas in the header it's obvious. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_keymap changes.]
Ran Benita 073a2107 2012-04-08T15:40:12 Constify the syms_out argument to xkb_key_get_syms() The caller should not mess around with these as they come directly from our internal structs. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 467d7bb6 2012-04-05T10:13:24 Implement missing xkb_state_ref and add return value xkb_state_ref was missing. Also modify the _ref functions to return the object instead of being void. This is a useful idiom: struct my_object my_object_new(struct xkb_state *state) { [...] my_object->state = xkb_state_ref(state); [...] } Essentially "taking" a reference, such that you don't forget to increment it and it's one line less (see example in our own code). A case could also be made for _unref to return the object or NULL, but this is quite uncommon. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_keymap changes.]
Ran Benita 2590b5a1 2012-04-08T15:37:36 Fix compiler warnings (They were not reported, see next commit). The reset function declaration didn't match its name in the definition; the _defaults variant matches better with the rest. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated to current master.]
Daniel Stone ef88c7ef 2012-04-03T15:14:16 Rename xkb_desc to xkb_keymap struct xkb_desc was just a hangover from the old XkbDescRec, which isn't a very descriptive name. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
kmx.io     mail     discord kmxgit v0.4.0