src/xkbcomp/keycodes.c


Log

Author Commit Date CI Message
Ran Benita fbd0e643 2019-12-27T21: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>
Ran Benita 40aab05e 2019-12-27T13: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>
Peter Hutterer badb428e 2018-07-23T11: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>
Ran Benita 91620179 2014-10-23T21:03:13 keycodes: use correct printf format Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4a660d7f 2014-10-18T19:47:19 xkbcomp: remove file->topName It is useless. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a931740c 2014-09-10T13: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>
Ran Benita 320e5ffa 2014-07-25T23: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>
Ran Benita 67323f41 2014-04-25T01: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>
Ran Benita 9014cf8c 2014-04-22T13: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>
Ran Benita caf8f3be 2014-02-22T23:43:19 symbols, keycodes: fix int return type when bool is intended Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 3923aa71 2014-02-09T11:27:34 doc: move some file comments into txt files in doc/ Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e731b251 2013-08-01T20: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>
Ran Benita 4b560287 2013-07-18T14: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>
Ran Benita 6a39a065 2013-03-04T18:35:56 Fix pointer style nit (I really dislike this one for some reason..) Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4bd0610f 2013-03-04T13:21:42 keycodes: remove KeyNamesInfo::merge Not used. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b06ef2b8 2013-03-04T13: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>
Ran Benita a78c1f0a 2013-03-04T12: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>
Ran Benita f8d3ec9f 2013-03-04T12: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>
Ran Benita ea3cf26d 2013-03-04T10: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>
Ran Benita 71eb033e 2013-03-03T21: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>
Ran Benita 82c3e393 2013-03-03T15: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>
Ran Benita 614f60e3 2013-03-03T00: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>
Ran Benita 540feef3 2013-03-01T13:51:13 More spelling errors Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a7b9c73d 2013-02-25T16:08:08 keycodes: fix spelling in error message Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a46e4cc1 2013-02-25T00: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>
Ran Benita a4904ee1 2013-02-09T21:46:09 keycodes: some minor style Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 8cee7490 2013-02-17T22: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>
Ran Benita 0779d9dc 2012-10-21T17:13:25 Silence a couple of warnings These appear to come and go randomly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e43f53a6 2012-10-11T14:03:03 compat: add documentation for interpret's Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9197eb0f 2012-10-10T19: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>
Ran Benita f3732d83 2012-10-10T17:51:06 keymap: don't use darray for keymap->keys It's never resized. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 1dbb2c4a 2012-10-10T12:11:43 keycodes: refactor AddIndicatorName Make it shorter and fix the XXX. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a75989b9 2012-10-04T12:39:22 Omit struct '_Name' from non-recursive struct typedefs Just a pet peeve. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 41a7fed3 2012-09-27T19: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>
Ran Benita 3b389b15 2012-09-27T18: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>
Ran Benita 0dd40125 2012-09-22T10: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>
Daniel Stone bf194080 2012-09-19T16: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>
Ran Benita 09a4f2ca 2012-09-15T13:39:14 keycodes: add KeyNameInfo Instead of keeping the two files and names arrays. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b979a5e9 2012-09-15T02: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>
Ran Benita 4b69d6f7 2012-09-15T02: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>
Ran Benita c2570d51 2012-09-14T11: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>
Ran Benita 96c21e15 2012-09-14T00: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>
Ran Benita 77ab928e 2012-09-12T21: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>
Daniel Stone 74ec4c1c 2012-08-21T12:47:28 kbproto unentanglement: XkbNumIndicators Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone f5dffd2b 2012-08-21T11: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>
Ran Benita 5f613988 2012-09-04T17: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>
Ran Benita 7ae0c6ba 2012-08-31T19: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>
Ran Benita 1a996883 2012-08-31T19: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>
Ran Benita 8d7d9792 2012-08-28T00: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>
Ran Benita 9ba5ac0e 2012-08-27T23:05:04 keycodes: remove outdated comments Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 518aff6d 2012-08-31T11: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>
Ran Benita be78b826 2012-08-31T11: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>
Ran Benita d3ddcf70 2012-08-15T21: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>
Ran Benita eaa50c45 2012-08-15T10:10:44 xkbcomp: seperate keymap-copying code from Compile functions Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bebad402 2012-08-31T18: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>
Ran Benita 8f1ee629 2012-08-14T14:42:57 types: add "Effects on keymap" to overview Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita cdc228ea 2012-08-13T11: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>
Ran Benita 0cc5ae33 2012-08-10T13: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>
Ran Benita 34e690ce 2012-08-10T13: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>
Ran Benita 7bcc5fab 2012-08-10T13: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>
Ran Benita 7c89f34e 2012-07-29T11:39:44 keycodes: small changes to make it a bit nicer. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b2c4331a 2012-07-28T22: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>
Ran Benita c548c815 2012-07-28T12:10:44 keycodes: add a general overview Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 3bea189b 2012-08-01T18:46:01 Make top level Handle*File functions nicer Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 82ee45b3 2012-07-28T23: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>
Ran Benita 27f94929 2012-07-23T15:46:50 expr: drop ExprResult from ResolveString Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 000528dd 2012-07-24T00:23:34 expr: drop ExprResult from ResolveKeyCode Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 025ca579 2012-07-23T12:20:05 expr: drop ExprResult from ResolveLhs Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 724f62c8 2012-07-25T17:29:08 Convert defines to enums in xkbcomp.h For statement / expression types. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 89723b7c 2012-07-24T19: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>
Ran Benita 4f843c81 2012-07-24T13:24:59 Drop Xkbc prefix of text functions Not really needed and inconsistent. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 112cccb1 2012-07-23T16: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>
Ran Benita 3c580721 2012-07-23T16: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>
Ran Benita 70e3e7e5 2012-07-21T15:39:18 xkbcomp: use new log functions Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 37579ce9 2012-07-20T18: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>
Ran Benita 0ae1199a 2012-07-20T19:38:36 keycodes: use new log functions Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 85826c3c 2012-07-18T17: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>
Ran Benita 861e6a17 2012-07-18T16: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>
Ran Benita dfa0929c 2012-07-16T22:15:43 Convert macros to inline functions Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4bf987e5 2012-07-16T21:25:00 keycodes: use list instead of CommonInfo in AliasInfo Always pass around the KeyNamesInfo which contains the list head. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita cc8b0682 2012-07-16T17:53:46 Move alias.c functions into keycodes.c They are only used in this file. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 3fbf4ce3 2012-07-16T21:28:25 keycodes: use list instead of CommonInfo in IndicatorNameInfo Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7d9f0313 2012-07-15T13:00:04 Get rid of struct xkb_key_name Just embed it directly. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e8a6a5f0 2012-07-15T10:38:05 Add common xkb_key struct Instead of having a million arrays from the keycode to various key-specific info in the keymap, add a single struct xkb_key to hold all of the data for the key in one object. This way we can pass it around, do some refactoring and make the code simpler. It's also nice to see everything in one place. The keys array is still indexed by keycode, which is suboptimal because there may be a lot of holes (i.e. unused keycodes between min_key_code and max_key_code). By the end of this series it would be abstracted enough to replace it by a hash table or similar if there's ever a need. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 81d029f5 2012-07-15T11:52:54 Replace xkb_keycode_t 'key' variable name by 'kc' We want to reserve the name 'key' for something else. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 1313af8f 2012-07-15T01:31:34 Get rid of xkb_key_names Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 50fef8eb 2012-07-15T00:46:31 Get rid of xkb_indicator Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 9308a460 2012-07-17T10:20:15 Run source tree through uncrustify .uncrustify.cfg committed for future reference also, but had to manually fix up a few things: it really likes justifying struct initialisers. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 6c3e0811 2012-07-14T15:14:44 Convert missed enum merge_mode variables Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 43bf4136 2012-07-14T15:19:12 Fix fileID mess A few problems here: * In e.g. keycodes.c the fileID field of the Info struct was never initialized to the id of the appropriate file, so it was always 0. There's some code which uses it, mostly for warnings. * Some of the fileID fields were unsigned char, which overflows several times, seeing as the ID in some of our tests can get > 1000 (because we reuse the context). * Some sign mismatches. * fileID vs file_id. Hopefully this fixes everything. I doubt this stuff had ever worked as intended, in xkbcomp or otherwise. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 0765064b 2012-07-13T18:34:11 Remove MERGE_ALT_FORM merge mode The mode comes from the "alternate" keyword, which is unused in xkeyboard-config and mostly undocumented. Its purpose is to allow to assign the same key name to multiple key codes, which is not allowed otherwise (and doesn't make much sense). The xkblib specification implies that this was part of the overlay functionality, which we also no longer support. If we do encounter this keyword, we just treat it as MERGE_DEFAULT. The keycodes.c code will detect a collision and will ignore all but the first key code (and the error count is not incremented). Some peripheral code is also removed as a result. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f0599675 2012-07-11T16:16:20 dump: add back kccgst names Readd the component names to the keymap->names struct. This is used when printing the component, e.g. xkb_keymap { xkb_keycodes "evdev+aliases(qwerty)" { instead of xkb_keymap { xkb_keycodes { This makes diffing against xkbcomp $DISPLAY a bit easier and is kind of useful anyway. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 48b4d30a 2012-06-29T17: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>
Ran Benita 213dcf68 2012-06-29T17: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>
Ran Benita f637d35a 2012-06-27T00:22:31 Use void* instead of old style char* in CommonInfo functions Removes some annoying casts. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita cb631c2d 2012-06-08T09:25:38 Unconstify a few string struct fields These were made const when the structs were exposed in the API. Now they are private and we shouldn't mess around with the UNCONSTIFY business. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bc50cdd4 2012-06-05T18:46:24 darray: some changes for convenience - Make darray_free also initialize the array back to an empty state, and stop worrying about it everywhere. - Add darray_mem, to access the underlying memory, which we do manually now using &darray_item(arr, 0). This makes a bit more clear when we actually mean to take the address of a specific item. - Add darray_copy, to make a deep copy of a darray. - Add darray_same, to test whether two darrays have the same underlying memory (e.g. if the struct itself was value copied). This should used where previously two arrays were compared for pointer equality. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone a3ae0e84 2012-05-29T16:12:54 Pass merge down through indicator creation To avoid using potentially undefined memory. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 89c5e886 2012-05-22T15:45:42 keycodes: use darray in KeyNamesInfo Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 374b0c98 2012-05-22T08:39:09 alloc: use darray in xkb_key_names Signed-off-by: Ran Benita <ran234@gmail.com>