src/xkbcomp/vmod.c


Log

Author Commit Date CI Message
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 28a22ba2 2014-04-22T18:05:24 xkbcomp: use straight assignment instead of CopyModSet 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 6b1cdee1 2014-04-22T11:47:23 keymap: add and use xkb_mods_{foreach,enumerate}() To iterate over an xkb_mod_set. Slightly nicer interface and makes transitioning from darray easier. Signed-off-by: Ran Benita <ran234@gmail.com>
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 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 ca3170ad 2013-02-08T13:09:33 Add struct xkb_mod_set The only thing that the compilation phase needs the keymap for currently is for access to the modifier information (it also modifies it in place!). We want to only pass along the neccessary information, to make it more tractable and testable, so instead of passing the entire keymap we add a new 'mod_set' object and pass a (const) reference to that. The new object is just the old array of 'struct xkb_mod'. Signed-off-by: Ran Benita <ran234@gmail.com>
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 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 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 9a2ce2a5 2012-10-05T20: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>
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 dd29b14e 2012-10-03T12: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>
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 fcd20290 2012-09-21T14:44:17 Don't use xkbcommon-compat names in internal code 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 b04d896a 2012-08-21T12:48:20 kbproto unentanglement: XkbNumVirtualMods Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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 3d305bd0 2012-08-30T13:49:23 vmod: remove outdated comments 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 ab1566cd 2012-08-28T11:11:40 vmod: remove useless keymap initialization keymap->vmods is not touched until UpdateModifiersFromCompat, where it initialized and used. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita b9c87eb7 2012-08-14T17:11:16 vmod: remove support for direct vmod -> real mod mapping The current code supports statements such as: virtual_modifiers NumLock = Mod2; This would set the mapping from the NumLock vmod to the Mod2 real mod directly, without going through the virtualModifier field in an interpret statement (in xkb_compat) or vmods field in a key statement (in xkb_symbols). This is undocumented, unused and complicates things, so remove it. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f410622b 2012-08-15T22:07:37 vmod: remove support for resolving integer to virtual modifier This is only relevant to the virtualModifier= statement in interpret statements in xkb_compat. The current code allows to write e.g. virtualModifier = 4 to get the virtual modifier whose index happens to be 4 (possibly declared in other files or sections, i.e. xkb_types). Doing this is undeterministic, will break without notice, and not used anywhere. Don't allow it. 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 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 b0b11c4e 2012-08-02T00:29:07 types: don't use canonical/required types Xkb required every keymap to have at least the four following canonical types: ONE_LEVEL, TWO_LEVEL, ALPHABETIC, KEYPAD. This is specified in e.g. the kbproto spec and XkbKeyTypesForCoreSymbols(3) man page. If these types are not specified in the keymap, the code specifically checks for them and adds them to the 4 first places in the types array, such that they exist in every keymap. These are also the types (along with some non-required 4-level ones) that are automatically assigned to keys which do not explicitly declare a type (see FindAutomaticType in symbols.c, this commit doesn't touch these heuristics, whcih are also not very nice but necessary). The xkeyboard-config does not rely on the builtin xkbcomp definitions of these types and does specify them explicitly, in types/basic and types/numpad, which are virtually always included. This commit removes the special behavior: - The code is ugly and makes keytypes.c harder to read. - The code practically never gets run - everyone who uses xkeyboard-config or a keymap based upon it (i.e. everyone) doesn't need it. So it doesn't get tested. - It mixes policy with implementation for not very good reasons, it seems mostly for default compatibility with X11 core. - And of course we don't need to remain compatible with Xkb ABI neither. Instead, if we read a keymap with no types specified at all, we simply assign all keys a default one-level type (like ONE_LEVEL), and issue plenty of warnings to make it clear (with verbosity >= 3). Note that this default can actually be changed from within the keymap, by writing something like type.modifier = Shift type.whatever_field = value in the top level of the xkb_types section. (This functionality is completely unused as well today, BTW, but makes some sense). This change means that if someone writes a keymap from scratch and doesn't add say ALPHABETIC, then something like <AE11> = { [ q Q ]; }; will ignore the second level. But as stated above this should never happen. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 09dac54b 2012-08-01T21:31:36 vmod: remove unused fields Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 41d9afc5 2012-07-27T15:31:03 Remove ExprResult Convert the IdentLookup typedef away from ExprResult, which drags along everything else. This should also make all of the conversions explicit. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 38614c88 2012-07-24T17:21:29 expr: drop ExprResult from ResolveMask Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 2e4933cd 2012-07-24T10:39:15 expr: drop ExprResult from ResolveInteger 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 6cb98200 2012-07-24T13:15:40 Use xkb_mod_mask_t and xkb_mask_index_t throughout 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 544a83e6 2012-07-21T15:27:09 vmod: use new log functions 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 3de9d874 2012-07-15T00:26:28 Get rid of xkb_server_map Same as xkb_client_map which was removed before. 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 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>
Daniel Stone 7b00485a 2012-05-11T15:03:43 Rename 'ctx' back to 'context' in external API Still keep things as 'ctx' internally so we don't have to worry about typing it too often, but rename the user-visible API back as it was kinda ugly. This partially reverts e7bb1e5f. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita e7bb1e5f 2012-05-09T15:03:11 Shorten context to ctx (This breaks the API.) "context" is really annoying to type all the time (and we're going to type it a lot more :). "ctx" is clear, concise and common in many other libraries. Use it! Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Fix for xkb -> keymap change.]
Ran Benita cdd2906d 2012-05-09T13:50:05 Make the context available for XkbcAtomText And rename the function to xkb_atom_text. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb -> keymap.]
Ran Benita 8d680e80 2012-05-09T12:01:03 Make the context available for XkbcAtomGetString In preparation of contextualizing atom handling. Since we touch every function call, we also rename the function to xkb_atom_strdup to match xkb_atom_intern, and be more descriptive. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Updated for xkb -> keymap.]
Ran Benita c117318f 2012-05-09T11:47:20 Make the context available to xkb_intern_atom In preparation of contextualizing the atom table. Since we touch every function call, also rename the function to xkb_atom_intern, to match better with the rest (which will also be renamed). Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Fixed for 'xkb' -> 'keymap'.]
Daniel Stone 38cb6390 2012-05-09T15:15:30 Change all 'xkb' xkb_keymap names to 'keymap' To make it a bit more clear what it actually is. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 33273304 2012-05-08T13:57:07 Rename xkbcomp/misc.h to xkbcomp-priv.h and use it The include dependencies were quite convoluted, where you change the order and get a ton of errors. Instead, change one file to act as the internal interface for the xkbcomp files, and make every file use it. Also drop the pointless "xkb" prefix to file names. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 62a75dc1 2012-04-10T23:08:49 Remove unused stuff from XKBcommonint.h Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a641a185 2012-04-06T03:38:55 Use stdbool.h 'Cause defining your own True and False is so 1990's. Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: Fixed for xkb_desc -> xkb_keymap changes.]
Daniel Stone ef88c7ef 2012-04-03T15:14:16 Rename xkb_desc to xkb_keymap struct xkb_desc was just a hangover from the old XkbDescRec, which isn't a very descriptive name. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita 84ec6b61 2012-04-01T16:51:48 Add a NULL check before before strcmp'ing The names array can have NULL entries for some virtual modifier indexes. Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita fb606b06 2012-04-01T17:07:56 Avoid use of partly initialized VModInfo in error path Such as: Compiling path: ./test/data/bad.xkb mapName: ==1300== Conditional jump or move depends on uninitialised value(s) ==1300== at 0x4E46166: HandleVModDef (vmod.c:90) ==1300== by 0x4E3FEC9: HandleKeyTypesFile (keytypes.c:1035) ==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387) ==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022) ==1300== by 0x4E3FBE1: HandleIncludeKeyTypes.constprop.11 (keytypes.c:387) ==1300== by 0x4E401DD: HandleKeyTypesFile (keytypes.c:1022) ==1300== by 0x4E4026F: CompileKeyTypes (keytypes.c:1150) ==1300== by 0x4E3DF9B: CompileKeymap (keymap.c:169) ==1300== by 0x4E465E9: compile_keymap (xkbcomp.c:205) ==1300== by 0x4E46BE4: xkb_compile_keymap_from_file (xkbcomp.c:290) ==1300== by 0x400B37: test_file (filecomp.c:47) ==1300== by 0x4008E3: main (filecomp.c:90) ==1300== Uninitialised value was created by a stack allocation ==1300== at 0x4E3FB3F: HandleIncludeKeyTypes.constprop.11 (keytypes.c:366) Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita 0480f427 2012-03-23T23:28:24 Remove useless stuff from utils Signed-off-by: Ran Benita <ran234@gmail.com> [daniels: fixed conflicts from strcasecmp, added includes to make filecomp build again]
Daniel Stone a0e756fd 2012-03-09T19:09:25 Introduce xkb_atom_t type Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 731e5c40 2012-03-09T18:53:47 Stringify public name types Ensure that all names under xkb_desc are strings, rather than atoms. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone b28823cc 2012-03-09T16:04:00 Remove KcCGST names from the map Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ran Benita eb738b13 2012-03-02T17:40:19 Constify global tables Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita f278cea1 2012-02-29T20:25:11 Remove all uses of the register keyword Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a3e40917 2012-03-01T23:43:51 Remove return's at the end of void functions Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita a0dd0526 2012-02-25T11:46:12 Remove unused includes of "tokens.h" Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone 43ed3ff0 2012-02-20T17:14:04 Switch expression resolution priv from char to void Avoids a lot of really lame casts. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 11ea0791 2012-02-20T17:07:48 Invert LookupModMask/LookupVModMask order We never want to solely lookup a virtual modifier without also looking up core modifiers. So, rather than chaining the vmod lookup inside the core modifier lookup, invert the ordering. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 90d86c36 2012-02-20T16:54:54 Remove field reference lookup support None of the lookup functions anyone ever used supported field references, so don't pretend we do in the API. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 91b89852 2012-02-20T16:24:02 Turn ExprResolveInteger into a simple wrapper Move the bulk of ExprResolveInteger into an internal function called ExprResolveIntegerLookup, and introduce ExprResolveInteger as a simple wrapper which doesn't take priv/lookup arguments. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 3151ce36 2012-02-20T13:34:36 Remove priv arguments from ExprResolveModMask What with them now being unused and all. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone 1a6c3807 2012-02-15T15:58:14 vmod: Pass xkb_desc explicitly to vmod functions Some error paths don't set info->xkb correctly, so just do like most utility functions and pass the xkb_desc explicitly. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Kristian Høgsberg a63e82be 2010-12-17T21:14:54 Rename XkbcInternAtom() to xkb_intern_atom() and export Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Adam Jackson 73ca959d 2010-09-27T16:05:52 Dead code removal and static markup Signed-off-by: Adam Jackson <ajax@redhat.com>
Kristian Høgsberg 9f602686 2010-07-01T14:35:24 Pull in enough structs and defines from XKBstr.h to only need XKB.h We want to move away from sharing implementation structs and let libX11 and libxkbcommon use each their own set of structs.
Kristian Høgsberg e10e16ad 2010-06-30T17:20:56 Constify XkbcAtomText() Atoms aren't mutable and this lets us put tbGetBuffer() back in the box.
Kristian Høgsberg 47d3b396 2010-06-28T06:50:12 Drop CARD32 and Opaque types
Daniel Stone 7257d4c8 2010-06-21T14:28:34 Use CARD32 instead of Atom, move geom headers in Use CARD32 instead of Atom/KeySym/et al to avoid type size confusion between server and non-server code; relatedly, move the geometry headers in from kbproto, so every non-simple type (i.e. structs containing nothing more than basic types) is now copied into xkbcommon. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Daniel Stone d20bdd3b 2010-06-15T15:14:58 xkbcomp: vmod: Don't get and immediately intern atoms XkbcInternAtom(XkbcAtomGetString(atom)) has to be the most spectacularly broken antipattern I've yet seen. Just compare the atoms directly. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Dan Nicholson 6a84a34d 2009-04-08T07:46:25 Remove all non-public API from XKBcommon.h header The noble intention was to expose all the new API and new generic types in the split out kbproto headers through XKBcommon.h. It turns out that would be a massive amount of work in the server. Someday, but first just wedging in XkbCompileKeymap* would be good. Most of the API is in new internal xkb*.h headers. In order to allow the XKBcommon.h header to be used from the server, we can't pull in other headers from kbproto since the server has its own copies. However, types that are different (XkbDescRec, XkbAction) still have Xkbc equivalents here, and I think they should be used in the server.
Dan Nicholson 8b100fc0 2009-04-05T15:15:20 Add action datatypes as defined in the server Some of the XkbAction types are defined differently in the server, so we add those to XKBcommon.h and use them here like XkbcDescPtr. We'll have to deal with the impedance mismatch on the client side later.
Dan Nicholson a2e59767 2009-04-04T12:50:27 xkbcomp: Don't say we're exiting when we're not
Dan Nicholson 5c910623 2009-04-04T09:19:51 Remove trailing spaces in source files
Dan Nicholson a27e56b6 2009-03-31T07:21:20 xkbcomp: Remove duplicated macros
Dan Nicholson 2671b777 2009-03-28T14:06:26 Add more *Text functions from xkbfile This should cover all the usage in xkbcomp. The format arguments were dropped except for the special case of XkbModMaskText, which needs to write in XkbCFile format in HandleVModDef. This was just changed to a Bool to avoid the need for the macros in XKBfile.h. The function prefixes have been renamed to be unique from xkbfile.
Dan Nicholson 39d7be43 2009-03-28T11:45:05 xkbcomp: Use xkbcommon allocation functions s/XkbAlloc/XkbcAlloc/ so we don't know XKBlib.
Dan Nicholson 8544cde5 2009-03-28T06:56:26 xkbcomp: Drop unused Display argument in Atom functions The xkbcommon Atom implementation doesn't take Display into account.
Dan Nicholson 18337008 2009-03-27T20:58:27 libxkbcomp: Use the internal Atom implementation s/XkbInternAtom/XkbcInternAtom/ and s/XkbAtomGetString/XkbcAtomGetString/
Dan Nicholson 4fe322aa 2009-03-27T20:13:22 libxkbcomp: s/XPointer/char */ Replace XPointer with its definition since we don't have the privilege of using Xlib.h. Why this is char * and not void *, I'll never know.
Dan Nicholson 37769b5a 2009-03-27T20:01:32 libxkbcomp: s/XkbDescPtr/XkbcDescPtr/ We need to use the keyboard description structure from XKBcommon.h since it doesn't have the Display field.
Dan Nicholson 30e01032 2009-03-27T19:25:14 libxkbcomp: Remove usage of client-side headers This will surely break things. Let's see just what we need to replace.
Dan Nicholson 0c1bbb05 2009-03-27T06:55:32 Import xkbcomp sources for CompileKeymap A copy of the xkbcomp sources (except the frontend) have been copied in to provide a means to compile a XkbDescPtr. This definitely doesn't build or do the right thing yet.