summaryrefslogtreecommitdiff
path: root/src/xkbcomp/keymap.c
AgeCommit message (Collapse)AuthorFilesLines
2023-09-24Messages: merge macros with and without message codePierre Le Marre1-5/+9
Previously we had two types of macros for logging: with and without message code. They were intended to be merged afterwards. The idea is to use a special code – `XKB_LOG_MESSAGE_NO_ID = 0` – that should *not* be displayed. But we would like to avoid checking this special code at run time. This is achieved using macro tricks; they are detailed in the code (see: `PREPEND_MESSAGE_ID`). Now it is also easier to spot the remaining undocumented log entries: just search `XKB_LOG_MESSAGE_NO_ID`.
2023-09-24Messages: add new messages to registryPierre Le Marre1-0/+1
This commit is another step to identify and document the maximum number of logging messages. Bulk changes: - Rename `conflicting-key-type` to `conflicting-key-type-merging-groups`. Giving more context in the name allow us to introduce `conflicting-key-type-definitions` later. - Add conflicting-key-type-definitions - Add conflicting-key-type-map-entry - Add undeclared-modifiers-in-key-type Also improve the log messages. - Add conflicting-key-type-preserve-entries - Use XKB_ERROR_UNSUPPORTED_MODIFIER_MASK - Add illegal-key-type-preserve-result - Add conflicting-key-type-level-names - Add duplicate-entry - Add unsupported-symbols-field - Add missing-symbols-group-name-index - Use XKB_ERROR_WRONG_FIELD_TYPE - Add conflicting-key-name - Use XKB_WARNING_UNDEFINED_KEYCODE - Add illegal-keycode-alias - Add unsupported-geometry-section - Add missing-default-section - Add XKB_LOG_MESSAGE_NO_ID - Rename log_vrb_with_code to log_vrb - Use ERROR_WRONG_FIELD_TYPE & ERROR_INVALID_SYNTAX - Add unknown-identifier - Add invalid-expression-type - Add invalid-operation + fixes - Add unknown-operator - Rename ERROR_UNKNOWN_IDENTIFIER to ERROR_INVALID_IDENTIFIER - Add undeclared-virtual-modifier - Add expected-array-entry - Add invalid-include-statement - Add included-file-not-found - Add allocation-error - Add invalid-included-file - Process symbols.c - Add invalid-value - Add invalid-real-modifier - Add unknown-field - Add wrong-scope - Add invalid-modmap-entry - Add wrong-statement-type - Add conflicting-key-symbols-entry - Add invalid-set-default-statement
2019-12-27build: include config.h manuallyRan Benita1-0/+2
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>
2018-07-30xkbcomp: fix crash when parsing an xkb_geometry sectionRan Benita1-2/+7
xkb_geometry sections are ignored; previously the had done so by returning NULL for the section's XkbFile, however some sections of the code do not expect this. Instead, create an XkbFile for it, it will never be processes and discarded later. Caught with the afl fuzzer. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-10-18xkbcomp: remove file->topNameRan Benita1-7/+1
It is useless. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-10-18xkbcomp/keymap: remove useless free()Ran Benita1-3/+1
Signed-off-by: Ran Benita <ran234@gmail.com>
2014-09-25keymap: rename XkbKeyGroupWidth to XkbKeyNumLevelsRan Benita1-2/+2
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>
2014-08-18Make the effective mod mask calculation available to other filesRan Benita1-9/+1
We will want to use that function in state.c as well. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-06-01Remove unnecessary !!(expressions)Ran Benita1-1/+1
_Bool already does that. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-04-22keymap, keycodes, compat: don't use darray for LEDsRan Benita1-2/+2
Use a static array of size XKB_MAX_LEDS instead, as in xkb_mod_set. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-04-22keymap: add and use xkb_mods_{foreach,enumerate}()Ran Benita1-2/+2
To iterate over an xkb_mod_set. Slightly nicer interface and makes transitioning from darray easier. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-04-22keymap: rename xkb_foreach_key to xkb_keys_foreachRan Benita1-4/+4
We'll use the format xkb_foos_foreach and xkb_foos_enumerate for the various iterators. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-04-19Add struct xkb_mod_setRan Benita1-2/+2
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>
2014-02-08Use (1u << idx) instead of (1 << idx) where appropriateRan Benita1-3/+3
It doesn't matter (I think), since the implicit conversion doesn't have any effect (e.g. sign-extension). But it's better to be aware of the type. Signed-off-by: Ran Benita <ran234@gmail.com>
2014-02-08Fix sign-compare warningsRan Benita1-1/+1
Signed-off-by: Ran Benita <ran234@gmail.com>
2013-07-31keymap: update builtin fields directly in src/keymap.cRan Benita1-25/+0
This fields are part of our API and every keymap should have them, not just xkbcomp/ ones. Signed-off-by: Ran Benita <ran234@gmail.com>
2013-07-21ctx: adapt to the len-aware atom functionsRan Benita1-8/+8
xkb_atom_intern now takes a len parameter. Turns out though that almost all of our xkb_atom_intern calls are called on string literals, the length of which we know statically. So we add a macro to micro-optimize this case. Signed-off-by: Ran Benita <ran234@gmail.com>
2013-07-21keymap: don't use darray for sym_interpretsRan Benita1-2/+3
We want xkb_keymap to be easy to handle everywhere. Signed-off-by: Ran Benita <ran234@gmail.com>
2013-04-01xkbcomp/keymap: silence a gcc warningRan Benita1-1/+1
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>
2013-03-18keymap: rename xkb_kt_map_entry to xkb_key_type_entryRan Benita1-2/+2
That's a better name and fits more nicely. Also change type->map to type->entries. Signed-off-by: Ran Benita <ran234@gmail.com>
2013-03-18Build cleanly with clangRan Benita1-1/+1
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>
2013-03-18Change 'indicator' to 'led' everywhere possibleRan Benita1-4/+4
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>
2012-10-18Clean up xkb_sym_interpret a bitRan Benita1-13/+8
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>
2012-10-11keymap: rename keymap->sym_interpret -> sym_interpretsRan Benita1-2/+2
This can be a bit confusing. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-10-10Remove the XKB_NUM_INDICATORS limitRan Benita1-3/+3
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>
2012-10-06Replace 0xff with MOD_REAL_MASK_ALLRan Benita1-1/+1
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>
2012-10-06Remove now-unneeded mod type annotationsRan Benita1-2/+2
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>
2012-10-06Keep real and virtual mods in the same table in the keymapRan Benita1-10/+35
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>
2012-10-06Don't use shifted virtual modifier masksRan Benita1-6/+5
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>
2012-10-06Remove the XKB_NUM_VIRTUAL_MODIFIERS limitRan Benita1-19/+9
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>
2012-10-06Use our types instead of int/uint32_t in a few placesRan Benita1-1/+1
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-27xkbcomp/keymap: use default interpret in ApplyInterpsToKeyRan Benita1-14/+19
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>
2012-09-24keymap: store a pointer to the type in xkb_group instead of indexRan Benita1-2/+2
Gets rid of some more unneeded indirection, including the XkbKeyType macro. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24keymap, symbols: improve xkb_key memory layoutRan Benita1-17/+7
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>
2012-09-24Don't use xkbcommon-compat names in internal codeRan Benita1-2/+2
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-24Promote keymap enumeration API to publicDaniel Stone1-1/+2
Rename the functions to get keysyms by key/layout/level to fit with the recent public API renames, and expose them. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-19xkbcomp/keymap: correct ACTION_MODS_LOOKUP_MODS handlingRan Benita1-15/+5
The xkblib spec says: If XkbSA_UseModMapMods is not set in the flags field, the mask, real_mods, vmods1, and vmods2 fields are used to determine the action modifiers. Otherwise they are ignored and the modifiers bound to the key (client map->modmap[keycode]) are used instead. So we should just assign the modmap without considering what's there. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-14state, map: constify references to xkb_keyRan Benita1-1/+1
Makes it clear that we treat the keys as immutible values in these files. Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-12Copyright updatesDaniel Stone1-11/+14
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>
2012-09-11kbproto unentanglement: XkbExplicit*MaskDaniel Stone1-3/+3
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-11kbproto unentanglement: XkbSI_AutoRepeatDaniel Stone1-1/+1
That was the only interp flag, so just turn it into a straight boolean. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-11kbproto unentanglement: XkbSI match flagsDaniel Stone1-8/+8
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-10kbproto unentanglement: action flagsDaniel Stone1-1/+1
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-10kbproto unentanglement: action typesDaniel Stone1-4/+4
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-10Remove deprecated actionsDaniel Stone1-5/+0
We didn't do anything with ISO_Lock, ActionMessage, RedirectKey, and the device-specifying variants of the pointer actions, so remove those. Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-10kbproto unentanglement: XkbNumVirtualModsDaniel Stone1-4/+4
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-10kbproto unentanglement: XkbNumIndicatorsDaniel Stone1-1/+1
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
2012-09-03Use XKB_MOD_INVALID instead of XkbNoModifierRan Benita1-1/+1
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-03keymap: optimize FindInterpsForKey a bitRan Benita1-5/+8
Signed-off-by: Ran Benita <ran234@gmail.com>
2012-09-03keymap: refactor ApplyInterpsToKeyRan Benita1-33/+14
There's really not much to explain what the function used to do there... Signed-off-by: Ran Benita <ran234@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-26 02:27:33 +0000