The PLACEHOLDER was not meant to be used, but c++ doesn't like passing 0
to enums, so it was used. For this reason we add all the NO_FLAGS items,
so the PLACEHOLDER shouldn't be used anymore.
Second, XKB_MAP is the prefix we used ages ago, KEYMAP is the expected
prefix here. So deprecate that as well.
The old names may still be used through the xkbcommon-compat.h header,
which is included by default (no need to include directly).
Signed-off-by: Ran Benita <ran234@gmail.com>
Before:
ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
ran 20000000 iterations in 6.623018074s
After:
ran@ran:~/src/libxkbcommon$ ./test/bench-key-proc
ran 20000000 iterations in 4.762291091s
Not that anyone needs to process millions of keys per second...
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
This reverts commit 1e6e5669c6.
It's probably safe, but let's not take any chances, as I don't have any
esoteric arch to test on. But keep the ATTR in case it's ever useful.
Signed-off-by: Ran Benita <ran234@gmail.com>
The int ones cannot be signed (they come as such from the scanner, and
NEGATE is never applied to them).
The uint32_t one is really an atom, but presumably the type was never
converted to xkb_atom_t.
Signed-off-by: Ran Benita <ran234@gmail.com>
size_t is too large; if we ever need it, that's the least of our
problems. Besides, when we roll our own (e.g. in keymap.h) it's already
unsigned int. Instead, add some emergency overflow check. So, why?
- It plays nicer with all the other uint32_t's and unsigned int's (no
extensions, etc.).
- Reduces keymap memory usage by 5% or so as a bonus.
Signed-off-by: Ran Benita <ran234@gmail.com>
Integer may be negative, so also need to test >= 0.
Also, $$ was left uninitialized if the keysym wasn't recognized.
Signed-off-by: Ran Benita <ran234@gmail.com>
We have quite diverged from the upstream file, so let's make it at least
easier to look at. Remove some unused macros and rename some for
consistency.
Signed-off-by: Ran Benita <ran234@gmail.com>
This must always hold (but if there are no actions, #actions==0), and
explicitly ensures there won't be a division-by-zero a bit below.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
Ran Benita