It's a name of a function in scanner-utils.h and also of some
parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=79898
Reported-by: Bryce Harrington <b.harrington@samsung.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
If count % SIZE == 0 we did a useless iteration where start==stop. It's
harmless but strange, so don't do that.
Signed-off-by: Ran Benita <ran234@gmail.com>
matcher_match() builds up the kccgst's, and we steal the memory on
success. But on error we didn't free it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Two problems:
- `j` can be >= `SIZE`, and needs to be wrapped like in the rest of the
code.
- `cookies[j % SIZE]` is not initialized if there's no atom in `from[j]`.
The is manifested when:
- We've already gone through one batch (>= 128 atoms) (in fact this
cannot happen in call to `adopt_atoms` in the current code).
- An XCB request failed in the middle of a batch.
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead just statically allocate the mods array (of size MAX_MOD_SIZE =
32). The limit is not going anywhere, and static allocations are nicer
(nicer code, no OOM, etc.). It's also small and dense enough.
Signed-off-by: Ran Benita <ran234@gmail.com>
The keymap is not removed entirely from the Info (just constified),
since it is still needed in AddKeySymbols() for looking up aliases. This
dependency will be removed in the future.
Signed-off-by: Ran Benita <ran234@gmail.com>
This is the only place where the modifier information is modified. We
will make it local to a given XKB file (after which it will be merged
into the keymap). Currently it changes the keymap directly, which
sidesteps the abstraction and leaves side-effects even if the XkbFile's
compilation fails.
Signed-off-by: Ran Benita <ran234@gmail.com>
The modifier printing functions only need the modifier information, they
don't care about keys or leds, etc.
Signed-off-by: Ran Benita <ran234@gmail.com>
The only thing that the compilation phase needs the keymap for currently
is for access to the modifier information (it also modifies it in
place!). We want to only pass along the neccessary information, to make
it more tractable and testable, so instead of passing the entire keymap
we add a new 'mod_set' object and pass a (const) reference to that.
The new object is just the old array of 'struct xkb_mod'.
Signed-off-by: Ran Benita <ran234@gmail.com>
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 documentation should be clear about what is happening, even if it's
rather unlikely anyone will really dig into the details.
Signed-off-by: Ran Benita <ran234@gmail.com>
And also add release dates to the NEWS.
We're adding API freely, so this can make life easier for anyone who
wants to stay compatible with an older version.
Signed-off-by: Ran Benita <ran234@gmail.com>
This CI service https://travis-ci.org/ builds the project in several
configurations, runs the tests, and if something fails it sends an email.
Testing on some other systems is always good, and there don't seem to
be any drawbacks to this, so why not.
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>
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>
Ran Benita