kc3-lang/libxkbcommon/src/xkbcomp
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
4ac22263 | 2025-01-16 23:22:40 | keysyms: Check clashes between keysyms names and keywords Due to how our parser is implemented, keysyms names that are also valid keywords require special handling. Added a check for these clashes in the keysym generator. The only current clash, `section`, is already handled. Note that it means that e.g. `section`, `Section` and `sEcTiOn` all parse to the same keysym. This side effect is fine here, because *currently* there is no other keysym that clashes with any possible of the case variation of `section`. But in order to be extra cautious, we now test thoses clashes too. Hopefully we will never have a clash again, but while it is unlikely that we modify the keywords, the keysyms are not a frozen set. | |
|
818b1b6b | 2025-01-22 17:19:41 | symbols: Simplify GetGroupIndex call | |
|
357ab0cb | 2025-01-23 16:42:30 | clang-tidy: Fix missing default case in switch statement | |
|
842497d9 | 2025-01-22 16:46:11 | clang-tidy: Fix implicit or incorrect integer casts | |
|
7c124fd9 | 2025-01-22 17:20:04 | rules: Fix incrementing a variable in a complex condition | |
|
53b3f446 | 2025-01-22 17:43:53 | clang-tidy: Fix headers includes | |
|
0c940827 | 2025-01-22 16:39:35 | clang-tidy: Macro arguments should be enclosed in parentheses | |
|
b1e1aae6 | 2025-01-23 15:20:44 | xkbcomp: Fix memory leak when extra content after keymap It triggers with e.g.: ``` xkb_keymap { xkb_keycodes { }; }; }; // erroneous ``` | |
|
709027ec | 2025-01-23 09:12:15 | symbols: Fix inconsistent error handling Currently the following keymap triggers a critical error (invalid `vmods`) only for the second key statement, while it should handle both equally. ``` xkb_keymap { xkb_keycodes { <> = 9; }; xkb_types { }; xkb_compat { }; xkb_symbols { key <> { vmods = [], repeats = false }; key <> { repeats = false, vmods = [] }; }; }; ``` Fixed by parsing the whole symbols body and failing if any error was found. | |
|
ec2915fe | 2025-01-22 17:18:21 | symbols: Fix a possible null pointer deference Introduce a new Expression type, `EXPR_EMPTY_LIST`, to avoid the ambiguity between action and keysym empty lists. Two alternatives were rejected to keep the semantics clear: - Using `EXPR_KEYSYM_LIST`: because we would end up accepting an empty keysym list while processing actions. - Using NULL: convey no info and is hazardous. | |
|
425dc634 | 2025-01-21 15:40:33 | Fix some implicit integers casts | |
|
9ef45dc5 | 2025-01-21 19:55:47 | Fix incompatible pointer types with enums The enum casts can possibly lead to unaligned access. The warnings trigger in the Windows CI but not on Linux. One may use `-fshort-enums` with gcc in order to trigger the errors. | |
|
b1aecd47 | 2025-01-21 17:51:56 | actions: Fix SwitchScreen screen value range Currently we accept values of -255..255 while parsing the screen value of `SwitchScreen` actions`, but then we silently cast it against `int8_t`, i.e. in range -128..127. We actually do as xkbcomp, but this seems a bug because the target storage is a `char`. Let’s simply raise a parse error if the value does not fit in our type. | |
 |
26069b76 | 2025-01-21 10:48:28 | xkbcomp/parser: silence a set but unused warning ``` libxkbcommon.so.0.7.0.p/parser.c:1632:9: warning: variable '_xkbcommon_nerrs' set but not used [-Wunused-but-set-variable] 1632 | int yynerrs = 0; ``` Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
c0762c49 | 2025-01-20 16:33:50 | keymap: Fix buffer unnecessary written twice When dumping the keymap, we first try to write to the buffer and get the min size requirement. Then we reallocate if necessary. However, we should not write it again if we got enough space previously! | |
|
24fe4bac | 2025-01-20 16:31:44 | Fix undefined behaviours with NULL pointer Issues detected by the sanitizers: - fix indexing NULL pointer - fix zero offset to NULL pointer | |
|
b0d9a790 | 2025-01-15 12:03:10 | vmods: Fix explicit vmods not dumped | |
|
c7fdf506 | 2025-01-16 20:23:28 | Use portable integer literal suffixes | |
|
e3e44998 | 2025-01-16 20:23:47 | Fix missing or incorrect integer literal suffixes The correct suffix is required in order to have the expected value in a portable way. | |
|
dfa286b2 | 2025-01-15 13:56:36 | compat: Fix Interp & LED merge modes | |
|
d43bb955 | 2024-12-19 18:21:01 | symbols: Fix key symbols/actions merge - Fixed field for defined keysyms/actions - Fixed regression introduced by fdf2c525977e7e8af4135d593110f5bc1454abd8 | |
|
bf03b4b5 | 2024-12-19 16:23:05 | symbols: Parse empty key The following syntax does not parse in xkbcommon, but it does in xkbcomp: ``` xkb_symbols "x" { key <AD01> { }; }; ``` While the usefulness of such statement is debatable, the fact that it does parse in xkbcomp and that tools may generate such keymap entry make it relevant to handle. | |
|
60228356 | 2024-10-07 10:42:27 | symbols: Add message ID for incompatible keysyms and actions counts | |
|
fdf2c525 | 2024-10-08 19: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 | |
|
772ac0c4 | 2024-09-23 11:02:35 | keymap: Rename keysyms field in xkb_level The current field `u` (short for “union”) is not very descriptive. Next commit will add multiple actions per level, so let’s rename the keysym field to `s` (short for “symmbols”). | |
|
31c6d866 | 2024-10-08 18:39:00 | symbols: Min. 2 keysyms in level list Do not allow `{ a }` when a single `a` suffices. | |
|
7c4c718b | 2024-09-30 06: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-09 08: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) ] }; ``` | |
|
929a485f | 2024-10-08 12:52:53 | symbols: Fix too liberal parsing of keysyms lists Currently we are too liberal when parsing symbols lists: e.g. `[{a,{b}}]` is parsed as `[{a,b}]` but it should be rejected. | |
|
4ea9d431 | 2023-11-16 17: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-24 15: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. | |
|
076c60df | 2024-09-25 16:21:05 | rules: Ensure same number of layouts and variants | |
|
c67ec170 | 2024-09-25 14:59:23 | include: Use constants for merge mode prefixes This will make their semantics explicit. | |
|
a898bc81 | 2024-09-25 06:47:23 | logging: Added new error messages ID for keymap and rules | |
|
ba896935 | 2024-09-24 21:28:12 | logging: Make scanner_warn use a message ID | |
|
c8bd57dd | 2024-09-24 21:20:41 | logging: Make scanner_err use a message ID | |
|
fdcd458c | 2024-09-24 21:20:29 | nit: Format files | |
|
7697c712 | 2024-09-16 16: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. | |
|
44df6eee | 2024-09-23 07:27:48 | Add new warnings for deprecated keysyms Add 2 new warnings: - Deprecated keysym name (typo, historical alias, etc.); - Deprecated keysym (all names and forms). Guard deprecated keysym tests with verbosity level ≥2, so they are run only when actually needed. | |
|
05ba96db | 2024-08-20 16: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. | |
|
e83d08dd | 2024-02-23 17: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; ``` | |
|
9944be7e | 2024-07-15 15:40:54 | nit: Fix typo | |
 |
d455e805 | 2024-03-24 05:07:18 | rules: fix variant index being ignored for layout index (#475) We accidentally ignored the variant index and used the layout index instead. In realistic rules they are always the same but don't have to be. | |
 |
ba76ec16 | 2024-03-01 15: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-01 15:02:42 | Global default statement: Fix symbols | |
|
13b36a76 | 2024-03-01 15:02:41 | Global default statement: Improve code & error message - Simplify error handling. - Improve error message: add message ID and relevant quotes and try to standardize a bit. - Add proper doc for in the message registry. Note: Instead of testing the value of `expr.op`, we test if the argument `elem` of `ExprResolveLhs` is set: this allows us to catch also the error with `x.y[z]` rather than just `x.y` as previously. | |
|
d21645be | 2024-02-18 13: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 | |
 |
efdb05d1 | 2024-01-27 23: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. | |
|
20329baf | 2023-11-23 09:30:57 | xkbcomp: Use `steal` for better memory handling | |
|
00e3058e | 2023-11-06 21: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. | |
|
171e0170 | 2023-10-25 20:39:39 | Fix memory leak in FindFileInXkbPath The string `buf` was not freed after each call to `asprintf_safe`. Avoid allocating and introduce the new message: `XKB_ERROR_INSUFFICIENT_BUFFER_SIZE`. | |
|
2b714310 | 2023-10-25 20:01:22 | Fix memory leaks in key types compilation 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. | |
|
3aaa4e2a | 2023-10-30 15:51:34 | rules: early detection of invalid encoding | |
|
82e9293e | 2023-10-30 15:28:10 | xkbcomp: early detection of invalid encoding | |
|
9e887180 | 2023-10-29 07: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. | |
|
f937c308 | 2023-10-29 07:31:34 | xkbcomp: 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. | |
|
9d15c6a7 | 2023-09-26 17:05:14 | Show invalid escape sequences It is easier to debug when the message actually displays the offending escape sequence. | |
|
ca7aa69c | 2023-09-26 17: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. | |
|
c0065c95 | 2023-09-21 20:06:27 | Messages: merge macros with and without message code Previously we had two types of macros for logging: with and without message code. They were intended to be merged afterwards. The idea is to use a special code – `XKB_LOG_MESSAGE_NO_ID = 0` – that should *not* be displayed. But we would like to avoid checking this special code at run time. This is achieved using macro tricks; they are detailed in the code (see: `PREPEND_MESSAGE_ID`). Now it is also easier to spot the remaining undocumented log entries: just search `XKB_LOG_MESSAGE_NO_ID`. | |
|
a83d745b | 2023-09-21 20:06:27 | Messages: add new messages to registry This commit is another step to identify and document the maximum number of logging messages. Bulk changes: - Rename `conflicting-key-type` to `conflicting-key-type-merging-groups`. Giving more context in the name allow us to introduce `conflicting-key-type-definitions` later. - Add conflicting-key-type-definitions - Add conflicting-key-type-map-entry - Add undeclared-modifiers-in-key-type Also improve the log messages. - Add conflicting-key-type-preserve-entries - Use XKB_ERROR_UNSUPPORTED_MODIFIER_MASK - Add illegal-key-type-preserve-result - Add conflicting-key-type-level-names - Add duplicate-entry - Add unsupported-symbols-field - Add missing-symbols-group-name-index - Use XKB_ERROR_WRONG_FIELD_TYPE - Add conflicting-key-name - Use XKB_WARNING_UNDEFINED_KEYCODE - Add illegal-keycode-alias - Add unsupported-geometry-section - Add missing-default-section - Add XKB_LOG_MESSAGE_NO_ID - Rename log_vrb_with_code to log_vrb - Use ERROR_WRONG_FIELD_TYPE & ERROR_INVALID_SYNTAX - Add unknown-identifier - Add invalid-expression-type - Add invalid-operation + fixes - Add unknown-operator - Rename ERROR_UNKNOWN_IDENTIFIER to ERROR_INVALID_IDENTIFIER - Add undeclared-virtual-modifier - Add expected-array-entry - Add invalid-include-statement - Add included-file-not-found - Add allocation-error - Add invalid-included-file - Process symbols.c - Add invalid-value - Add invalid-real-modifier - Add unknown-field - Add wrong-scope - Add invalid-modmap-entry - Add wrong-statement-type - Add conflicting-key-symbols-entry - Add invalid-set-default-statement | |
|
eafd3ace | 2023-09-18 18:17:39 | Add a new warning for numeric keysyms Usually it is better to use the corresponding human-friendly keysym names. If there is none, then the keysym is most probably not supported in the ecosystem. The only use case I see is similar to the PUA in Unicode (see: https://en.wikipedia.org/wiki/Private_Use_Areas). I am not aware of examples of this kind of use. | |
|
ef81d04e | 2023-09-18 18:17:34 | Structured log messages with a message registry Currently there is little structure in the log messages, making difficult to use them for the following use cases: - A user looking for help about a log message: the user probably uses a search engine, thus the results will depend on the proper indexing of our documentation and the various forums. It relies only on the wording of the message, which may change with time. - A user wants to filter the logs resulting of the use of one of the components of xkbcommon. A typical example would be testing xkeyboard-config against libxkbcommon. It requires the use of a pattern (simple words detection or regex). The issue is that the pattern may become silently out-of-sync with xkbcommon. A common practice (e.g. in compilers) is to assign unique error codes to reference theses messages, along with an error index for documentation. Thus this commit implements the following features: - Create a message registry (message-registry.yaml) that defines the log messages produced by xkbcommon. This is a simple YAML file that provides, for each message: - A unique numeric code as a short identifier. It is used in the output message and thus can be easily be filtered to spot errors or searched in the internet. It must not change: if the semantics of message changes, it is better to introduce a new message for clarity. - A unique text identifier, meant for two uses: 1. Generate constants dealing with log information in our code base. 2. Generate human-friendly names for the documentation. - A type: currently warning or error. Used to prefix the constants (see hereinabove) and for basic classification in documentation. - A short description, used as concise and mandatory documentation. - An optionnal detailed description. - Optional examples, intended to help the user to fix issues themself. - Version of xkbcommon it was added. For old entries this often unknown, so they will default to 1.0.0. - Version of xkbcommon it was removed (optional) No entry should ever be deleted from this index, even if the message is not used anymore: it ensures we have unique identifiers along the history of xkbcommon, and that users can refer to the documentation even for older versions. - Add the script update-message-registry.py to generate the following files: - messages.h: message code enumeration for the messages currently used in the code base. Currently a private API. - message.registry.md: the error index documentation page. - Modify the logging functions to use structured messages. This is a work in progress. | |
 |
e7f02d32 | 2023-08-05 15:29:36 | parser: change deprecated `%pure-parser` to `%define api.pure` (#370) This is now supported by byacc since version 2.0 20230516 | |
|
7a815ad3 | 2023-07-04 09:23:24 | Fix parsing of numeric keysyms in ExprResolveKeySym `ExprResolveKeySym` in `expr.c` does not parse non-digit numeric keysyms. Fixed by checking upper bound; also add warning messages. | |
|
0da68bc6 | 2023-07-04 09:23:24 | Simplify parsing of numeric keysyms in parser.y In `parser.y`, a numeric keysym is parsed by formatting it in its hexadecimal form then parsed as a keysym name. This is convoluted. Fixed by checking directly the upper bound. | |
|
5b5b67f2 | 2023-05-01 22: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. | |
 |
b4e81ca1 | 2022-12-16 01: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> | |
|
0b3d9092 | 2022-03-14 16:44:13 | scanner: prefix functions with `scanner_` to avoid symbol conflicts Particularly `eof()` in mingw-w64. Fixes: https://github.com/xkbcommon/libxkbcommon/pull/285 Reported-by: Marko Lindqvist Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
09ac27f7 | 2021-05-22 19:51:02 | ignore: remove no longer relevant gitignore files These were relevant for the autoconf build but now we're meson only. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
3a6c3b2c | 2021-03-30 20:34:11 | ast: remove comment re. anonymous struct C11 is not sufficient for this, needs `--ms-extensions` which we don't want to enable. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
 |
fa86433e | 2021-03-30 07:56:09 | xkbcomp: remove useless assignment ../../../src/xkbcomp/compat.c:693:16: warning: Although the value stored to 'merge' is used in the enclosing expression, the value is never actually read from 'merge' [deadcode.DeadStores] si.merge = merge = (def->merge == MERGE_DEFAULT ? merge : def->merge); Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
20f7f80c | 2021-03-29 16:23:28 | xkbcomp: use memcpy over strncpy to avoid analyzer warnings The target buffer is 7 bytes long, null-termination is optional (as the comment already suggests). Coverity is unhappy about this though so let's use memset and memcpy instead. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
95e29079 | 2021-03-18 12:22:34 | xkbcomp: plug a potential memory leak libxkbcommon-1.0.3/src/xkbcomp/ast-build.c:526: leaked_storage: Variable "file" going out of scope leaks the storage it points to. Where we exit the loop early, we don't release the various allocated memory. Make this patch more obvious my moving the declaration for those into the loop as well, this way we know that they aren't used outside the loop anywhere. Found by coverity Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
fbf087ea | 2020-11-23 19: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> | |
|
afdc9cee | 2020-10-19 10: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 ] }; | |
 |
69713ce3 | 2020-09-11 05:06:23 | parser: fix another format string for int64_t (#191) | |
|
d7b39f6f | 2020-07-10 08:50:02 | Add /etc/xkb as extra lookup path for system data files This completes the usual triplet of configuration locations available for most processes: - vendor-provided data files in /usr/share/X11/xkb - system-specific data files in /etc/xkb - user-specific data files in $XDG_CONFIG_HOME/xkb The default lookup order user, system, vendor, just like everything else that uses these conventions. For include directives in rules files, the '%E' resolves to that path. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
05d6efc4 | 2020-07-10 15:16:50 | xkbcomp: allow including kccgst files from other paths Previously, a 'symbols/us' file in path A would shadow the same file in path B. This is suboptimal, we rarely need to hide the system files - we care mostly about *extending* them. By continuing to check other lookup paths, we make it possible for a XDG_CONFIG_HOME/xkb/symbols/us file to have sections including those from /usr/share/X11/xkb/symbols/us. Note that this is not possible for rules files which need to be manually controlled to get the right bits resolved. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
bbc7005b | 2020-07-27 11:55:32 | xkbcomp: simplify the include path handling Streamline the code a bit - instead of handling all the if (!file) conditions handle the case of where we have a file and jump to the end. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
351b4b9c | 2020-07-27 11:48:29 | xkbcomp: move the logging of include paths into a helper function No functional changes, prep work for some other refacturing. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
dcb6c7b8 | 2020-07-10 15:13:38 | xkbcomp: return NULL, not false in place of a FILE* Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
d4b78a5f | 2020-07-10 15:01:31 | xkbcomp: simplify buffer handling in the include handling Don't do the realloc dance, just asprintf to the buffer and move on. The check is likely pointless anyway, if we run out of asprintf size, log_error will probably blow up as well. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
fadfb13c | 2019-12-28 14:19:22 | xkbcomp/rules: support \r\n line endings Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
da4a90c1 | 2019-12-28 13:49:40 | Open files in binary mode This turns off some misfeatures on Windows, and does nothing on POSIX. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
521bb498 | 2019-12-27 22:08:57 | xkbcomp: remove cast which triggers warning on gcc Will need some other way to take care of the warning on MSVC. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
fbd0e643 | 2019-12-27 21:51:34 | xkbcomp: make a couple of casts explicit to mark them as checked This acknowledges some "possible loss of data cast" warnings from MSVC. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
1849158a | 2019-12-27 15:10:10 | xkbcomp/keywords: regenerate with newer gperf Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
823708b7 | 2019-12-27 14:51:31 | parser: fix format string for int64_t Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
40bea8e9 | 2019-12-27 14:52:49 | xkbcomp: fix wrong return type Detected by MSVC: xkbcomp\xkbcomp.c(111): warning C4047: 'return': 'bool' differs in levels of indirection from 'void *' Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
6ca1a0c9 | 2019-12-27 14:17:55 | parser: use int64_t for all numbers Don't use int which can have different size on different machines. Also avoid some warnings from MSVC: xkbcomp/parser.y(760): warning C4244: '=': conversion from 'int64_t' to 'int', possible loss of data xkbcomp/parser.y(761): warning C4244: '=': conversion from 'int64_t' to 'int', possible loss of data xkbcomp/parser.y(767): warning C4244: '=': conversion from 'int64_t' to 'int', possible loss of data Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
40aab05e | 2019-12-27 13:03:20 | build: include config.h manually Previously we included it with an `-include` compiler directive. But that's not portable. And it's better to be explicit anyway. Every .c file should have `include "config.h"` first thing. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
34122f9f | 2019-12-27 12:34:49 | utils: use MIN/MAX instead of min/max min/max symbols conflict on some systems (msvc), so just use the macros. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
ade13130 | 2019-12-27 12:22:37 | xkbcomp: downgrade "Symbol added to modifier map for multiple modifiers" log to a warning This condition happens in xkeyboard-config keymaps and seems hard to fix. Currently it incessantly spams people's logs who have no idea what to do about it. So downgrade to "warning" level, so it doesn't show up by default. When working on keymaps, set `XKB_LOG_LEVEL=debug XKB_LOG_VERBOSITY=10` to see all possible messages. Refs https://github.com/xkbcommon/libxkbcommon/issues/111 Fixes https://github.com/xkbcommon/libxkbcommon/issues/128 Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
00f31e0d | 2019-11-13 11:38:39 | rules: eliminate an extra fopen/fclose cycle FindXkbFileInPath() opens the file so we're guaranteed that the file not only exists, but that we can read it. Changing that would alter behavior so instead let's just pass that file handle along and do the same for include files. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
ca033a29 | 2019-09-03 11: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> | |
|
3c57b328 | 2019-11-12 15:27:22 | rules: move the matcher result handling to the caller This shouldn't be processed in the matcher itself, especially in the glorious future when we can have nested matchers. Only handle this once in the caller to the original parsed file. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
2ec07b62 | 2019-11-12 14:19:55 | rules: put the scanner on the stack This allows nesting the scanner for the future !include directive. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
bb7551a6 | 2019-11-12 15:25:16 | rules: simplify an error path Initialize to NULL so we don't have to care about whether the cleanups can be called or not. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
d9b98856 | 2019-11-12 14:39:47 | rules: rename a variable from 's' to 'str' To avoid name conflicts with a future patch. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
|
2a578a60 | 2019-11-12 14:17:44 | rules: drop the matcher_err() macro and use scanner_err directly No functional changes, this is what the macro expanded to anyway. Prep work for putting the scanner on the stack and removing it from the matcher struct. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> |