kc3-lang/libxkbcommon/src/xkbcomp/keycodes.c
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
324984f1 | 2025-05-17 06:49:49 | xkbcomp: Fix log for unknown default field | |
|
61d8ec67 | 2025-05-12 18:20:47 | misc: Fix string format specifiers Ensure better portability. | |
|
ac2aa2df | 2025-05-12 07:47:03 | keymap: Ensure proper type for LEDs count | |
|
c3953a96 | 2025-05-12 07:37:29 | keymap: Ensure proper type for key codes aliases | |
|
d66a65c2 | 2025-03-20 17:34:07 | xkbcomp: Consistent keycodes logging | |
|
53d80b87 | 2025-03-20 15:29:17 | xkbcomp: Safer keycode max_key_code Since we now always keep the keycodes array at the minimal dimensions, `max_key_code` is redundant and error prone. Let’s use `darray_size` directly. | |
|
06c024e0 | 2025-03-19 13:11:35 | xkbcomp: Fix merge modes Fix various issues with merge mode handling: - Invalid initialization - Invalid merge mode inherited from keymap - Do not leak local merge mode | |
|
5a32b779 | 2025-04-06 06:16:41 | logging: Handle NULL map name Display “(unnamed map)” instead of “(null)”. | |
|
3150bca8 | 2025-03-30 09: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. | |
|
e8561909 | 2025-03-18 14: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. | |
|
f2dd0302 | 2025-02-12 14:15:26 | xkbcomp: Fix LED index int type | |
|
558447d8 | 2025-02-11 17:34:27 | xkbcomp: Explicit vars initialization The `Resolve*` functions do not always initialize the parameters that they can modify, so it is safer to always initialize them at the call site. | |
|
97698fca | 2025-02-11 17:34:23 | xkbcomp: Use explicit int sizes for Expr resolution | |
 |
e120807b | 2025-01-29 15:35:22 | Update license notices to SDPX short identifiers + update LICENSE Fix #628. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
502e9e5b | 2025-01-29 12:19:10 | xkbcomp: Add stricter bounds for keycodes and levels Our current implementation uses continuous arrays indexed by keycodes and levels. This is simple and good enough for realistic keymaps. However, they are allowed to have big values that will lead to either memory exhaustion or a waste of memory (sparse arrays). Added the much stricter upper bounds `0xfff` for keycodes[^1] and 2048 for levels[^2], which should still be plenty enough and provides stronger memory security. [^1]: Current max keycode is 0x2ff in Linux. [^2]: Should be big enough to satisfy automatically generated keymaps. | |
|
fdcd458c | 2024-09-24 21:20:29 | nit: Format files | |
|
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. | |
|
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. | |
|
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 | |
|
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. | |
|
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> | |
|
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> | |
 |
badb428e | 2018-07-23 11:48:35 | keycodes: don't try to copy zero key aliases Move the aliases copy to within the (num_key_aliases > 0) block. Passing info->aliases into this fuction with invalid aliases will cause log messages but num_key_aliases stays on 0. The key_aliases array is never allocated and remains NULL. We then loop through the aliases, causing a null-pointer dereference. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> | |
 |
