kc3-lang/libxkbcommon/src/xkbcomp/keymap.c

Branch :

Log

Author Commit Date CI Message
e1892266 2025-02-13 16:57:46 clang-tidy: Miscellaneous fixes
02456c14 2025-02-02 21:51:20 xkbcomp/keymap: avoid some allocations in ApplyInterpsToKey Reuse the darray. memusage ./release/bench-compile-keymap --iter=1000 --layout us,de --variant ,neo Before: Memory usage summary: heap total: 552866360, heap peak: 581022, stack peak: 18848 total calls total memory failed calls realloc| 2035244 211110112 0 (nomove:37629, dec:0, free:0) After: Memory usage summary: heap total: 534063576, heap peak: 581022, stack peak: 18848 total calls total memory failed calls realloc| 1447657 192307328 0 (nomove:37629, dec:0, free:0) Signed-off-by: Ran Benita <ran@unusedvar.com>
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>
c85c9bdc 2025-01-27 17:15:06 symbols: Allow levels with different keysyms and actions counts Contrary to groups, there is no reason for levels to restrict the same count of keysyms and actions.
c7fdf506 2025-01-16 20:23:28 Use portable integer literal suffixes
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
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) ] }; ```
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
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>
917636b1 2018-03-11 17:07:06 xkbcomp: fix crash when parsing an xkb_geometry section xkb_geometry sections are ignored; previously the had done so by returning NULL for the section's XkbFile, however some sections of the code do not expect this. Instead, create an XkbFile for it, it will never be processes and discarded later. Caught with the afl fuzzer. 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>
96a29ede 2014-10-18 19:22:56 xkbcomp/keymap: remove useless free() Signed-off-by: Ran Benita <ran234@gmail.com>
725ae134 2014-09-25 22:01:17 keymap: rename XkbKeyGroupWidth to XkbKeyNumLevels The "width" terminology comes from the group*width+level layout of the keysyms in a key, as used in the old implementations. We don't keep all the keysyms of a key in one array so change it to a more accurate name. Signed-off-by: Ran Benita <ran234@gmail.com>
99184f16 2012-11-24 13:29:54 Make the effective mod mask calculation available to other files We will want to use that function in state.c as well. Signed-off-by: Ran Benita <ran234@gmail.com>
67d884ec 2014-06-01 15:24:10 Remove unnecessary !!(expressions) _Bool already does that. 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>
6b1cdee1 2014-04-22 11:47:23 keymap: add and use xkb_mods_{foreach,enumerate}() To iterate over an xkb_mod_set. Slightly nicer interface and makes transitioning from darray easier. Signed-off-by: Ran Benita <ran234@gmail.com>
0f6bca2b 2014-04-22 11:33:47 keymap: rename xkb_foreach_key to xkb_keys_foreach We'll use the format xkb_foos_foreach and xkb_foos_enumerate for the various iterators. Signed-off-by: Ran Benita <ran234@gmail.com>
ca3170ad 2013-02-08 13:09:33 Add struct xkb_mod_set The only thing that the compilation phase needs the keymap for currently is for access to the modifier information (it also modifies it in place!). We want to only pass along the neccessary information, to make it more tractable and testable, so instead of passing the entire keymap we add a new 'mod_set' object and pass a (const) reference to that. The new object is just the old array of 'struct xkb_mod'. Signed-off-by: Ran Benita <ran234@gmail.com>
769b91c5 2014-02-08 15:30:05 Use (1u << idx) instead of (1 << idx) where appropriate It doesn't matter (I think), since the implicit conversion doesn't have any effect (e.g. sign-extension). But it's better to be aware of the type. Signed-off-by: Ran Benita <ran234@gmail.com>
623b10f8 2014-02-08 00:27:54 Fix sign-compare warnings Signed-off-by: Ran Benita <ran234@gmail.com>
990c09a3 2013-07-28 16:21:40 keymap: update builtin fields directly in src/keymap.c This fields are part of our API and every keymap should have them, not just xkbcomp/ ones. Signed-off-by: Ran Benita <ran234@gmail.com>
9e801ff7 2013-07-21 17:01:20 ctx: adapt to the len-aware atom functions xkb_atom_intern now takes a len parameter. Turns out though that almost all of our xkb_atom_intern calls are called on string literals, the length of which we know statically. So we add a macro to micro-optimize this case. Signed-off-by: Ran Benita <ran234@gmail.com>
9ffe9dae 2013-07-21 09:48:12 keymap: don't use darray for sym_interprets We want xkb_keymap to be easy to handle everywhere. Signed-off-by: Ran Benita <ran234@gmail.com>
094f1dc2 2013-03-30 19:19:01 xkbcomp/keymap: silence a gcc warning src/xkbcomp/keymap.c:127:12: error: 'found' may be used uninitialized in this function [-Werror=maybe-uninitialized] Not really, but why not. Signed-off-by: Ran Benita <ran234@gmail.com>
57bfde3a 2013-03-04 18:41:13 keymap: rename xkb_kt_map_entry to xkb_key_type_entry That's a better name and fits more nicely. Also change type->map to type->entries. Signed-off-by: Ran Benita <ran234@gmail.com>
a7b1f80d 2013-03-02 20:43:57 Build cleanly with clang clang doesn't like the use of typeof with out default flags, so just don't use it. 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>
eb748ab6 2012-10-18 21:04:27 Clean up xkb_sym_interpret a bit First we split the LEVEL_ONE_ONLY bit off of the 'match' field, which allows us to turn enum xkb_match_operation to a simple enum and remove the need for MATCH_OP_MASK. Next we rename 'act' to 'action', because we've settled on that everywhere else. Finally, SIMatchText is changed to not handle illegal values - it shouldn't get any. This removes one usage of the GetBuffer hack. Signed-off-by: Ran Benita <ran234@gmail.com>
b6ddd105 2012-10-11 14:05:49 keymap: rename keymap->sym_interpret -> sym_interprets This can be a bit confusing. 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>
6d74e66e 2012-10-06 17:53:53 Replace 0xff with MOD_REAL_MASK_ALL To make it easier to see where it's used. The name is just to match MOD_REAL. Signed-off-by: Ran Benita <ran234@gmail.com>
39232e6d 2012-10-06 17:21:09 Remove now-unneeded mod type annotations Most of the mod type annotations can now be changed to MOD_BOTH, because if you pass a mask which can only contain real mods in the first place to e.g. ModMaskText, then MOD_REAL and MOD_BOTH will give the same result. In the cases where MOD_BOTH is only ever the argument, we just remove it. What's left is where it really "matters". Signed-off-by: Ran Benita <ran234@gmail.com>
424de613 2012-10-05 22:46:21 Keep real and virtual mods in the same table in the keymap We change the keymap->vmods array into keymap->mods, and change it's member type from struct xkb_vmod to struct xkb_mod. This table now includes the real modifiers in the first 8 places. To distinguish between them, we add an enum mod_type to struct xkb_mod. Besides being a more reasonable approach, this enables us to share some code later, remove XKB_NUM_CORE_MODS (though the 0xff mask still appears in a few places), and prepares us to flat out remove the distinction in the future. This commit just does the conversion. Signed-off-by: Ran Benita <ran234@gmail.com>
1005b320 2012-10-05 22:07:04 Don't use shifted virtual modifier masks Modifier masks can be confusing in some places. For example, key->vmodmap only contains virtual modifiers, where the first is in position 0, the second in 1 etc., while normally in a xkb_mod_mask_t the virtual modifiers start from the 8th (XKB_NUM_CORE_MODS) position. This happens in some other places as well. Change all of the masks to be in the usual real+virtual format, and when we need to access e.g. keymap->vmods we just adjust by XKB_NUM_CORE_MODS. (This also goes for indexes, e.g. interpret->virtual_modifier). This makes this stuff easier to reason about. Signed-off-by: Ran Benita <ran234@gmail.com>
dd29b14e 2012-10-03 12:57:53 Remove the XKB_NUM_VIRTUAL_MODIFIERS limit Turn the virtual modifiers arrays in the keymap to a single darray, which doesn't use this limit. The number of virtual modifiers is still limited by the size of xkb_mod_mask_t, so we make sure not to go over that. Signed-off-by: Ran Benita <ran234@gmail.com>
fe1faa14 2012-10-03 20:08:13 Use our types instead of int/uint32_t in a few places Signed-off-by: Ran Benita <ran234@gmail.com>
53cfe8c3 2012-09-27 09:19:12 xkbcomp/keymap: use default interpret in ApplyInterpsToKey This makes the code easier to follow and does more explicitly what the xkblib spec says: If no matching symbol interpretation is found, the server uses a default interpretation where: sym = 0 flags = XkbSI_AutoRepeat match = XkbSI_AnyOfOrNone mods = 0 virtual_mod = XkbNoModifier act = SA_NoAction If a level doesn't have any keysyms, we don't apply anything to it. Signed-off-by: Ran Benita <ran234@gmail.com>
c955f8e2 2012-09-24 14:41:09 keymap: store a pointer to the type in xkb_group instead of index Gets rid of some more unneeded indirection, including the XkbKeyType macro. Signed-off-by: Ran Benita <ran234@gmail.com>
01b00d75 2012-09-24 12:11:31 keymap, symbols: improve xkb_key memory layout Add struct xkb_group and xkb_level for use in xkb_key, to mirror how it's done in KeyInfo, GroupInfo, LevelInfo in symbols.c. This corresponds more nicely to the logical data layout (i.e. a key has groups which have levels), and also removes a lot of copying and ugly code due to the index indirections and separate arrays which were used before. This uses more memory in some places (e.g. we alloc an action for every level even if the key doesn't have any) but less in other places (e.g. we no longer have to pad each group to ->width levels). The numbers say we use less overall. Signed-off-by: Ran Benita <ran234@gmail.com>
fcd20290 2012-09-21 14:44:17 Don't use xkbcommon-compat names in internal code 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>
9c2a5c6c 2012-09-19 15:23:35 xkbcomp/keymap: correct ACTION_MODS_LOOKUP_MODS handling The xkblib spec says: If XkbSA_UseModMapMods is not set in the flags field, the mask, real_mods, vmods1, and vmods2 fields are used to determine the action modifiers. Otherwise they are ignored and the modifiers bound to the key (client map->modmap[keycode]) are used instead. So we should just assign the modmap without considering what's there. 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>
b4b40d73 2012-09-12 16:54:07 Copyright updates With Dan Nicholson's permission (via email), update his copyright and license statements to the standard X.Org boilerplate MIT license, as both myself and Ran have been using. Clean up my copyright declarations (in some cases to correct ownership), and add copyright/license statements from myself and/or Ran where appropriate. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
e60e9523 2012-09-11 12:35:24 kbproto unentanglement: XkbExplicit*Mask Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2eab7efc 2012-09-11 12:32:18 kbproto unentanglement: XkbSI_AutoRepeat That was the only interp flag, so just turn it into a straight boolean. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
a8d462e3 2012-09-11 12:28:29 kbproto unentanglement: XkbSI match flags Signed-off-by: Daniel Stone <daniel@fooishbar.org>
70c775f6 2012-09-10 20:38:46 kbproto unentanglement: action flags Signed-off-by: Daniel Stone <daniel@fooishbar.org>
0b2506db 2012-09-10 19:23:16 kbproto unentanglement: action types Signed-off-by: Daniel Stone <daniel@fooishbar.org>
b04d896a 2012-08-21 12:48:20 kbproto unentanglement: XkbNumVirtualMods Signed-off-by: Daniel Stone <daniel@fooishbar.org>
74ec4c1c 2012-08-21 12:47:28 kbproto unentanglement: XkbNumIndicators Signed-off-by: Daniel Stone <daniel@fooishbar.org>
314965b1 2012-08-21 14:40:51 Remove deprecated actions We didn't do anything with ISO_Lock, ActionMessage, RedirectKey, and the device-specifying variants of the pointer actions, so remove those. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
41472822 2012-08-29 15:17:00 Use XKB_MOD_INVALID instead of XkbNoModifier Signed-off-by: Ran Benita <ran234@gmail.com>
db639be6 2012-09-03 10:23:44 keymap: optimize FindInterpsForKey a bit Signed-off-by: Ran Benita <ran234@gmail.com>
872e15e5 2012-08-30 00:12:41 keymap: refactor ApplyInterpsToKey There's really not much to explain what the function used to do there... Signed-off-by: Ran Benita <ran234@gmail.com>
8c1b1b0e 2012-08-29 15:02:40 Add xkbcomp/keymap.c and move some code there Add CompileKeymap to do most of what compile_keymap_file does now, and move UpdateKeymapFromModifiers along with it from (mostly unrelated) compat.c. Also rename UpdateKeymapFromModifiers to UpdateDerivedKeymapFields, because it does more than update the modifiers. Signed-off-by: Ran Benita <ran234@gmail.com>
fe4f9909 2012-07-14 00:27:19 Move CompileKeymap into xkbcomp.c It's nicer to see the code where its used. Removes keymap.c. Signed-off-by: Ran Benita <ran234@gmail.com>
8ff98487 2012-07-01 00:45:20 keymap: remove redundant check This is handled above in the LEGAL_FILE_TYPES check. Signed-off-by: Ran Benita <ran234@gmail.com>
48b4d30a 2012-06-29 17:05:33 Use enum for file types enums are nice for some type safety and readability. This one also removes the distinction between file type mask / file type index and some naming consistency. Signed-off-by: Ran Benita <ran234@gmail.com>
7111eb8e 2012-06-29 17:45:47 compat: move some unclear code where it belongs It seems like at some point it was needed to break the abstraction and perform this piece of code in the context above CompileCompatMap. The extra argument and the typedef look strange now, and doesn't seem to be needed any more, so move them back. Signed-off-by: Ran Benita <ran234@gmail.com>
213dcf68 2012-06-29 17:31:10 Use enum for merge mode The merge mode shows up in a lot of functions, so it's useful to give it a distinct type. Signed-off-by: Ran Benita <ran234@gmail.com>
8f257397 2012-06-29 16:04:55 keymap: simplify legal/required logic a bit Now that we've consolidated on the keymap file type, this code only serves to confuse. Signed-off-by: Ran Benita <ran234@gmail.com>
75ff2cef 2012-05-13 18:45:43 Various static analyzer fixes Signed-off-by: Ran Benita <ran234@gmail.com>
7b00485a 2012-05-11 15: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>
5e59ef3f 2012-05-09 17:54:37 Remove support for xkb_layout and xkb_semantics file types These are two aggregate file types which are not used anywhere. We maintain useful-enough backward compatibility in the parser, by treating them as xkb_keymap. The keymap type allows for all types of components, so they will still compile fine if they ever come up. Signed-off-by: Ran Benita <ran234@gmail.com>
e7bb1e5f 2012-05-09 15: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.]
38cb6390 2012-05-09 15: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>
33273304 2012-05-08 13:57:07 Rename xkbcomp/misc.h to xkbcomp-priv.h and use it The include dependencies were quite convoluted, where you change the order and get a ton of errors. Instead, change one file to act as the internal interface for the xkbcomp files, and make every file use it. Also drop the pointless "xkb" prefix to file names. Signed-off-by: Ran Benita <ran234@gmail.com>
62a75dc1 2012-04-10 23:08:49 Remove unused stuff from XKBcommonint.h Signed-off-by: Ran Benita <ran234@gmail.com>
12b3495d 2012-04-11 01:55:50 Remove unused 'which' and 'merge' arguments Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_desc -> xkb_keymap changes.]
a641a185 2012-04-06 03:38:55 Use stdbool.h 'Cause defining your own True and False is so 1990's. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Fixed for xkb_desc -> xkb_keymap changes.]
ef88c7ef 2012-04-03 15: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>
7a7ec9b1 2012-03-31 02:30:33 Avoid leak in CompileKeymap error path The NULL check is unneeded, and prevented the atoms from being free'd. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb_map_unref.]
cc5588c6 2012-03-29 17:39:11 Fail gracefully on failure to find component include If we can't find the component of the include file we're looking for, make sure we don't return success when we meant failure, segfault, or spectacularly leak everything. Tested with incorrect component includes for keycodes, compat, symbols, and types. Signed-off-by: Daniel Stone <daniel@fooishbar.org> Reported-by: David Herrmann <dh.herrmann@googlemail.com>
034ffce6 2012-03-27 17:22:35 Use xkb_contexts in keymap compilation Primarily for the include path, but also for the logging in future. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
d039622a 2012-03-22 17:39:12 Rename keymap allocation API Signed-off-by: Daniel Stone <daniel@fooishbar.org>
bcd811ce 2012-03-20 17:24:09 Small constification Signed-off-by: Daniel Stone <daniel@fooishbar.org>
0e0b5b00 2012-03-14 18:24:37 Update modifiers after building keymap The server used to have to go and do this on our own, but we can do better than that: after we've compiled the keymap, go through and bind virtual modifiers to everything that needs it. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
671ab1bf 2012-03-10 13:54:03 Handle XkbFiles without a name Signed-off-by: Daniel Stone <daniel@fooishbar.org>
c8fd3ea4 2012-03-10 13:48:13 Move allocation of xkb_desc into CompileKeymap Signed-off-by: Daniel Stone <daniel@fooishbar.org>
57b551a4 2012-03-09 18:46:46 Ensure we always have a complete keymap Refuse to compile without keycodes + compat + types + symbols. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
73919568 2012-03-09 16:32:45 Add explicit braces Signed-off-by: Daniel Stone <daniel@fooishbar.org>
4bc451bf 2012-03-09 16:55:37 Convert CompileKeymap to early-return style Signed-off-by: Daniel Stone <daniel@fooishbar.org>
aa41ab29 2012-03-09 16:31:48 xkbcomp: Turn an array into an anonymous struct Signed-off-by: Daniel Stone <daniel@fooishbar.org>
ed5c6c17 2012-03-09 16:26:34 Remove geometry support, again It still parses geometry, but happily throws it away. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
889a299e 2012-03-02 14:49:36 Free XkbFile's when no longer needed Signed-off-by: Ran Benita <ran234@gmail.com>
c7bf3687 2012-03-02 22:36:32 Make the sections array local to the keymap compiling function Signed-off-by: Ran Benita <ran234@gmail.com>
4bc839ab 2012-02-29 20:50:17 Use memset instead of bzero Signed-off-by: Ran Benita <ran234@gmail.com>
f278cea1 2012-02-29 20:25:11 Remove all uses of the register keyword Signed-off-by: Ran Benita <ran234@gmail.com>
a0dd0526 2012-02-25 11:46:12 Remove unused includes of "tokens.h" Signed-off-by: Ran Benita <ran234@gmail.com>
9005624f 2012-02-24 16:00:10 Remove unneeded assignments and variables Signed-off-by: Ran Benita <ran234@gmail.com>
9f602686 2010-07-01 14:35:24 Pull in enough structs and defines from XKBstr.h to only need XKB.h We want to move away from sharing implementation structs and let libX11 and libxkbcommon use each their own set of structs.
6a84a34d 2009-04-08 07:46:25 Remove all non-public API from XKBcommon.h header The noble intention was to expose all the new API and new generic types in the split out kbproto headers through XKBcommon.h. It turns out that would be a massive amount of work in the server. Someday, but first just wedging in XkbCompileKeymap* would be good. Most of the API is in new internal xkb*.h headers. In order to allow the XKBcommon.h header to be used from the server, we can't pull in other headers from kbproto since the server has its own copies. However, types that are different (XkbDescRec, XkbAction) still have Xkbc equivalents here, and I think they should be used in the server.
5c910623 2009-04-04 09:19:51 Remove trailing spaces in source files
a27e56b6 2009-03-31 07:21:20 xkbcomp: Remove duplicated macros
2671b777 2009-03-28 14:06:26 Add more *Text functions from xkbfile This should cover all the usage in xkbcomp. The format arguments were dropped except for the special case of XkbModMaskText, which needs to write in XkbCFile format in HandleVModDef. This was just changed to a Bool to avoid the need for the macros in XKBfile.h. The function prefixes have been renamed to be unique from xkbfile.
d5a9be65 2009-03-27 20:32:33 libxkbcomp: Drop unused format field for *Text functions
dd25bbc9 2009-03-27 19:54:50 libxkbcomp: Eradicate XkbFileInfo usage The only real usage was in the frontend to generate a .xkm file. The rest of the code just operated on the attached XkbDescPtr. Note that here we've replaced the usage of the defined field in CompileKeymap with the equivalent field in a XkbcDescPtr.