The arrays found in KeyInfo are by far the most complicated, so this is
taken one member at a time so as not to break anything.
Signed-off-by: Ran Benita <ran234@gmail.com>
- Make darray_free also initialize the array back to an empty state, and
stop worrying about it everywhere.
- Add darray_mem, to access the underlying memory, which we do manually
now using &darray_item(arr, 0). This makes a bit more clear when we
actually mean to take the address of a specific item.
- Add darray_copy, to make a deep copy of a darray.
- Add darray_same, to test whether two darrays have the same underlying
memory (e.g. if the struct itself was value copied). This should used
where previously two arrays were compared for pointer equality.
Signed-off-by: Ran Benita <ran234@gmail.com>
Here are some quick numbers from valgrind, running rulescomp only with a
simple, common "us,de" rule set:
before darray: cb047bb
total heap usage: 44,924 allocs, 44,924 frees, 3,162,342 bytes allocated
after darray: c87468e
total heap usage: 52,670 allocs, 52,670 frees, 2,844,517 bytes allocated
tweaking specific inital allocation sizes:
total heap usage: 52,652 allocs, 52,652 frees, 2,841,814 bytes allocated
changing initial alloc = 2 globally
total heap usage: 47,802 allocs, 47,802 frees, 2,833,614 bytes allocated
changing initial alloc = 3 globally
total heap usage: 47,346 allocs, 47,346 frees, 3,307,110 bytes allocated
changing initial alloc = 4 globally
total heap usage: 44,643 allocs, 44,643 frees, 2,853,646 bytes allocated
[ Changing the geometric progression constant from 2 only made things
worse. I tried the golden ratio - not so golden :) ]
The last one is obviously the best, so it was chosen, with the specific
tweaks thrown in as well (these were there before but don't make much
difference). Overall it seems to do better than the previous manual
allocations which is a bit surprising.
Signed-off-by: Ran Benita <ran234@gmail.com>
These were made const when the structs were exposed in the API. Now they
are private and we shouldn't mess around with the UNCONSTIFY business.
Signed-off-by: Ran Benita <ran234@gmail.com>
This avoids a couple of special cases in the code, and is more
consistent. Since anyone who includes xkbcommon.h also gets
xkbcommon-keysyms.h, and anyone who include xkbcommon-keysyms.h would
want NoSymbol anyway, there's no down side.
Signed-off-by: Ran Benita <ran234@gmail.com>
This code uses a table and code derived from
http://www.cl.cam.ac.uk/~mgk25/ucs/keysym2ucs.c
The added API calls are:
xkb_keysym_to_utf32
xkb_keysym_to_utf8
[daniels: Changed API to be more in line with keysym_get_name, added
test, changed formatting to 4-space.]
If we can merge cleanly (i.e. use the entirety of one entry rather than
having to go level by level), then just reuse the existing symbols array
and skip the entire merge process.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
A symbols file may contain a global, non key specific setting for
the group out-of-range handling method (wrap, clamp, redirect). Only
that:
* Its parsed and kept in the SymbolsInfo, but is not otherwise used in
any way (it's the same in the real xkbcomp).
* It's not used in any of xkeyboard-config files.
* It's not mentioned in the xkb specs (only the per-key ones).
* It doesn't make much sense anyway.
So remove the struct field, and emit an "unsupported, ignored" warning.
We don't increment the error count because of it, just continue (the
radio group warning just below is changed to do the same - there's no
reason to possibly abort the entire thing for it).
Signed-off-by: Ran Benita <ran234@gmail.com>
Conflicts:
src/xkbcomp/symbols.c
Instead of using NoSymbol in the map, we use num_syms == 0 to signify
the non-presence of a symbol. So instead of adding NoSymbol mappings
to the list regardless, detect them and set num_syms == 0.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The failure mode here is a little irritating:
- server loads map with ISO_Lock action
- server dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
action= NoAction();
};
as we don't (yet) print ISO_Lock actions
- client parses keymap from string
- client dumps keymap to string, including:
interpret ISO_Lock+AnyOfOrAll(None) {
};
- this results in a syntax error
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some actions could also take relative rather than absolute parameters,
so they really needed to be signed instead of explicitly unsigned.
Oops.
Fixes, e.g., action= MovePtr(x=-1,y=+1), which was reported as
(x=+65535,y=+1).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Currently, if you pass in an rmlvo with an empty string for layout or
variant, it would not match layout and variant rules even with
wildcards. But if the rules file had set an appropriate default, and someone
passes in the empty string, than he should get the default.
NULL in this case signifies not wanting to match against the layout or
variant at all, and so the rule should still fail to match NULLs.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Daniel Stone
Rob Bradford