|
5b5b67f2
|
2023-05-01T22: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-05T17: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-12T14: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-28T00:33:19
|
|
keymap: share LevelsSameSyms()
The function is generic enough.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
c7e2e6d7
|
2015-10-26T21:57:39
|
|
keymap: fix outdated comment
See 725ae134d434bab6c999121d55dbc3582c4acb65.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
725ae134
|
2014-09-25T22: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-24T13: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-09T22: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-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>
|
|
|
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>
|
|
|
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>
|
|
|
0f6bca2b
|
2014-04-22T11: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-22T11:22:22
|
|
keymap: protect xkb_foreach_key macro params
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
95aabeec
|
2013-02-09T19: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-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>
|
|
|
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>
|
|
|
3d7aff5f
|
2014-04-19T16: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-19T15: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-16T10: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-09T17:49:30
|
|
keymap: reduce padding in struct xkb_sym_interpret
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
5dbd1364
|
2014-02-07T20: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-13T17: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-02T10: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-26T00: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-23T11: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-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>
|
|
|
a392d268
|
2012-08-12T11: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-11T12: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-04T18: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-04T12: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-03T21: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-01T21: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-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>
|
|
|
60bd9202
|
2012-11-11T00: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-23T09: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-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>
|
|
|
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>
|
|
|
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>
|
|
|
f3732d83
|
2012-10-10T17: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-10T17: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-06T21: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-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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
3b389b15
|
2012-09-27T18: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-24T14: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-24T14: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-24T12: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-24T00:50:19
|
|
keymap: use our type for keymap->enabled_ctrls
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
1d47cbfc
|
2012-09-23T22:32:53
|
|
keymap.h: add note on why XKB_NUM_GROUPS is still there
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
|
d941bc0c
|
2012-09-23T22: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-23T20: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-23T17: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>
|
|
|
be3cbc99
|
2012-09-22T10: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-21T14: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>
|