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

src/xkbcomp/compat.c

Log

Author Commit Date CI Message
Peter Hutterer fa86433e 2021-03-30T07:56:09 xkbcomp: remove useless assignment ../../../src/xkbcomp/compat.c:693:16: warning: Although the value stored to 'merge' is used in the enclosing expression, the value is never actually read from 'merge' [deadcode.DeadStores] si.merge = merge = (def->merge == MERGE_DEFAULT ? merge : def->merge); Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Ran Benita 3d43f480 2019-11-12T22:31:46 compat: reject interpret modifier predicate with more than one value Given interpret ISO_Level3_Shift+AnyOf(all,extraneous) { ... }; Previously, extraneous (and further) was ignored. Now it's rejected. Signed-off-by: Ran Benita <ran@unusedvar.com>
Daniel Stone 96df3106 2017-06-26T17:12:29 xkbcomp: Don't crash on no-op modmask expressions If we have an expression of the form 'l1' in an interp section, we unconditionally try to dereference its args, even if it has none. Signed-off-by: Daniel Stone <daniels@collabora.com>
Ran Benita c03834a1 2014-10-23T21:00:20 Reduce variable scopes 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 61fed8da 2014-07-26T00:19:34 Replace darray_mem with a new darray_steal That's a more declarative interface. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 67d884ec 2014-06-01T15:24:10 Remove unnecessary !!(expressions) _Bool already does that. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 07fb6a6c 2014-04-22T18:18:13 xkbcomp: don't align enum values Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 28a22ba2 2014-04-22T18:05:24 xkbcomp: use straight assignment instead of CopyModSet 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 787faf36 2014-04-22T12:23:36 keymap: don't use darray in xkb_mod_set Instead just statically allocate the mods array (of size MAX_MOD_SIZE = 32). The limit is not going anywhere, and static allocations are nicer (nicer code, no OOM, etc.). It's also small and dense enough. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita bf2878d2 2013-02-08T15:12:35 compat: use xkb_mod_set instead of entire keymap Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b5655b3d 2013-02-08T14:39:38 vmod: take xkb_mod_set instead of the entire keymap This is the only place where the modifier information is modified. We will make it local to a given XKB file (after which it will be merged into the keymap). Currently it changes the keymap directly, which sidesteps the abstraction and leaves side-effects even if the XkbFile's compilation fails. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 0b7c8d61 2013-02-08T14:32:47 action: take xkb_mod_set instead of the entire keymap A couple of modiifer actions need this information, but not the entire keymap. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9fbcf6bb 2013-02-08T13:56:41 expr: take xkb_mod_set instead of the entire keymap The modifier-resolving functions only need the modifier information. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita edc0aef5 2013-02-08T13:21:27 text: take xkb_mod_set instead of the entire keymap The modifier printing functions only need the modifier information, they don't care about keys or leds, etc. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 659eacc9 2013-02-08T00:22:38 compat: separate ctx Same as was done for types. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 5bd273a7 2012-11-27T10:42:15 vmod: bring back support for direct vmod -> real mod mapping This brings back the functionality that was removed in b9c87eb710ba4a86455601ca8c5a516b25e20366. Though it is not used in xkeyboard-config, from our current perspective it can be quite useful to be able to set the mappings directly, thus sidestepping the ugly and legacy-ridden modifier_map statement. Here's an example of how to get rid of modifier_map statements (though that would break core-X11 applications, since they must have the mappings through keysyms): virtual_modifiers NumLock = Mod2; virtual_modifiers Alt = Mod1; // Would be nice to map these to Alt, but that would be // incompatible with xkbcomp and somewhat complicated virtual_modifiers LAlt = Mod1; virtual_modifiers RAlt = Mod1; virtual_modifiers LevelThree = Mod5; virtual_modifiers RControl = Control; virtual_modifiers LControl = Control; virtual_modifiers Super = Mod4; virtual_modifiers Meta = Mod1; virtual_modifiers Hyper = Mod4; virtual_modifiers AltGr = Mod5; virtual_modifiers LShift = Shift; virtual_modifiers RShift = Shift; Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a7d753e4 2014-02-09T17:17:13 compat: steal interps and leds when merging if possible 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 972395b8 2013-12-01T12:08:47 expr: split expression types and allocate them separately Currently, we have one ExprDef type, which contains a tagged union with the value of all expression types. Turns out, this union is quite wasteful memory-wise. Instead, create separate types for all expressions (e.g ExprBinary, ExprInteger) which embed the common fields (ExprCommon), and malloc them per their size; ExprDef then becomes a union of all these types, but is just used as a generic pointer. [Instead of making ExprDef a union, another option is to use ExprCommon as the generic pointer type and then do up-castings, like we do with ParseCommon. But this makes the code much uglier.] The diff is mostly straightforward mechanical adaptations. It could have been much smaller with the help of C11 anonymous structs (which were previously a gnu extension). This will have saved all of the 'op' -> 'expr->op', etc changes. But if we can be a bit more portable for a little effort, we should. Before (./test/rulescomp, x86 32 bit, -O2): ==12974== total heap usage: 145,217 allocs, 145,217 frees, 10,476,238 bytes allocated After: ==11145== total heap usage: 145,217 allocs, 145,217 frees, 8,270,358 bytes allocated Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita dbd8b1ef 2013-11-30T22:25:39 expr: add 'ident' value to ExprDef union This distinguishes between an identifier expression and a string expression in the union. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9dc5b8cb 2013-11-27T13:49:13 Resolve keysyms early in parser Instead of having the parser passing strings to the AST, and symbols/compat etc. resolving them themselves. This simplifies the code a bit, and makes it possible to print where exactly in the file the bad keysym originates from. The previous lazy approach had an advantage of not needlessly resolving keysyms from unrelated maps. However, I think reporting these errors in *any* map is better, and the parser is also a bit smarter then old xkbcomp and doesn't parse many useless maps. So there's no discernible speed/memory difference with this change. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 869c9b58 2013-08-13T09:57:07 xkbcomp: improve a few log messages Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9ffe9dae 2013-07-21T09: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>
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 4921eb74 2013-03-04T14:11:13 compat: remove file_id See previous commit. 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 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 dd81d5e0 2013-02-08T00: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>
Ran Benita fab28da3 2013-02-08T16:06:35 compat: make it clear which 'dflt' is meant Also s/dflt/default. 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 6a94b122 2012-10-22T20: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>
Ran Benita e6946ae2 2012-10-18T22:55:17 Remove a couple more uses of static char buffers Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 714e95e1 2012-10-18T22: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>
Ran Benita eb748ab6 2012-10-18T21: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>
Ran Benita b6ddd105 2012-10-11T14:05:49 keymap: rename keymap->sym_interpret -> sym_interprets This can be a bit confusing. 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 90b1984c 2012-10-11T12: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>
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 2ac319c5 2012-10-08T22: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>
Ran Benita 6d74e66e 2012-10-06T17: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>
Ran Benita a1124b59 2012-10-06T17: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>
Ran Benita 39232e6d 2012-10-06T17: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>
Ran Benita 9ebd2f67 2012-10-06T14: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>
Ran Benita aed3140e 2012-10-05T21: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>
Ran Benita 1f4009d4 2012-10-04T19:44:47 vmod: remove merge argument from HandleVModDef It's unused and unneeded. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 424de613 2012-10-05T22: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>
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 fe1faa14 2012-10-03T20:08:13 Use our types instead of int/uint32_t in a few places 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>
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>
Daniel Stone b4b40d73 2012-09-12T16: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>
Daniel Stone 2eab7efc 2012-09-11T12: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>
Daniel Stone a8d462e3 2012-09-11T12:28:29 kbproto unentanglement: XkbSI match flags Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 830fe671 2012-09-10T20:07:54 kbproto unentanglement: XkbIM_* Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 0b2506db 2012-09-10T19:23:16 kbproto unentanglement: action types Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 74ec4c1c 2012-08-21T12:47:28 kbproto unentanglement: XkbNumIndicators Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 54d1d5ed 2012-09-04T17:40:09 compat: make LEDInfo a wrapper around xkb_indicator_map instead of duplicating the fields. The same is done in SymInterpInfo which wraps xkb_sym_interpret. Signed-off-by: Ran Benita <ran234@gmail.com>
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 af2a8b3a 2012-09-02T21:45:42 Unify some string tables from xkbcomp, text and keymap-dump We move the LookupEntry struct from expr.h to text.h, along with most of the lookup tables. This makes them available everywhere. Looking up a value in the LookupEntry format is slower than direct index mapping, but it allows multiple names per value (with the canonical one being first) and "all"- and "none"-type masks. These functions are not used anywhere efficiency matters. 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 41472822 2012-08-29T15:17:00 Use XKB_MOD_INVALID instead of XkbNoModifier Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 87bfd973 2012-09-02T11:29:31 action: keep array of default actions, instead of list of changes The implementation of changing the default properties of actions, e.g. a statements such as (from test/data/compat/basic): setMods.clearLocks= True; latchMods.clearLocks= True; latchMods.latchToLock= True; works by keeping a list of ActionInfo's, each containing the neccesary info from each statement, and then when some action comes up (e.g. in an interpret statment) it goes through the list, and applies the relevent ActionInfo's to the newly-constructed xkb_action. Instead of doing this, we add a struct ActionsInfo, which contains an array of xkb_actions, one for each type. When a default changing statement appears, we change the action in the array; when a new action comes up, we just copy from the array. This is simpler to figure out, and pretty straightforward. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita db639be6 2012-09-03T10:23:44 keymap: optimize FindInterpsForKey a bit 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 b3aced7e 2012-08-28T11:14:54 vmod: ClearVModInfo doesn't need the keymap Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 8c1b1b0e 2012-08-29T15: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>
Ran Benita 6738d300 2012-09-02T19:16:34 compat: only compute 'bool report' once Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e5fdbcbb 2012-09-02T11:49:43 compat: disallow changing global defaults from within an interpret It's currently possible to write something like this: interpret Num_Lock+Any { virtualModifier = NumLock; action = LockMods(modifiers=NumLock); !indicator.allowExplicit; }; The final statement has the same effect as writing it in the global file scope, which changes the default indicator (which all subsequent indicators start off as). This very strange and also unused; if someone does it he probably expects it to affect only the local scope, and he might then get unexpected behavior. So don't allow it. Also, HandleInterpVar is clearly a misnomer (as it can also change indicator defaults) so rename it. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c9466b32 2012-08-27T22:06:50 compat: use darray instead of list for interps No need for a list here. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 8c6694fd 2012-09-02T18:51:26 compat: remove "flags" field from xkb_indicator_map We don't set this field any more. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6e676cb7 2012-08-30T18:56:24 compat: ignore "allowExplicit" in indicator statements Using !allowExplicit sets the XkbIM_NoExplicit flag of the indicator, which means that an XKB client cannot change the state of the indicator using e.g. XkbSetNamedIndicator(). We do not support changing the state of an indicator; furthermore doing it is probably only useful in conjunction with led-drives-keyboard behavior, which we also do not support. This is because setting an indicator without led-drives-keyboard would make the indicator and the modifier/group it's bound to to get out of sync. We can re-add this if we need this info. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita d573600d 2012-08-30T16:39:33 compat: ignore "ledDrivesKbd" in indicator statements We don't support it, as mentioned in the README, so we should stop processing it and print a message about it. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 7f75502f 2012-08-27T13:21:03 compat: get rid of BindIndicators Now that 1fba6189e67 removed support for binding indicator maps by index instead of name, we can remove some more magic which happens now: if an indicator map specifies an indicator name which was not previously declared in a 'indicator 5 = "Caps Lock"'-like statement in xkb_keycodes, we can just look at the next free index and assign it. This also allows us to use a darray for the LEDInfo's instead of a list. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 9de067aa 2012-08-27T21:31:18 compat: ignore "group" (compatibility) statements Group compatibility statements are like the following: group 3 = AltGr; This currently results in: keymap->groups[2].mask = <real mod mapped from AltGr vmod> And we don't do any thing with this value later. The reason it exists in XKB is to support non-XKB clients (i.e. XKB support disabled entirely in the server), which do not know the concept of "group", and use some modifier to distinguish between the first and second keyboard layouts (usually with the AltGr key). We don't care about all of that, so we can forget about it. One artifact of this removal is that xkb_map_num_groups no longer works, because it counted through keymap->groups (this wasn't entirely correct BTW). Instead we add a new num_groups member to the keymap, which just hold the maximum among the xkb_key's num_groups. This also means we don't have to compute anything just to get the number of groups. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 02de2a3e 2012-08-27T12:29:57 compat: ignore "index" field in indicator statements The current code allows to set the "index" field in an indicator statment's body. This would bind the indicator to the specified index, instead of by name (which was declared previously in xkb_keycodes). Doing this is a bad idea, for the same reasons as in 3cd9704, and is also happily not used anywhere. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 65c4a717 2012-08-27T11:38:44 compat: remove dead NoAutomatic code The xkblib spec, table 7.1 (indicators), says: XkbIM_NoAutomatic: Xkb does not automatically change the value of the indicator based upon a change in the keyboard state, regardless of the values for the other fields of the indicator map. xkbcomp (the real one) never actually implemented a way for an indicator statement to set this flag, so it's just dead unused code. We definitely don't want to implement it ourselves, so remove any mention of it. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita e9aa84f3 2012-08-14T15:06:11 compat: small changes Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 4fec91cb 2012-08-14T15:05:56 compat: add general overview Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 79a2cc09 2012-08-11T11:54:05 action: convert action field type to enum We can also hide the ActionInfo definition inside action.c. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 16f2de8b 2012-08-14T16:26:30 compat: ignore "locking" field in sym interprets This field is used in conjunction with key behaviors, which we don't support since c1ea23da5. This is also unused in xkeyboard-config. 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 4c34bda1 2012-08-10T22:38:07 action: get rid of xkb_any_action And use union xkb_action instead. We add xkb_private_action, which is the same as xkb_any_action, but only used where the intention is clear. This should take care of whatever sizing changes the action struct might have. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 87dff888 2012-08-10T18:14:35 Store actions inside struct xkb_key Cuts out a lot of useless redirection and space. 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 07b18bde 2012-08-09T02:33:51 Modernize struct xkb_mods Currently xkb_mods has the following members: - uint8_t real_mods - 8 X11 core mods - xkb_mod_mask_t vmods - 16 virtual mods, zero-based index - xkb_mod_mask_t mask - the computed effective *real* modifier mask, basically a cache for the first two which is: real_mods | real mods computed from vmods Our API acts on masks which combine the real_mods and vmods into a single value, which is: 8 first bits real mods | 16 next bits virtual mods (XkbNumModifiers = 8, XkbNumVirtualMods = 16). This is also the format which ResolveVModMask uses (which is where all the modifier masks really "come from", e.g. "Shift+Lock+Level5" -> xkb_mod_mask_t). What the code does now after getting the mask from ResolveVModMask, is to break it into real part and virtual part and store them seperately, and then join them back together when the effective mask is calculated. This is all pretty useless work. We change xkb_mods to the following: - xkb_mod_mask_t mods - usually what ResolveVModMask returns - xkb_mod_mask_t mask - the computed mask cache And try to consistently use the word "mods" for the original, non-effective mods and mask for the effective mods (which can only contain real mods for now, because things break otherwise). The separation is also made clearer. The effective masks are computed by UpdateModifiersFromCompat after all the sections have been compiled; before this the mask field is never touched; after this (i.e. map.c and state.c) the original mods field is never touched. This single execption to this rule is keymap-dump.c: it needs to print out only the original modifiers, not computed ones. This is also the reason why we actually keep two fields instead keeping one and modifying it in place. The next logical step is probably to turn the real mods into vmods themselves, and get rid of the distinction entirely (in a compatible way). Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 41478b43 2012-08-09T01:30:22 types: don't compute effective masks here as well After compiling all of the sections, UpdateModifiersFromCompat does all of the vmod -> real mods translations, including types/kt_entries. keytypes.c also has code that does that, but it's unneeded: - Later sections don't look at their effective masks, so doing it later is fine. - When this code is executed, the vmods -> real mods mapping is empty (that is set up later), so VModsToReal has no effect here. So we can just remove it. However UpdateModifiersFromCompat didn't update the preserve mask, so do that. Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 4bb8b6b1 2012-08-03T05:19:50 Remove unused vmodmask calculation This was basically an open-coded VModsToReal, which we were using in the line immediately below. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita b2fba730 2012-08-07T08:52:23 types: use regular array for map entries This array is only initialized once. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 8ccfee82 2012-08-07T08:38:20 types: use regular array for types The current code doesn't resize it any more. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 6b75dd2d 2012-08-05T19:38:31 Fix virtual modifiers mask extraction The calculations were performed incorrectly in several places, specifically shifting by 16 instead of 8 (= XkbNumModifiers) and masking with 0xff instead of 0xffff. More stuff that probably never worked as intended. This also makes these more grep-able when we remove the vmods/real_mods separation. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita c1ea23da 2012-08-04T10:47:56 symbols: remove support for key behaviors The possible key behaviors are: KB_RadioGroup, KB_Overlay1, KB_Overlay2: already removed support for these. KB_Lock (with or without KB_Permanent): used to ignore key presses or releases to simulate and deal with some legacy keyboard behaviors (like keys that physically lock). Not used at all. We already ignore them while processing key events in state.c, so make it official. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 59d947c9 2012-08-05T19:24:44 Add and use xkb_level_index_t Several types are used over the code for shift levels; better to use just one. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita cead8527 2012-08-01T22:12:13 Replace more defines with enums Mostly the ones used to track the fields of types/keys/leds which were already defined. 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 3bea189b 2012-08-01T18:46:01 Make top level Handle*File functions nicer Signed-off-by: Ran Benita <ran234@gmail.com>
kmx.io     mail     discord kmxgit v0.4.0