kc3-lang/libxkbcommon/src/keymap.h
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
df2322d7 | 2025-02-05 14:41:21 | Replace include guards by `#pragma once` We currently have a mix of include headers, pragma once and some missing. pragma once is not standard but is widely supported, and we already use it with no issues, so I'd say it's not a problem. Let's convert all headers to pragma once to avoid the annoying include guards. The public headers are *not* converted. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
|
e120807b | 2025-01-29 15:35:22 | Update license notices to SDPX short identifiers + update LICENSE Fix #628. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
 |
502e9e5b | 2025-01-29 12:19:10 | xkbcomp: Add stricter bounds for keycodes and levels Our current implementation uses continuous arrays indexed by keycodes and levels. This is simple and good enough for realistic keymaps. However, they are allowed to have big values that will lead to either memory exhaustion or a waste of memory (sparse arrays). Added the much stricter upper bounds `0xfff` for keycodes[^1] and 2048 for levels[^2], which should still be plenty enough and provides stronger memory security. [^1]: Current max keycode is 0x2ff in Linux. [^2]: Should be big enough to satisfy automatically generated keymaps. | |
|
c85c9bdc | 2025-01-27 17:15:06 | symbols: Allow levels with different keysyms and actions counts Contrary to groups, there is no reason for levels to restrict the same count of keysyms and actions. | |
|
0c940827 | 2025-01-22 16:39:35 | clang-tidy: Macro arguments should be enclosed in parentheses | |
|
8d0df44a | 2025-01-15 19:11:58 | text: Ensure mod mask can always be printed entirely | |
|
b0d9a790 | 2025-01-15 12:03:10 | vmods: Fix explicit vmods not dumped | |
|
d43bb955 | 2024-12-19 18:21:01 | symbols: Fix key symbols/actions merge - Fixed field for defined keysyms/actions - Fixed regression introduced by fdf2c525977e7e8af4135d593110f5bc1454abd8 | |
|
31a841ae | 2024-10-14 16:05:35 | state: support querying whether virtual modifiers are active Previously it was not possible to query the status of virtual modifiers with the following functions: - `xkb_state_mod_index_is_active` - `xkb_state_mod_indices_are_active` - `xkb_state_mod_name_is_active` - `xkb_state_mod_names_are_active` Note that it may *overmatch* if some modifier mappings overlap. For example, the default “us” PC layout maps both “Alt” and “Meta” to the real modifier “Mod1”; thus “Mod1”, “Alt” and “Meta” modifiers will return the same result with these functions. | |
|
fdf2c525 | 2024-10-08 19:43:30 | actions: Add support for multiple actions per level This makes 1 keysym == 1 action holds also for multiple keysyms per level. The motivation of this new feature are: - Make multiple keysyms per level more intuitive. - Explore how to fix the issue with shortcuts in multi-layout settings (see the xkeyboard-config issue[^1]). The idea is to use e.g.: ```c key <LCTL> { symbols[1] = [ {Control_L, ISO_First_Group } ], actions[1] = [ {SetMods(modifiers=Control), SetGroup(group=-4) } ] }; ``` in order to switch temporarily to a reference layout in order to get the same shortcuts on every layout. When no action is specified, `interpret` statements are used to find an action corresponding for *each* keysym, as expected. For an interpretation matching Any keysym, we may get the same interpretation for multiple keysyms. This may result in unwanted duplicate actions. So set this interpretation only if no previous keysym was matched with this interpret at this level, else set the default interpretation. For now, at most one action of each following categories is allowed per level: - modifier actions: `SetMods`, `LatchMods`, `LockMods`; - group actions: `SetGroup`, `LatchGroup`, `LockGroup`. Some examples: - `SetMods` + `SetGroup`: ok - `SetMods` + `SetMods`: error - `SetMods` + `LockMods`: error - `SetMods` + `LockGroup`: ok [^1]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/416 | |
|
772ac0c4 | 2024-09-23 11:02:35 | keymap: Rename keysyms field in xkb_level The current field `u` (short for “union”) is not very descriptive. Next commit will add multiple actions per level, so let’s rename the keysym field to `s` (short for “symmbols”). | |
|
7c4c718b | 2024-09-30 06:13:38 | Allow only the first group in symbols sections when using RMLVO Currently `xkb_keymap_num_layouts` may return a greater number than the number of layouts configured using RMLVO, because we allow symbols sections to define various groups per key. This is unintuitive and kind of buggy: groups should be added via rules by setting an explicit `:n` modifier. Fix: when parsing a keymap using RMLVO resolution: - Get the expected layouts count from the resulting KcCGST. - Drop the groups after the first one in included symbols sections. This will ensure that a symbol section can only define one group per key. Notes: - Compiling a keymap string directly is unaffected. - RMLVO resolution may still produce more groups than the input layouts. Indeed, some legacy rules in xkeyboard-config rely on this to insert automatically a US layout before the given non-Latin one, resulting in two layouts while only one was given. | |
|
948f7a59 | 2024-10-09 08:34:27 | symbols: Skip interprets only for groups with explicit actions Previously setting explicit actions for a group in symbols files made the parser skip compatibility interpretations for the corresponding *whole* key, so the other groups with *no* explicit actions could result broken on some levels. In the following example, `<RALT>` would have an action on group 2, because it is explicit, but none on group 1 because interpretation are also skipped there as a side effect: ```c key <RALT> { symbols[1]= [ ISO_Level3_Shift ], symbols[2]= [ ISO_Level3_Shift ], actions[2]= [ SetMods(modifiers=LevelThree) ] }; ``` Fixed by skipping interpretations *only* for groups with explicit actions. We still set `key->explicit |= EXPLICIT_INTERP` if at least one group has explicit actions. In such case, when dumping a keymap, we will write explicit actions for *all* groups, in order to ensure that X11 and previous versions of libxkbcommon can parse the keymap as intended. One side effect is that no interpretation will be run on this key anymore, so we may have to set some extra fields explicitly: repeat, virtualMods. Thus the previous example would be bumped as: ```c key <RALT> { repeat= No, symbols[1]= [ ISO_Level3_Shift ], actions[1]= [ SetMods(modifiers=LevelThree,clearLocks) ], symbols[2]= [ ISO_Level3_Shift ], actions[2]= [ SetMods(modifiers=LevelThree) ] }; ``` | |
|
5b5b67f2 | 2023-05-01 22:30:41 | Add support for modmap None (#291) Unlike current xkbcommon, X11’s xkbcomp allows to remove entries in the modifiers’ map using “modifier_map None { … }”. “None” is translated to the special value “XkbNoModifier” defined in “X11/extensions/XKB.h”. Then it relies on the fact that in "CopyModMapDef", the following code: 1U << entry->modifier ends up being zero when “entry->modifier” is “XkbNoModifier” (i.e. 0xFF). Indeed, it relies on the overflow behaviour of the left shift, which in practice resolves to use only the 5 low bits of the shift amount, i.e. 0x1F here. Then the result of “1U << 0xFF” is cast to “char”, i.e. 0. This is a good trick but too magical, so in libxkbcommon we will use an explicit test against our new constant XKB_MOD_NONE. | |
 |
d92a248c | 2020-02-05 17:42:06 | API to query modifier set required to type a keysym The new API is useful to implement features like auto-type and desktop automation. Since the inputs for these features is usually specified in terms of the symbols that need to be typed, the implementation needs to be able to invert the keycode->keysym transformation and produce a sequence of keycodes that can be used to type the requested character(s). | |
 |
26453b84 | 2017-12-12 14:30:21 | keymap: fix NULL dereference when dumping the default fallback type The default fallback type uses type->level_names = NULL but the keymap-dump code was not checking this case. Instead of adding more workarounds and possible bugs (e.g. previous commit), let's just keep the number of level names separately. This has the additional advantage retains extraneous level name if someone adds them for some reason. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
39082082 | 2016-02-28 00:33:19 | keymap: share LevelsSameSyms() The function is generic enough. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c7e2e6d7 | 2015-10-26 21:57:39 | keymap: fix outdated comment See 725ae134d434bab6c999121d55dbc3582c4acb65. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
725ae134 | 2014-09-25 22:01:17 | keymap: rename XkbKeyGroupWidth to XkbKeyNumLevels The "width" terminology comes from the group*width+level layout of the keysyms in a key, as used in the old implementations. We don't keep all the keysyms of a key in one array so change it to a more accurate name. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
99184f16 | 2012-11-24 13:29:54 | Make the effective mod mask calculation available to other files We will want to use that function in state.c as well. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
d38ff018 | 2014-08-09 22:19:39 | keymap: remove "flags" field of xkb_private_action Private actions have no flags - only serialized data. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9014cf8c | 2014-04-22 13:15:21 | keymap, keycodes, compat: don't use darray for LEDs Use a static array of size XKB_MAX_LEDS instead, as in xkb_mod_set. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
787faf36 | 2014-04-22 12: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> | |
|
6b1cdee1 | 2014-04-22 11:47:23 | keymap: add and use xkb_mods_{foreach,enumerate}() To iterate over an xkb_mod_set. Slightly nicer interface and makes transitioning from darray easier. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0f6bca2b | 2014-04-22 11:33:47 | keymap: rename xkb_foreach_key to xkb_keys_foreach We'll use the format xkb_foos_foreach and xkb_foos_enumerate for the various iterators. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9b1a68ec | 2014-04-22 11:22:22 | keymap: protect xkb_foreach_key macro params Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
95aabeec | 2013-02-09 19:10:56 | symbols: use xkb_mod_set instead of entire keymap The keymap is not removed entirely from the Info (just constified), since it is still needed in AddKeySymbols() for looking up aliases. This dependency will be removed in the future. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
edc0aef5 | 2013-02-08 13: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> | |
|
ca3170ad | 2013-02-08 13:09:33 | Add struct xkb_mod_set The only thing that the compilation phase needs the keymap for currently is for access to the modifier information (it also modifies it in place!). We want to only pass along the neccessary information, to make it more tractable and testable, so instead of passing the entire keymap we add a new 'mod_set' object and pass a (const) reference to that. The new object is just the old array of 'struct xkb_mod'. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3d7aff5f | 2014-04-19 16:15:05 | keymap: rename wrap_group_into_range -> XkbWrapGroupIntoRange It better fits with the naming convention in keymap.h. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
51a1df2f | 2014-04-19 15:56:27 | keymap: move ModNameToIndex from text.c and use it in keymap.c Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
18191702 | 2014-02-16 10:59:42 | keymap: change action flag NO_ACCEL -> ACCEL It's easier to deal with, but we need to set it as "factory default". Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
27a24589 | 2014-02-09 17:49:30 | keymap: reduce padding in struct xkb_sym_interpret Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
5dbd1364 | 2014-02-07 20:58:19 | action: change xkb_pointer_button_action::button to uint8_t In XkbPtrBtnAction it is unsigned char, don't know how it became signed. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7210497c | 2014-01-13 17:07:41 | keymap: split private functions to keymap-priv.c This makes it easier to share the private functions in other DSOs without relying (too much) on dead code elimination, exported symbols, etc. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4884a8e6 | 2013-08-02 10:19:01 | keymap: move XkbEscapeMapName() to keymap.c. So we can use it outside src/xkbcomp; it is not really specific to it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
be38862b | 2013-07-26 00:50:26 | keymap: remove struct xkb_key_redirect_action The file src/xkbcomp/action.c already doesn't handle this action type and fails if it encounters it. So lets not pretend to do something with it, and ignore it rather than failing. If we/someone wants this we can consider implementing it. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
806d24b1 | 2013-07-23 11:36:01 | keymap: move RANGE_WRAP to be the first in the enum This is the reasonable "zero-default" for this enum. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9ffe9dae | 2013-07-21 09:48:12 | keymap: don't use darray for sym_interprets We want xkb_keymap to be easy to handle everywhere. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
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> | |
 |
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 | |
|
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> | |
|
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> | |
|
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> | |
|
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> | |
|
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> | |
|
60bd9202 | 2012-11-11 00:22:46 | keymap: wrap the layout parameter if it is out of range for the key The functions num_levels_for_key() and get_syms_by_level() have a 'layout' parameter. Currently it is expected that this value is always legal for the key, as determined by num_layouts_for_key(). However, there are legitimate use cases for passing an out-of-range layout there, most probably passing the effective layout, and expecting to get the keysyms/levels for just this layout. So we wrap it just as we do in the xkb_state_* functions. This is also useful for stuff like this: http://developer.gnome.org/gdk/stable/gdk-Keyboard-Handling.html#gdk-keymap-lookup-key If this behavior is not desired, the user has the option to check against num_layouts_for_key herself. https://bugs.freedesktop.org/show_bug.cgi?id=56866 Reported-by: Gatis Paeglis <gatis.paeglis@digia.com> 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> | |
|
eb748ab6 | 2012-10-18 21:04:27 | Clean up xkb_sym_interpret a bit First we split the LEVEL_ONE_ONLY bit off of the 'match' field, which allows us to turn enum xkb_match_operation to a simple enum and remove the need for MATCH_OP_MASK. Next we rename 'act' to 'action', because we've settled on that everywhere else. Finally, SIMatchText is changed to not handle illegal values - it shouldn't get any. This removes one usage of the GetBuffer hack. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b6ddd105 | 2012-10-11 14:05:49 | keymap: rename keymap->sym_interpret -> sym_interprets This can be a bit confusing. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9197eb0f | 2012-10-10 19:08:01 | Remove the XKB_NUM_INDICATORS limit Use a darray instead of a static array of size 32. We still enforce XKB_MAX_LEDS because of the size of xkb_led_mask_t. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
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> | |
|
9984d1d0 | 2012-10-06 21:37:43 | keymap: use xkb_mod_mask_t for interpret->mods and modmap These are both real modifier masks, but we keep this information only in the program logic now so when we change it we don't have to worry about the type. 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> | |
|
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> | |
|
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> | |
|
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> | |
|
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> | |
|
e0573c76 | 2012-09-24 00:50:19 | keymap: use our type for keymap->enabled_ctrls Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
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> | |
|
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> | |
|
9a18b872 | 2012-09-23 17:52:51 | Add format argument to xkb_keymap_get_as_string This function really needs a format argument, for symmetry with the keymap creation functions. If we add new formats, we will almost certainly want to add support for serializing it into a string. It would also allow to convert from one format to another, etc. The in the common case, the user would just want to use the format she used to create the keymap; for that we add a special XKB_KEYMAP_USE_ORIGINAL_FORMAT value, which will do that (it is defined to -1 outside of the enum because I have a feeling we might want to use 0 for something else). To support this we need to keep the format inside the keymap. While we're at it we also initialize keymap flags properly. This changes the API, but the old xkb_map_get_as_string name works as expected so this is the best time to do this. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1d47cbfc | 2012-09-23 22:32:53 | keymap.h: add note on why XKB_NUM_GROUPS is still there Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
be3cbc99 | 2012-09-22 10:21:22 | keymap: remove XkbKeyGetKeycode Because we keep the keycode inside the xkb_key now. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
bbaa11c6 | 2012-09-21 14:58:31 | Rename map.{c,h} to keymap.{c,h} Seeing as we don't like "map" anymore. Signed-off-by: Ran Benita <ran234@gmail.com> |