This rule allows you to put several xkb_keymaps in one file.
This doesn't make any sense: only the default/first can ever be used,
yet the others are fully parsed as well.
Different keymaps should just be put in different files.
Signed-off-by: Ran Benita <ran234@gmail.com>
This rule allows you to write file maps as:
xkb_keycodes
<BLA> = 5;
[...]
instead of the usual format which is:
xkb_keycodes {
<BLA> = 5;
[...]
};
This is not documented, It is also not used in xkeyboard-config, and I
have never run into it otherwise. It also only allows one map per file.
It *might* be used in some obscure place, but probably nothing we should
care about; the simplified grammar is more useful for us now.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is a proof-of-concept for the long key names. The keycodes in the
file evdev-xkbcommon are autogenerated from linux/input.h, and uses the
names given there; all of the previous names are aliased to the new
names, so they continue to work with the symbols files, etc.
You can try it with 'sudo ./test/interactive -r evdev-xkbcommon -n 0'
The -n 0 means that we don't offset the evdev scan codes - just feed
them directly. The -r evdev-xkbcommon just means to use a new rules file
which makes us use the new keycodes file. (The only problem I can see is
with the MENU and LSGT names which has some conflicts).
Maybe some day xkeyboard-config could ship something similar, so that
the 8 offset is unneeded.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
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>
The autoType variable is supposed to tell us whether the type was
explicitly specified by the user or was detected automatically according
to the keysyms. It then allows us to know whether to prints the type
when we dump the keymap to a string or not.
Right now it is not always set when we find an automatic type, according
to some apparently legacy rules. We change it to simply this: type
computed automatically? -> don't print.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
Instead of maintaining a syms array in the GroupInfo + sym_index's in
the levels. This simplifies the code somewhat.
In order not to alloc for every level instead of every group, we only do
it if the level has more than one keysym (with a union). Since for now
this is a special case, it actually works out better memory-wise.
Signed-off-by: Ran Benita <ran234@gmail.com>
If we enter this branch, we have 3 <= width <= 4, so if the width is 3
than syms[3] is out of bounds.
Happily inherited from xkbcomp.
Signed-off-by: Ran Benita <ran234@gmail.com>
The levels will be resized to the number of levels of the type anyway,
so removing useless levels from the end here is unneeded.
Signed-off-by: Ran Benita <ran234@gmail.com>
The code that handles group name statements currently does this:
info->group_names[grp - 1 + info->explicit_group] = name;
Other than the fact that this addition makes no sense, it actually can
reach out of the bounds of the array (which is of size XKB_NUM_GROUPS)
in the (non-realistic) case where (grp - 1) is not 0 (i.e. the statement
is not name[Group1] = "foo").
We also change explicit_group to be XKB_LAYOUT_INVALID if not set
otherwise, instead of initializing it to 0; this is clearer and if
someone happens to write 'us:1' for some reason, it will discard the
other groups in the file as it should.
This entire explicit_group thing was clearly bolted on as an
afterthought.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
This is useful to see whether the function was successful and whether
truncation occurred.
It just changes void -> int so shouldn't break API or ABI.
Signed-off-by: Ran Benita <ran234@gmail.com>
To make it look better and a bit more structured and informative.
Not all of the functions are converted to doxygen format, so this is not
finished.
Signed-off-by: Ran Benita <ran234@gmail.com>
Simple HTML docs generated from the doxygen comments.
After running 'make' or 'make doc', try firefox doc/html/index.html to
see it (if you have doxygen). It's also installed with 'make install'.
You can use --enable-docs or --disable-docs, or specifically
--with-doxygen or --without-doxygen (autodetected, default yes).
The docs are currently not distributed in the tarball, because I
couldn't make it work properly in all cases :/
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
Before it was a static array of size XKB_NUM_GROUPS.
The previous cleanups made this transition a bit easier. This is a
first step for removing the XKB_NUM_GROUPS hardcoded limit; but for now
we still check that the groups are < XKB_NUM_GROUPS (e.g. in
ResolveGroup and GetGroupIndex) until the keymap, etc. is worked out as
well.
This also makes us alloc quite a bit less (this is just rulescomp):
Before:
==51999== total heap usage: 291,474 allocs, 291,474 frees, 21,458,334 bytes allocated
After:
==31394== total heap usage: 293,595 allocs, 293,595 frees, 18,150,110 bytes allocated
This is because most rmlvo's don't use the full 4 layouts that KeyInfo
had always alloced statically before.
Signed-off-by: Ran Benita <ran234@gmail.com>
These values weren't wrapped before, which caused group_index_is_active
to stop working after a few group switches.
Also, the current group-wrapping function didn't take into consideration
actions such as LockGroup=-1, which need to wrap around, etc.
xkb_layout_index_t is unsigned, but it was used to hold possibly
negative values (e.g. locked_group is 0 and gets a -1 action).
This group wrapping function should now act like the XkbAdjustGroup
function from xserver, and at least ./test/interactive doesn't bring up
any problems with group switching any more.
Signed-off-by: Ran Benita <ran234@gmail.com>
Currently, xkb_state_layout_{index,name}_is_active may report multiple
groups as effective, because at looks at base,latched,locked separately.
But there can only be one effective group, which is computed from the
other three. So if XKB_STATE_EFFECTIVE is requested, just compare to the
effective group we have computed.
We also modify mod_{index,name}_is_active similarly, just for symmetry
(there the effective mask is just an OR of the other three so the
current test is correct).
Signed-off-by: Ran Benita <ran234@gmail.com>
What this code does is, in case someone compile a keymap like -layout
'us,us,us' then only one group would be created. If there is anything
which differentiates between any of the groups (e.g. a variant, another
layout), then this is not done.
This is pretty obscure, only saves a few kbytes in the final keymap, and
if the user asked for it, why not let her?
Signed-off-by: Ran Benita <ran234@gmail.com>
This old rules parser gives the same kccgst here, so in the interest of
staying compatible we shouldn't fix it there. Similarly we shouldn't
touch ParseIncludeMap, so this is the best place to handle this.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone