We probably don't want to get a privileged process to compile arbitrary
keymaps. So we should be careful about the envvars which control include
paths or default RMLVOs. But then secure_getenv is more sensible for
everything we do.
Signed-off-by: Ran Benita <ran234@gmail.com>
- Use 'test =' instead of 'test ==' in the x11 test. The second one
might not work with e.g. dash, whoops.
- Use AS_IF instead of 'if'. It actually blends in better..
Signed-off-by: Ran Benita <ran234@gmail.com>
- Remove outdated information about API/ABI stability. If we ever break
API or ABI, we'll do a major release. But currently everything is
stable.
- Remove outdated warnings about internal symbols. You simply cannot
access them...
- Briefly mention xkbcommon-x11 existence.
- Update git and bug URLs.
- Add myself as maintainer :)
Signed-off-by: Ran Benita <ran234@gmail.com>
Add two tests:
./test/interactive-x11
which is like test/interactive-evdev, but should behave exactly like your
X keyboard and react to state and keymap changes - in other words, just
like typing in xterm. Press ESC to exit.
./test/x11
which currently should only print out the same keymap as
xkbcomp $DISPLAY out.xkb
(modulo some whitespace and some constructs we do not support.)
Signed-off-by: Ran Benita <ran234@gmail.com>
These are function to create an xkb_keymap directly from XKB requests
to the X server. This opens up the possibility for X clients to use
xcb + xcb-xkb + xkbcommon as a proper replacement for Xlib + xkbfile for
keyboard support.
The X11 support must be enabled with --enable-x11 for now.
The functions are in xkbcommon/xkbcommon-x11.h. It depends on a recent
libxcb with xkb enabled. The functions are in a new libxkbcommon-x11.so,
with a new pkg-config file, etc. so that the packages may be split, and
libxkbcommon.so itself remains dependency-free.
Why not just use the RMLVO that the server puts in the _XKB_RULES_NAMES
property? This does not account for custom keymaps, on-the-fly keymap
modifications, remote clients, etc., so is not a proper solution in
practice. Also, some servers don't even set it. Now, the client just
needs to recreate the keymap in response to a change in the server's
keymap (as Xlib clients do with XRefreshKeyboardMapping() and friends).
Signed-off-by: Ran Benita <ran234@gmail.com>
This helps ensure we don't ship a library with undefined symbols, which
can easily happen with multiple inter-dependent DSOs.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
These functions also return -1 on invalid input. The original tests
didn't check that, but used !tests instead. Since then we've changed
them, but some were missed, and for some we forgot to remove the ! (or
you can say they were extra clever).
Signed-off-by: Ran Benita <ran234@gmail.com>
Someone was nice enough to run this for us:
ftp://ftp.sunet.se/pub/Linux/distributions/Debian/debian/pool/main/libx/libxkbcommon/libxkbcommon_0.3.1.orig.tar.gz
[libxkbcommon-0.3.1/src/keymap.c:86]: (style) The scope of the variable 'j' can be reduced.
[libxkbcommon-0.3.1/src/keymap.c:87]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/src/keysym-utf.c:843]: (style) The scope of the variable 'mid' can be reduced.
[libxkbcommon-0.3.1/src/state.c:992]: (style) The scope of the variable 'str' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/action.c:467]: (style) The scope of the variable 'absolute' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:468]: (style) The scope of the variable 'consumed' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:862]: (style) The scope of the variable 'mlvo' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:863]: (style) The scope of the variable 'kccgst' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/rules.c:865]: (style) The scope of the variable 'match_type' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:753]: (style) The scope of the variable 'toAct' can be reduced.
[libxkbcommon-0.3.1/src/xkbcomp/symbols.c:1573]: (style) The scope of the variable 'key' can be reduced.
[libxkbcommon-0.3.1/test/common.c:80]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'.
[libxkbcommon-0.3.1/test/interactive.c:358]: (style) The scope of the variable 'nevs' can be reduced.
[libxkbcommon-0.3.1/test/interactive.c:236]: (style) Checking if unsigned variable 'nsyms' is less than zero.
[libxkbcommon-0.3.1/test/interactive.c:226]: (style) Unused variable: unicode
Signed-off-by: Ran Benita <ran234@gmail.com>
This shows a measurable improvement in memory and performance for free,
on 64bit at least. Packing is (or should be) safe in this case.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead of having a darray of pointers to malloc'ed atom_node's, make it
a darray of atom_node's directly.
This makes the code a bit simpler, saves on some malloc's, and the
memory gain/loss even out.
Unfortunately, we are no longer Three Star Programmers ;(
http://c2.com/cgi/wiki?ThreeStarProgrammer
Signed-off-by: Ran Benita <ran234@gmail.com>
Currently, we have one ExprDef type, which contains a tagged union with
the value of all expression types. Turns out, this union is quite
wasteful memory-wise. Instead, create separate types for all expressions
(e.g ExprBinary, ExprInteger) which embed the common fields
(ExprCommon), and malloc them per their size; ExprDef then becomes a
union of all these types, but is just used as a generic pointer.
[Instead of making ExprDef a union, another option is to use
ExprCommon as the generic pointer type and then do up-castings, like we
do with ParseCommon. But this makes the code much uglier.]
The diff is mostly straightforward mechanical adaptations. It could have
been much smaller with the help of C11 anonymous structs (which were
previously a gnu extension). This will have saved all of the 'op' ->
'expr->op', etc changes. But if we can be a bit more portable for a
little effort, we should.
Before (./test/rulescomp, x86 32 bit, -O2):
==12974== total heap usage: 145,217 allocs, 145,217 frees, 10,476,238 bytes allocated
After:
==11145== total heap usage: 145,217 allocs, 145,217 frees, 8,270,358 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead of having the parser passing strings to the AST, and
symbols/compat etc. resolving them themselves. This simplifies the code
a bit, and makes it possible to print where exactly in the file the bad
keysym originates from.
The previous lazy approach had an advantage of not needlessly resolving
keysyms from unrelated maps. However, I think reporting these errors in
*any* map is better, and the parser is also a bit smarter then old
xkbcomp and doesn't parse many useless maps. So there's no discernible
speed/memory difference with this change.
Signed-off-by: Ran Benita <ran234@gmail.com>
Ran Benita
Hardening
Jasper St. Pierre