91620179 | 2014-10-23 21:03:13 | keycodes: use correct printf format Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4a660d7f | 2014-10-18 19:47:19 | xkbcomp: remove file->topName It is useless. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a931740c | 2014-09-10 13: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> | |
|
320e5ffa | 2014-07-25 23:24:46 | keycodes: split CopyKeyInfoToKeymap to several functions It's a bit easier to read and self-documenting. Also handles OOM better. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
67323f41 | 2014-04-25 01:14:31 | keycodes: fix uninitialized variable Happened in one of the previous commits. For some reason, gcc doesn't warn about this, but clang does... Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9014cf8c | 2014-04-22 13:15:21 | keymap, keycodes, compat: don't use darray for LEDs Use a static array of size XKB_MAX_LEDS instead, as in xkb_mod_set. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
caf8f3be | 2014-02-22 23:43:19 | symbols, keycodes: fix int return type when bool is intended Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3923aa71 | 2014-02-09 11:27:34 | doc: move some file comments into txt files in doc/ Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
e731b251 | 2013-08-01 20:24:27 | xkbcomp: handle empty keymaps We should handle empty xkb_keycode and xkb_symbol sections, since xkbcomp handles them, and apparently XQuartz uses it. There are also files for it in xkeyboard-config (rules=base model=empty layout=empty, which translate to keycodes/empty and symbols/empty). https://bugs.freedesktop.org/show_bug.cgi?id=67654 Reported-By: Gatis Paeglis <gatis.paeglis@digia.com> Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4b560287 | 2013-07-18 14:50:21 | xkbcomp: escape the section names before storing them in the keymap This ensures the names are escaped before having any interaction with the user. This was caught by noticing dump(compile(dump())) != dump. Since that's a nice test we add it to stringcomp. https://bugs.freedesktop.org/show_bug.cgi?id=67032 Reported-By: Auke Booij Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a78c1f0a | 2013-03-04 12:53:32 | keycodes: remove file_id The file_id thing is used to identify the XkbFile some statement originally came from. This is needed to avoid spurious warnings; for example, if you write the same alias twice in a file, that's redundant, and you'd want a warning about it. However if intentionally override it from another file, that's fine, and you shouldn't get a warning. So by comparing the file_id's the needed log verbosity is changed. However, the file_id mechanism is really not needed, because we already have that info! Each KeyNamesInfo corresponds to one XkbFile, so if the conflict occurred while handling that one file -> same_file = true, and if it occurs while merging two Info's -> same_file = false. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6a39a065 | 2013-03-04 18:35:56 | Fix pointer style nit (I really dislike this one for some reason..) Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4bd0610f | 2013-03-04 13:21:42 | keycodes: remove KeyNamesInfo::merge Not used. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b06ef2b8 | 2013-03-04 13:06:38 | keycodes: unwrap KeyNameInfo We don't need the struct any more, it only contains one field now. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
f8d3ec9f | 2013-03-04 12:27:06 | keymap: don't use darray for key aliases With a little tweak to the copy-to-keymap routine in keycodes.c we can use a normal array. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ea3cf26d | 2013-03-04 10:33:18 | keycodes: don't do unnecessary copies while merging If 'into' in empty we can just steal 'from'. Also move the alias-merging into the big function, it's nicer this way. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
71eb033e | 2013-03-03 21:35:43 | Move a couple of general keymap functions from keycodes.c To get a key by name and resolve an alias - this makes sense for everyone. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
540feef3 | 2013-03-01 13:51:13 | More spelling errors Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
82c3e393 | 2013-03-03 15:10:45 | keycodes: remove unneeded alias conflict check This is already checked when adding a new alias and merging aliases, so it can never happen when we get to copying to the keymap. Also the log verbosity decision there is quite useless, we should just warn always and be done with it. So we can remove the file_id from AliasInfo, and collapse the alias functions together. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
614f60e3 | 2013-03-03 00:11:27 | xkbcomp: handle XKB file include's better The 'merge_mode' situation is quite messy, and we've introduced a regression compared to original xkbcomp: when handling a composite include statement, such as replace "foo(bar)+baz(bla)|doo:dee" and merging the entire resulting *Info back into the including *Info, we actually use the merge mode that is set by the last part (here it is "augment" because of the '|'), when we should be using the one set for the whole statement (here "replace"). We also take the opportunity to clean up a bit. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a7b9c73d | 2013-02-25 16:08:08 | keycodes: fix spelling in error message Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a46e4cc1 | 2013-02-25 00:19:51 | Fix dead assignments "Value stored to 'stmt' is never read" "Value stored to 'grp_to_use' is never read" And change 'grp' to 'group' if we're here. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a4904ee1 | 2013-02-09 21:46:09 | keycodes: some minor style Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8cee7490 | 2013-02-17 22:18:57 | Change 'indicator' to 'led' everywhere possible The code currently uses the two names interchangeably. Settle on 'led', because it is shorter, more recognizable, and what we use in our API (though of course the parser still uses 'indicator'). In camel case we make it 'Led'. We change 'xkb_indicator_map' to just 'xkb_led' and the variables of this type are 'led'. This mimics 'xkb_key' and 'key'. IndicatorNameInfo and LEDInfo are changed to 'LedNameInfo' and 'LedInfo', and the variables are 'ledi' (like 'keyi' etc.). This is instead of 'ii' and 'im'. This might make a few places a bit confusing, but less than before I think. It's also shorter. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0779d9dc | 2012-10-21 17:13:25 | Silence a couple of warnings These appear to come and go randomly. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
e43f53a6 | 2012-10-11 14:03:03 | compat: add documentation for interpret's Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9197eb0f | 2012-10-10 19:08:01 | Remove the XKB_NUM_INDICATORS limit Use a darray instead of a static array of size 32. We still enforce XKB_MAX_LEDS because of the size of xkb_led_mask_t. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
f3732d83 | 2012-10-10 17:51:06 | keymap: don't use darray for keymap->keys It's never resized. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1dbb2c4a | 2012-10-10 12:11:43 | keycodes: refactor AddIndicatorName Make it shorter and fix the XXX. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a75989b9 | 2012-10-04 12:39:22 | Omit struct '_Name' from non-recursive struct typedefs Just a pet peeve. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
41a7fed3 | 2012-09-27 19:21:26 | Fix type of keycode in parser and ast For some reason keycodes were listed under mapFlags in the yylval union. Fix it and some sanity checks. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3b389b15 | 2012-09-27 18:49:13 | Don't limit key names to 4 characters Currently you can't give a key in xkb_keycodes a name of more than XKB_KEY_NAME_LENGTH (= 4) chars. This is a pretty annoying and arbitrary limitation; it leads to names such as <RTSH>, <COMP>, <PRSC>, <KPAD> etc. which may be hard to decipher, and makes it impossible to give more standard names (e.g. from linux/input.h) to keycodes. The purpose of this, as far as I can tell, was to save memory and to allow encoding a key name directly to a 32 bit value (unsigned long it was). We remove this limitation by just storing the names as atoms; this lifts the limit, allows for easy comparison like the unsigned long thing, and doesn't use more memory than previous solution. It also relieves us from doing all of the annoying conversions to/from long. This has a large diffstat only because KeyNameText, which is used a lot, now needs to take the context in order to resolve the atom. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0dd40125 | 2012-09-22 10:58:00 | API: add _context prefix to log-related functions This is to follow the general scheme set by all of the other API functions. Since no one is using these functions yet, we don't (actually better not) add the old names to xkbcommon-compat.h. Signed-off-by: Ran Benita <ran234@gmail.com> | |
 |
bf194080 | 2012-09-19 16:19:57 | Promote keymap enumeration API to public Rename the functions to get keysyms by key/layout/level to fit with the recent public API renames, and expose them. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
09a4f2ca | 2012-09-15 13:39:14 | keycodes: add KeyNameInfo Instead of keeping the two files and names arrays. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b979a5e9 | 2012-09-15 02:24:17 | keycodes: rename computedMin/Max to min/max_key_code min/max_key_code is more descriptive and matches the names of these field in xkb_keymap. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4b69d6f7 | 2012-09-15 02: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> | |
|
c2570d51 | 2012-09-14 11:17:30 | state, map: constify references to xkb_key Makes it clear that we treat the keys as immutible values in these files. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
96c21e15 | 2012-09-14 00:21:54 | Clean up Init/Clear functions - The Clear* functions should just free the memory associated with the object. If the object is used again, it is Init'd again. - s/Free/Clear if the actual pointer is not free'd. - Zeroise object in Init and only initialize non-zero fields. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
77ab928e | 2012-09-12 21:24:28 | symbols: remove unneeded recursion form CopySymbolsDef This function does some funky stuff, which, as far as I can tell, was needed to support the functionality of giving different keycodes the same name and thus make them duplicates (MERGE_ALT_FORM). This stuff was removed as useless in 0765064b3, but this leftover wasn't noticed. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
74ec4c1c | 2012-08-21 12:47:28 | kbproto unentanglement: XkbNumIndicators Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
f5dffd2b | 2012-08-21 11:21:19 | kbproto untanglement: XkbKeyNameLength Define it ourselves as XKB_KEY_NAME_LENGTH and use that, instead of the one from XKB.h. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
5f613988 | 2012-09-04 17:20:46 | Fold keymap->indicator_names into keymap->indicators This makes sense, since giving a name to an indicator 'activates' the indicator_map in that index. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7ae0c6ba | 2012-08-31 19:26:51 | Convert rest of names in xkb_keymap back to atoms These were kept as atoms, but since the keymap was exposed in the API, we converted them to strings; no the keymap is no longer exposed, so we can go back to atoms. They make the keymap smaller (at least on 64-bit machines) and the comparisons faster. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1a996883 | 2012-08-31 19:05:49 | expr: make ResolveString return an atom Almost all callers do xkb_atom_intern on the currently returned string, while ResolveString converts the atom to the string to begin with... uselss double work. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8d7d9792 | 2012-08-28 00:42:59 | log: replace "priority" by "level" everywhere Now that we don't use syslog, "level" does sound more commonplace. We should change it while there is still nobody using it. Also leave some space between the integers of the xkb_log_level enum values, if we ever need to shove more in between. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
be78b826 | 2012-08-31 11:13:24 | keycodes: ignore "virtual" in indicators The distinction between real/virtual indicators is useless for us, we can just ignore it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9ba5ac0e | 2012-08-27 23:05:04 | keycodes: remove outdated comments Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
518aff6d | 2012-08-31 11:40:35 | keycodes: use array for indicator names instead of list Using a simple array here to mirror keymap->indicator_names makes much more sense, and is simpler. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
d3ddcf70 | 2012-08-15 21:45:02 | expr: move op_type/value_type_to_string functions to ast Generally the enum-to-string function should appear where the enum is defined. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
eaa50c45 | 2012-08-15 10:10:44 | xkbcomp: seperate keymap-copying code from Compile functions Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
bebad402 | 2012-08-31 18:15:01 | keycodes: use darray for aliases instead of list Uses slightly more memory, but worth it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8f1ee629 | 2012-08-14 14:42:57 | types: add "Effects on keymap" to overview Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
cdc228ea | 2012-08-13 11:00:43 | Organize xkbcomp/ header files Various non-functional changes: - Re-add keycodes.h and move some stuff there. - Add parser-priv.h for internal bison/flex stuff. - Don't include headers from other headers, such that file dependencies are immediate in each file. - Rename xkbcomp.h -> ast.h, parseutils.{c,h} -> ast-build.{c,h} - Rename path.{c,h} -> include.{c,h} - Rename keytypes.c -> types.c - Make the naming of XkbFile-related functions more consistent. - Move xkb_map_{new,ref,unref} to map.c. - Remove most extern keyword from function declarations, it's just noise (XKB_EXPORT is what's important here). - Append XKBCOMP_ to include guards. - Shuffle some code around to make all of this work. Splitting this would be a headache.. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7bcc5fab | 2012-08-10 13:32:58 | keycodes: save context in Info, not keymap We don't need the keymap in this case, just makes things more verbose. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0cc5ae33 | 2012-08-10 13:30:44 | Remove xkbcomp/misc.c The KeyName functions are more appropriate in keycodes.c. The ProcessIncludeFile can go to path.c along with the other functions dealing with includes. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
34e690ce | 2012-08-10 13:08:03 | Remove AutoKeyNames feature If this keymap flag is set, whenever a key name appears in one of the sections which does not exist (i.e. has not been declared in keycodes), it finds the first unused keycode and attaches it that name. This might have been useful when you could compile the symbols section or geometry section without a keycodes section, but we don't support this anymore. It's also pretty useless for any real work, because the user has no way of knowing the keycode and so it will never be used. Finally the only obscure way left to set this flag is by including a keycodes file called "computed". Just remove it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3bea189b | 2012-08-01 18:46:01 | Make top level Handle*File functions nicer Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b2c4331a | 2012-07-28 22:15:59 | Handle key names consistently We treat the key names as fixed length, non NUL terminated strings of length XkbKeyNameLength, and use the appropriate *Text functions to print them. We also use strncpy everywhere instead of memcpy to copy the names, because it does some NUL padding and we might as well. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c548c815 | 2012-07-28 12:10:44 | keycodes: add a general overview Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7c89f34e | 2012-07-29 11:39:44 | keycodes: small changes to make it a bit nicer. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
82ee45b3 | 2012-07-28 23:21:46 | Use xkb_led_index_t throughout And use XKB_LED_INVALID instead of _LED_Unbound, which served the same purpose here. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
27f94929 | 2012-07-23 15:46:50 | expr: drop ExprResult from ResolveString Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
000528dd | 2012-07-24 00:23:34 | expr: drop ExprResult from ResolveKeyCode Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
025ca579 | 2012-07-23 12:20:05 | expr: drop ExprResult from ResolveLhs Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
724f62c8 | 2012-07-25 17:29:08 | Convert defines to enums in xkbcomp.h For statement / expression types. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
89723b7c | 2012-07-24 19:54:14 | utils: add/replace string equality macros It's more tidy and less error prone, since we use strcasecmp == 0 a lot. We replace strcmp == 0 by streq, strcasecmp == 0 by istreq, uStrCasePrefix by istreq_prefix and uDupString by strdup_safe. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4f843c81 | 2012-07-24 13:24:59 | Drop Xkbc prefix of text functions Not really needed and inconsistent. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
112cccb1 | 2012-07-23 16:03:34 | Some atom related optimizations We often get a strdup'd string, just to pass it over the atom_intern and then immediately free it. But atom_intern then strdup's it again (if it's not interned already); so instead we can have the interning "steal" the memory instead of allocing a new one and freeing the old one. This is done by a new xkb_atom_steal function. It also turns out, that every time we strdup an atom, we don't actually modify it afterwards. Since we are guaranteed that the atom table will live as long as the context, we can just use xkb_atom_text instead. This removes a some more dynamic allocations. For this change we had to remove the ability to append two strings, e.g. "foo" + "bar" -> "foobar" which is only possible with string literals. This is unused and quite useless for our purposes. xkb_atom_strdup is left unused, as it may still be useful. Running rulescomp in valgrind, Before: ==7907== total heap usage: 173,698 allocs, 173,698 frees, 9,775,973 bytes allocated After: ==6348== total heap usage: 168,403 allocs, 168,403 frees, 9,732,648 bytes allocated Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3c580721 | 2012-07-23 16:22:20 | keycodes: fix valgrind warnings ==7071== Conditional jump or move depends on uninitialised value(s) ==7071== at 0x40B6CB: AddIndicatorName (keycodes.c:148) ==7071== by 0x40C34F: MergeIncludedKeycodes (keycodes.c:420) ==7071== by 0x40C613: HandleIncludeKeycodes (keycodes.c:480) ==7071== by 0x40D022: HandleKeycodesFile (keycodes.c:733) ==7071== by 0x40D79F: CompileKeycodes (keycodes.c:881) ==7071== by 0x401E22: compile_keymap (xkbcomp.c:157) ==7071== by 0x402091: xkb_map_new_from_kccgst (xkbcomp.c:229) ==7071== by 0x40216A: xkb_map_new_from_names (xkbcomp.c:254) ==7071== by 0x4046F5: test_compile_rules (common.c:164) ==7071== by 0x4015C1: test_rmlvo (rulescomp.c:44) ==7071== by 0x40180D: main (rulescomp.c:98) Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
70e3e7e5 | 2012-07-21 15:39:18 | xkbcomp: use new log functions Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0ae1199a | 2012-07-20 19:38:36 | keycodes: use new log functions Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
37579ce9 | 2012-07-20 18:27:37 | keycodes: add keymap to KeyNamesInfo and let the info always be the first argument to the various functions, just for consistency (and it acting as the contex for this file). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
85826c3c | 2012-07-18 17:53:27 | Simplify HandleInclude functions Instead of special casing the first include, process it inside the loop as well. It works perfectly fine. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
861e6a17 | 2012-07-18 16:30:55 | Remove haveSelf include feature When including a file from another file, its possible to do something like this: include "+some(other)+files" with the "+" or "|" in the beginning. What will happen then is that instead of processing the include files separately and then merging into the existing info, we instead start with the existing info and merge into it as we go, as if it was written explicitly before the first "+". It's not particulary clear what this may be useful for. Since it's not used by xkeyboard-config, not documented anywhere (and google doesn't bring up anything), completely untested and kind of ugly, remove this "feature". It most likely never been used. Signed-off-by: Ran Benita <ran234@gmail.com> |