Separate the ctx object to its own field in CompatInfo, instead of doing
keymap->ctx.
The compilation functions should not have direct access to the keymap;
instead they should process the files with their own independent state
(in the *Info structs) as much as possible, and only at the end should
they be copied (i.e. commited) to the keymap. If the compilation fails,
it leaves no by-products. It's also just good form.
This was seemingly the original author's intention, but I suppose he cut
a few corners (mostly with the handling of virtual modifiers, which are
threaded through types -> compat -> symbols).
This commit is the first step and may look artificial; however the
'keymap' field will be removed shortly.
Signed-off-by: Ran Benita <ran234@gmail.com>
The current calculation is in short:
entry ? (entry->mask & ~entry->preserve) : 0
This changes it be
type->mask & ~(entry ? entry->preserve : 0)
This is what Xlib does. While less intuitive, it is actually more
correct, if you follow this deduction:
- The key group's type->mask defines which modifiers the key even cares
about. The others are completely irrelevant (and in fact they are
masked out from all sided in the level calculation). Example: NumLock
for an alphabetic key.
- The type->mask, the mods which are not masked out, are *all* relevant
(and in fact in the level calculation they must match *exactly* to the
state). These mods affect which level is chosen for the key, whether
they are active or not.
- Because the type->mask mods are all relevant, they must be considered
as consumed by the calculation *even if they are not active*.
Therefore we use type->mask instead of entry->mask.
The second change is what happens when no entry is found: return 0 or
just take preserve to be 0? Let's consider an example, the basic type
type "ALPHABETIC" {
modifiers = Shift+Lock;
map[Shift] = Level2;
map[Lock] = Level2;
level_name[Level1] = "Base";
level_name[Level2] = "Caps";
};
Suppose Shift+Lock is active - it doesn't match any entry, thus it gets
to level 0. The first interpretation would take them both to be
unconsumed, the second (new one) would take them both to be consumed.
This seems much better: Caps is active, and Shift disables it, they both
do something.
This change also fixes a pretty lousy bug (since 0.3.2), where Shift
appears to apparently *not* disable Caps. What actually happens is that
Caps is not consumed (see above) but active, thus the implicit
capitalization in get_one_sym() kicks in and capitalizes it anyway.
Reported-by: Davinder Pal Singh Bhamra
Signed-off-by: Ran Benita <ran234@gmail.com>
These functions generally have the same effect as
xkb_state_key_get_syms() + xkb_keysym_to_utf{8,32}().
So why add them?
- They provide a slightly nicer interface, especially if the string is
the only interest.
- It makes the handling of multiple-keysyms-to-utf8 transparent. For the
designated use-case of multiple-keysyms (unicode combining
characters), this is a must. We also validate the UTF-8, which the
user might not otherwise do.
- We will need to apply some transformation on the resulting string
which depend on the xkb_state. This is not possible with the
xkb_keysym_* functions.
With these functions, the existing xkb_keysym_to_utf{8,32}() are not
expected to be used by a typical user; they are "raw" functions.
Signed-off-by: Ran Benita <ran234@gmail.com>
We need to validate some UTF-8, so this adds an is_valid_utf8()
function, which is probably pretty slow but should work correctly.
Signed-off-by: Ran Benita <ran234@gmail.com>
It is valid for a keymap to not have key aliases, group names and
various other things. But the current test requires all of them to be
present in the reply, which causes us the fail on such keymaps (as the
XQuartz one).
Instead, require only what we really need. The virtual-mods names may
not be strictly required, but it seems safer to leave it in for now.
https://bugs.freedesktop.org/show_bug.cgi?id=75798
Reported-by: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Nothing bad can come out of it, but for some reason this error didn't
return early (inherited from xkbcomp).
Also promote the log message to an error, as it clearly is.
Signed-off-by: Ran Benita <ran234@gmail.com>
This retrieves the mask of consumed modifiers for a given key and state,
which is helpful for toolkits without having them to do it one modifier
at a time, or pass in 0xFFFFFFFF to xkb_state_remove_consumed_mods to
"reverse-engineer" the consumed mods.
This is a little shorter and follows easier from the spec flag
description table.
Also a few were too permissive (like allowing LatchToLock in SetMods).
Signed-off-by: Ran Benita <ran234@gmail.com>
This used to *unset* a flag called "SwitchApplication"; we changed the
flag to "same" but forgot to switch the cases.
Signed-off-by: Ran Benita <ran234@gmail.com>
It's the same as no flags, so might as well not print it.
(In fact it is slightly harmful, because it actively *clears* the affect
flags, which might have been set in some other manner. But in practice
this cannot happen).
Signed-off-by: Ran Benita <ran234@gmail.com>
Only the "data" field can have them, and every other field needs to
error out if it appears. But some didn't check.
Signed-off-by: Ran Benita <ran234@gmail.com>
Support for setting this field was missing from the LockMods and
LockControls actions.
Based on a xkbcomp patch by Andreas Wettstein.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead of using those t1 t2 variables, pass the final destinations
directly (while making sure they are not modified in case of error).
This also ensures the types are right, e.g. in CheckGroupField it should
be int32_t, not xkb_layout_index_t (and indeed it takes a negation!).
Signed-off-by: Ran Benita <ran234@gmail.com>
This brings back the functionality that was removed in
b9c87eb710. Though it is not used in
xkeyboard-config, from our current perspective it can be quite useful to
be able to set the mappings directly, thus sidestepping the ugly and
legacy-ridden modifier_map statement.
Here's an example of how to get rid of modifier_map statements (though
that would break core-X11 applications, since they must have the
mappings through keysyms):
virtual_modifiers NumLock = Mod2;
virtual_modifiers Alt = Mod1;
// Would be nice to map these to Alt, but that would be
// incompatible with xkbcomp and somewhat complicated
virtual_modifiers LAlt = Mod1;
virtual_modifiers RAlt = Mod1;
virtual_modifiers LevelThree = Mod5;
virtual_modifiers RControl = Control;
virtual_modifiers LControl = Control;
virtual_modifiers Super = Mod4;
virtual_modifiers Meta = Mod1;
virtual_modifiers Hyper = Mod4;
virtual_modifiers AltGr = Mod5;
virtual_modifiers LShift = Shift;
virtual_modifiers RShift = Shift;
Signed-off-by: Ran Benita <ran234@gmail.com>
First, make the rules and xkb scanners/parsers use the same logging
functions instead of rolling their own.
Second, use the gcc ##__VA_ARGS extension instead of dealing with C99
stupidity. I hope all relevant compilers support it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Previously the early-exit codepath might have left some values
unexpanded, and we'd go looking for e.g "%l%(v)".
Signed-off-by: Ran Benita <ran234@gmail.com>
We want all the default logic in a test, so encapsulate it in this
function, and make all the get_default_* functions static.
Signed-off-by: Ran Benita <ran234@gmail.com>
There can be multiple include paths. But it's nicer in any case.
This also makes scanner_error actually use log_err instead of log_warn -
oops.
Signed-off-by: Ran Benita <ran234@gmail.com>
It returns XKB_LAYOUT_INVALID in case num_groups == 0. So we shouldn't
just save it in the state.
Note, though, that this condition is generally impossible.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead of thinking about signed <-> unsigned an whatnot.
bsearch() is inline in glibc, so gcc optimizes this away anyway.
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
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 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>
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>
Ran Benita
Jasper St. Pierre