kc3-lang/libxkbcommon/src/xkbcomp
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
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> | |
|
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> | |
 |
17a956d8 | 2013-05-09 14:47:09 | Widen keycode range to 8/255 if possible (bug #63390) If the keycode range is smaller than 8 → 255, artifically widen it when dumping the keymap as not to displease X. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
a392d268 | 2012-08-12 11:40:02 | Replace flex scanner with a hand-written one The scanner is very similar in structure to the one in xkbcomp/rules.c. It avoids copying and has nicer error reporting. It uses gperf to generate a hashtable for the keywords, which gives a nice speed boost (compared to the naive strcasecmp method at least). But since there's hardly a reason to regenerate it every time and require people to install gperf, the output (keywords.c) is added here as well. Here are some stats from test/rulescomp: Before: compiled 1000 keymaps in 4.052939625s ==22063== total heap usage: 101,101 allocs, 101,101 frees, 11,840,834 bytes allocated After: compiled 1000 keymaps in 3.519665434s ==26505== total heap usage: 99,945 allocs, 99,945 frees, 7,033,608 bytes allocated Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
e4bceec8 | 2013-03-14 14:33:40 | utils: add {un,}map_file to read an entire file This wraps the current mmap call and adds a fallback implementation for systems which do not have mmap (e.g. mingw). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
99f6e6fc | 2013-03-14 14:31:55 | Add scanner-utils.h for common scanner functions We want to share the same functions for another scanner. Signed-off-by: Ran Benita <ran234@gmail.com> | |
 |
36f55c49 | 2013-03-11 12:53:39 | keymap: add xkb_keymap_new_from_buffer() The current API doesn't allow the caller to create keymaps from mmap()'ed files. The problem is, xkb_keymap_new_from_string() requires a terminating 0 byte. However, there is no way to guarantee that when using mmap() so a user currently has to copy the whole file just to get the terminating zero byte (assuming they cannot use xkb_keymap_new_from_file()). This adds a new entry xkb_keymap_new_from_buffer() which takes a memory location and the buffer size in bytes. Internally, we depend on yy_scan_{string,byte}() helpers. According to flex documentation these already copy the input string because they are wrappers around yy_scan_buffer(). yy_scan_buffer() on the other hand has some insane requirements. The buffer must be writeable and the last two bytes must be ASCII-NUL. But the buffer may contain other 0 bytes just fine. Because we don't want these constraints in our public API, xkb_keymap_new_from_buffer() needs to create a copy of the input memory. But it then calls yy_scan_buffer() directly. Hence, we have the same number of buffer-copies as with *_from_string() but without the terminating 0 requirement. The explicit yy_scan_buffer() call is preferred over yy_scan_byte() so the buffer-copy operation is not hidden somewhere in flex. Maybe some day we no longer depend on flex and can have a zero-copy API. A user could mmap() a file and it would get parsed right from this buffer. But until then, we shouldn't expose this limitation in the API but instead provide an API that some day can work with zero-copy. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> [ran: rebased on top of my branch] Conflicts: Makefile.am src/xkbcomp/xkbcomp.c | |
|
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> | |
|
0513686b | 2013-03-14 12:45:34 | rules: be more paranoid in scanner This can't happen, but better safe than sorry. The optimizations were noticeable but negligible. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0e200bd5 | 2013-03-13 13:55:11 | rules: quiet a gcc warning src/xkbcomp/rules.c:620:36: error: 'idx' may be used uninitialized in this function [-Werror=maybe-uninitialized] Can't happen but no harm done. 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> | |
|
56ba9866 | 2013-03-04 14:16:36 | Remove file_id entirely It is not used anymore. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
64c00262 | 2013-03-04 14:15:32 | symbols: remove file_id See previous commits. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4921eb74 | 2013-03-04 14:11:13 | compat: remove file_id See previous commit. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2b6e576f | 2013-03-04 14:04:49 | types: remove file_id See previous commit. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2ddb9e4f | 2013-03-04 14:00:44 | types: put all copy-to-keymap code in one function 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> | |
|
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> | |
|
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> | |
|
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> | |
|
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> | |
|
14842d6d | 2013-03-01 21:48:02 | keymap: abstract a bit over the keymap format Make it a bit easier to experiment with other formats. Add a struct xkb_keymap_format_operations, which currently contains the keymap compilation and _get_as_string functions. Each format can implement whatever it wants from these. The current public entry points become wrappers which do some error reporting, allocation etc., and calling to the specific format. The wrappers are all moved to src/keymap.c, so there are no XKB_EXPORT's under src/xkbcomp/ anymore. The only format available now is normal text_v1. This is all not very KISS, and adds some indirection, but it is helpful and somewhat cleaner. 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> | |
|
d1f7100b | 2013-02-25 01:12:38 | ast: add error handling to XkbFileFromComponents And try to not repeat ourselves. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b36d5b23 | 2013-02-25 17:00:53 | parser: also skip 'section' ELEMENT It's for geometry only. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
35657c66 | 2013-02-25 16:38:56 | ast-build: remove malloc_or_die This should be fixed properly. 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> | |
|
dd81d5e0 | 2013-02-08 00:07:28 | Change some log functions to take ctx instead of keymap They don't need the keymap, only the context. 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> | |
|
60bb639b | 2013-02-08 14:03:36 | action: s/hndlrType/handler_type Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
fab28da3 | 2013-02-08 16:06:35 | compat: make it clear which 'dflt' is meant Also s/dflt/default. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b5c1b1d2 | 2013-02-07 23:28:18 | symbols: make it clear which 'dflt' is meant A bit easier at a glance. Also, vowels are cool, so just say 'default'. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
fc56b513 | 2013-02-08 00:02:49 | ast: constify argument Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
164cec66 | 2013-02-19 11:10:23 | symbols: fix bad 'merge' assignment Bug introduced in 2a5b0c9dc1ad1488ecc6b139fd70e464eb687da6, was causing some keys to be merged incorrectly. 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> | |
|
bb620df7 | 2012-12-06 15:04:15 | Parser: Initialise geometry elements for VarDecl We were using uninitialised memory whilst parsing geometry, leaving random contents as the return for shape/overlay/etc sections. Somehow this actually worked everywhere but under Java. https://bugs.freedesktop.org/show_bug.cgi?id=57913 Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
998c957a | 2012-10-30 18:21:56 | action: don't allow private actions with a known type Some obscure bug having to do with Private actions; see the comments. This was prompted by: https://bugs.freedesktop.org/show_bug.cgi?id=56491 Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
f76859bc | 2012-10-23 09:58:11 | keymap: use plain array for keymap->group_names Again it is not resized. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6a94b122 | 2012-10-22 20:49:44 | Split the mods, layout, leds parts of xkb_state_components Note first: This commits breaks the ABI somewhat. If an application is run against this commit without recompiling against the updated header, these break: - xkb_state_layout_*_is_active always retuns false. - xkb_state_serialize_mods always returns 0. So it might break layout switching in some applications. However, xkbcommon-compat.h provides the necessary fixes, so recompiling should work (though updating the application is even better). Split the enum to its individual components, which enables us to refer to them individually. We will use that later for reporting which components of the state have changed after update. 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> | |
|
e6946ae2 | 2012-10-18 22:55:17 | Remove a couple more uses of static char buffers Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
714e95e1 | 2012-10-18 22:51:10 | Contextualize GetBuffer() Instead storing the buffer in a non-thread-safe static array, we move it to the context. 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> | |
 |
7b3bd11f | 2012-10-16 16:05:34 | Add xkb_keysym_from_name() flags argument for case-insensitive search This adds a flags argument to xkb_keysym_from_name() so we can perform a case-insensitive search. This should really be supported as many keysyms have really weird capitalization-rules. However, as this may produce conflicts, users must be warned to only use this for fallback paths or error-recovery. This is also the reason why the internal XKB parsers still use the case-sensitive search. This also adds some test-cases so the expected results are really produced. The binary-size does _not_ change with this patch. However, case-sensitive search may be slightly slower with this patch. But this is barely measurable. [ran: use bool instead of int for icase, add a recommendation to the doc, and test a couple "thorny" cases.] Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> | |
|
89523789 | 2012-10-11 21:50:21 | ast: simplify AppendStmt 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> | |
|
e43f53a6 | 2012-10-11 14:03:03 | compat: add documentation for interpret's Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
90b1984c | 2012-10-11 12:07:43 | compat: don't forget to copy XKB_MATCH_NONE interpret's Commit a8d462e3669b1790dfad75836d5ec59e390392ef accidentally removed the OR with XKB_MATCH_NONE. It is in fact unused though. 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> | |
|
bdea377c | 2012-10-10 17:30:15 | Rename XKB_NUM_GROUPS to XKB_MAX_GROUPS This is a more appropriate name now. 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> | |
|
2ac319c5 | 2012-10-08 22:11:18 | compat: fix bad interpret predicate mods "all" calculation Commit 9984d1d03cd78eb636c75cc2bbd2d240dc1dd72f changed the type of interpret->mods to xkb_mod_mask_t, but this bit of code assumes that the type is uint8_t. This code is not usually run (for example by our tests), but when it does keymap-dump would print out all of the modifiers (including the virtual ones) which causes recompilation of the output to fail miserably. https://bugs.freedesktop.org/show_bug.cgi?id=55769 Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
fcceeeaf | 2012-10-06 21:26:01 | symbols: refactor AddModMapEntry It really asks for it. 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> | |
|
a1124b59 | 2012-10-06 17:42:21 | expr: unify the real and virtual modifier functions This again pushes the mod type annotation to the original call site, to make it easier to grep to see where the real/virtual distinction matters. 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> | |
|
e6e3bda3 | 2012-10-06 17:00:26 | expr: share code for modifier functions We can make more use of the functions in text.c now and remove some cruft. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9ebd2f67 | 2012-10-06 14:34:17 | text: explicitly take mod_type in mod functions This essentially "tags" each invocation of the functions with the modifier type of the argument, which allows for easy grepping for them (with the aim being, to remove anything but MOD_BOTH). 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> | |
|
6974e1f9 | 2012-10-05 21:40:49 | expr: don't expose LookupModIndex The Lookup* functions should remain a private implementation detail of the expr.c file. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
aed3140e | 2012-10-05 21:06:34 | Remove VModInfo for now VModInfo currently is only used to track which virtual modifiers were declared in the file which owns the VModInfo. This, in turn, is only used in ResolveVirtualModifier, which in turn is only used to resolve the virtualModifier field in an interpret statement (compat.c). In other words, it is used to ensure that interprets can only use a vmod which was declared in the same map. We remove this now, because it doesn't do much and distracts from other changes; we will later re-add it properly. Specificly, we will make it so that virtual modifiers are not the exception in that they modify the keymap directly, instead of keeping the changes in some *Info struct and commiting them to the keymap at the end of the compilation. (This is bad because if a vmod is added to the keymap, and then the compilation of this specific file fails, the change sticks around nonetheless). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9a2ce2a5 | 2012-10-05 20:17:54 | vmod: don't allow to add a vmod with the name of a real mod Otherwise strange thing might ensue. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1f4009d4 | 2012-10-04 19:44:47 | vmod: remove merge argument from HandleVModDef It's unused and unneeded. 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> | |
|
1401b0fb | 2012-10-04 12:27:06 | expr: don't allow "none" in LookupModIndex LookupModMask handles this before calling LookupModIndex, and the only other user in symbols.c doesn't handle this return value at all. 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> | |
|
1c880887 | 2012-09-30 11:55:11 | Don't scan and parse useless maps One physical xkb file may (and usually does) contain multiple maps. For example, the us symbols file contains a map for every variant. Currently, when we need a map from a file (specific or default), we parse the entire file into a list of XkbFile's, find the map we want and discard the others. This happens for every include statement. This is a lot of unnecessary work; this commit is a first step at making it better. What we do now is make yyparse return one map at a time; if we find what we want, we can stop looking and avoid processing the rest of the file. This moves some logic from include.c to parser.y (i.e. finding the correct map, named or default). It also necessarily removes the CheckDefaultMap check, which warned about a file which contains multiple default maps. We can live without it. Some stats with test/rulecomp (under valgrind and the benchmark): Before: ==2280== total heap usage: 288,665 allocs, 288,665 frees, 13,121,349 bytes allocated compiled 1000 keymaps in 10.849487353s After: ==1070== total heap usage: 100,197 allocs, 100,197 frees, 9,329,900 bytes allocated compiled 1000 keymaps in 5.258960549s Pretty good. Note: we still do some unnecessary work, by parsing and discarding the maps before the one we want. However dealing with this is more complicated (maybe using bison's push-parser and sniffing the token stream). Probably not worth it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
26e685da | 2012-09-30 14:27:37 | scanner: don't strdup the file name We don't modify it and there's no way to modify the original in the scanner_extra life time. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ee4ab30e | 2012-09-28 10:15:27 | scanner: share code in XkbParse{File,String} Some refactoring to prepare for changes in the parse() function. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
471ebad6 | 2012-09-30 14:23:58 | scanner: remove uselss 'last symbol' error message It never shows something useful. Besides, you already get the line number, which is enough. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
22684cd1 | 2012-09-30 10:50:38 | parser: remove XkbCompMapList rule This rule allows you to put several xkb_keymaps in one file. This doesn't make any sense: only the default/first can ever be used, yet the others are fully parsed as well. Different keymaps should just be put in different files. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3b5ada23 | 2012-09-30 10:33:59 | parser: remove XkbConfig rule This rule allows you to write file maps as: xkb_keycodes <BLA> = 5; [...] instead of the usual format which is: xkb_keycodes { <BLA> = 5; [...] }; This is not documented, It is also not used in xkeyboard-config, and I have never run into it otherwise. It also only allows one map per file. It *might* be used in some obscure place, but probably nothing we should care about; the simplified grammar is more useful for us now. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
26cc2f40 | 2012-09-30 14:17:08 | Don't use %z printf format Some libc's don't support it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ed1203df | 2012-09-30 12:42:44 | rules: always initialize idx variable gcc didn't catch this one. 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> | |
|
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> | |
|
29a8b1ce | 2012-09-26 10:28:52 | Fix size_t vs. %d warning Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
cfa6d25c | 2012-09-25 11:49:23 | symbols: get rid of autoType The autoType variable is supposed to tell us whether the type was explicitly specified by the user or was detected automatically according to the keysyms. It then allows us to know whether to prints the type when we dump the keymap to a string or not. Right now it is not always set when we find an automatic type, according to some apparently legacy rules. We change it to simply this: type computed automatically? -> don't print. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
76478418 | 2012-09-25 11:35:59 | symbols: separate type-finding logic from CopySymbolsDef It's easier to follow this in isolation. Besides, previously the error reporting wasn't done very well. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
5d265926 | 2012-09-24 14:57:30 | keymap: remove some more unneeded macros It clearer to just access the needed data directly. 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> | |
|
e44cd2e9 | 2012-09-24 10:55:20 | symbols: move keysyms into LevelInfo Instead of maintaining a syms array in the GroupInfo + sym_index's in the levels. This simplifies the code somewhat. In order not to alloc for every level instead of every group, we only do it if the level has more than one keysym (with a union). Since for now this is a special case, it actually works out better memory-wise. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
eaf95152 | 2012-09-24 10:16:09 | symbols: fix index-out-of-bounds in FindAutomaticType If we enter this branch, we have 3 <= width <= 4, so if the width is 3 than syms[3] is out of bounds. Happily inherited from xkbcomp. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
504853de | 2012-09-24 09:14:35 | symbols: remove unneeded optimization The levels will be resized to the number of levels of the type anyway, so removing useless levels from the end here is unneeded. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a8b6b08a | 2012-09-24 14:36:46 | Add missing declaration for _xkbcommon_parse (aka yyparse) Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
d941bc0c | 2012-09-23 22:12:43 | keymap, symbols: use darray for num_groups Instead of using a static array of size XKB_NUM_GROUPS, because we want to get rid of this limit. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
79bbf6f7 | 2012-09-23 21:15:34 | symbols: avoid possible access-out-of-bound due to explicit_group The code that handles group name statements currently does this: info->group_names[grp - 1 + info->explicit_group] = name; Other than the fact that this addition makes no sense, it actually can reach out of the bounds of the array (which is of size XKB_NUM_GROUPS) in the (non-realistic) case where (grp - 1) is not 0 (i.e. the statement is not name[Group1] = "foo"). We also change explicit_group to be XKB_LAYOUT_INVALID if not set otherwise, instead of initializing it to 0; this is clearer and if someone happens to write 'us:1' for some reason, it will discard the other groups in the file as it should. This entire explicit_group thing was clearly bolted on as an afterthought. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6d97d0ce | 2012-09-23 20:38:25 | symbols: rename SymbolsInfo groupNames to group_names Just to match the matching field in the keymap. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7a90f9e2 | 2012-09-23 20:36:01 | keymap: don't use XKB_NUM_GROUPS for key->kt_index One unneeded XKB_NUM_GROUPS less. Signed-off-by: Ran Benita <ran234@gmail.com> |