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>
This is a nice intro to the documentation, and also preferably gently
pushes users to the "proper way" of using the library, which can be
confusing.
See also: http://fooishbar.org/tell-me-about/xkbcommon-intro/
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>
Especially a mention of the XKB_DEFAULT_* envvars was missing.
Reported-by: Paeglis Gatis <Gatis.Paeglis@digia.com> (thanks!)
Signed-off-by: Ran Benita <ran234@gmail.com>
There are valid reasons to use the other keymap-creation functions, if
one needs them. On the other hand, if one is supposed to use RMLVO, it
is more or less the only choice, so the comment is not needed in this
case as well.
Signed-off-by: Ran Benita <ran234@gmail.com>
- Specify in detail which parts of the events we care about. In theory
the X server should not bother us with things we didn't ask for. In
practice it still does, but oh well.
- Use the _aux version of select_events. This is the correct one to use,
the non-aux version is useless.
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>
It only works if 'bison' or 'byacc' are provided, but sometimes byacc
is installed as plain 'yacc'. The check fails for that.
I broke this in bdd8c11, restore Daniel's retrospectively clever check.
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>
Ran Benita
Jasper St. Pierre