Age | Commit message (Collapse) | Author | Files | Lines |
|
Add three new pieces of API:
- xkb_keymap_min_keycode does what it says on the tin
- xkb_keymap_max_keycode likewise
- xkb_keymap_key_for_each calls the provided function once for every
valid key in the keymap
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
If the keycode range is smaller than 8 → 255, artifically widen it when
dumping the keymap as not to displease X.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
The scanner is very similar in structure to the one in xkbcomp/rules.c.
It avoids copying and has nicer error reporting.
It uses gperf to generate a hashtable for the keywords, which gives a
nice speed boost (compared to the naive strcasecmp method at least). But
since there's hardly a reason to regenerate it every time and require
people to install gperf, the output (keywords.c) is added here as well.
Here are some stats from test/rulescomp:
Before:
compiled 1000 keymaps in 4.052939625s
==22063== total heap usage: 101,101 allocs, 101,101 frees, 11,840,834 bytes allocated
After:
compiled 1000 keymaps in 3.519665434s
==26505== total heap usage: 99,945 allocs, 99,945 frees, 7,033,608 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
This wraps the current mmap call and adds a fallback implementation for
systems which do not have mmap (e.g. mingw).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
We want to share the same functions for another scanner.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
The current API doesn't allow the caller to create keymaps from mmap()'ed
files. The problem is, xkb_keymap_new_from_string() requires a terminating
0 byte. However, there is no way to guarantee that when using mmap() so a
user currently has to copy the whole file just to get the terminating zero
byte (assuming they cannot use xkb_keymap_new_from_file()).
This adds a new entry xkb_keymap_new_from_buffer() which takes a memory
location and the buffer size in bytes.
Internally, we depend on yy_scan_{string,byte}() helpers. According to
flex documentation these already copy the input string because they are
wrappers around yy_scan_buffer().
yy_scan_buffer() on the other hand has some insane requirements. The
buffer must be writeable and the last two bytes must be ASCII-NUL. But the
buffer may contain other 0 bytes just fine.
Because we don't want these constraints in our public API,
xkb_keymap_new_from_buffer() needs to create a copy of the input memory.
But it then calls yy_scan_buffer() directly. Hence, we have the same
number of buffer-copies as with *_from_string() but without the
terminating 0 requirement.
The explicit yy_scan_buffer() call is preferred over yy_scan_byte() so the
buffer-copy operation is not hidden somewhere in flex.
Maybe some day we no longer depend on flex and can have a zero-copy API. A
user could mmap() a file and it would get parsed right from this buffer.
But until then, we shouldn't expose this limitation in the API but instead
provide an API that some day can work with zero-copy.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
[ran: rebased on top of my branch]
Conflicts:
Makefile.am
src/xkbcomp/xkbcomp.c
|
|
src/xkbcomp/keymap.c:127:12: error: 'found' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Not really, but why not.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
You can now set default values in the environment, as well as a context
option to ignore the environment, e.g. for tests.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
|
|
This can't happen, but better safe than sorry. The optimizations were
noticeable but negligible.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
src/xkbcomp/rules.c:620:36: error: 'idx' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Can't happen but no harm done.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
That's a better name and fits more nicely.
Also change type->map to type->entries.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
(I really dislike this one for some reason..)
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
It is not used anymore.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
See previous commits.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
See previous commit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
See previous commit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Not used.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
We don't need the struct any more, it only contains one field now.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
The file_id thing is used to identify the XkbFile some statement
originally came from. This is needed to avoid spurious warnings; for
example, if you write the same alias twice in a file, that's redundant,
and you'd want a warning about it. However if intentionally override it
from another file, that's fine, and you shouldn't get a warning. So by
comparing the file_id's the needed log verbosity is changed.
However, the file_id mechanism is really not needed, because we already
have that info! Each KeyNamesInfo corresponds to one XkbFile, so if the
conflict occurred while handling that one file -> same_file = true, and
if it occurs while merging two Info's -> same_file = false.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
With a little tweak to the copy-to-keymap routine in keycodes.c we can
use a normal array.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
If 'into' in empty we can just steal 'from'.
Also move the alias-merging into the big function, it's nicer this way.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
To get a key by name and resolve an alias - this makes sense for
everyone.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
This is already checked when adding a new alias and merging aliases, so
it can never happen when we get to copying to the keymap.
Also the log verbosity decision there is quite useless, we should just
warn always and be done with it. So we can remove the file_id from
AliasInfo, and collapse the alias functions together.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
The 'merge_mode' situation is quite messy, and we've introduced a
regression compared to original xkbcomp: when handling a composite
include statement, such as
replace "foo(bar)+baz(bla)|doo:dee"
and merging the entire resulting *Info back into the including *Info,
we actually use the merge mode that is set by the last part (here it is
"augment" because of the '|'), when we should be using the one set for
the whole statement (here "replace").
We also take the opportunity to clean up a bit.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
clang doesn't like the use of typeof with out default flags, so just
don't use it.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Make it a bit easier to experiment with other formats.
Add a struct xkb_keymap_format_operations, which currently contains the
keymap compilation and _get_as_string functions. Each format can
implement whatever it wants from these.
The current public entry points become wrappers which do some error
reporting, allocation etc., and calling to the specific format. The
wrappers are all moved to src/keymap.c, so there are no XKB_EXPORT's
under src/xkbcomp/ anymore.
The only format available now is normal text_v1.
This is all not very KISS, and adds some indirection, but it is helpful
and somewhat cleaner.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
The snprintf trick that LedStateText and ControlMaskText do cannot work,
because you can't use the buffer as an argument to write to itself!
(posix at least has 'restrict' there). So those two actually never
worked for more than one value (i.e. with a +).
Fix that, and do the same cleanup to ModMaskText. Now we have 3
functions which look exactly the same, oh well.
Also increase the context text buffer size, you never know.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
It's for geometry only.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
This should be fixed properly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
We don't use it anymore and it's easy to add back if needed.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
xkbcomp prints them too, but that's just annoying. Also xkb_keycodes
doesn't have it already.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
xkbcomp doesn't indent there, so it's easier to diff.
Also saves some horizontal space which is sorely needed when looking at
these files (especially the xkb_symbols).
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
And try to not repeat ourselves.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
"Value stored to 'stmt' is never read"
"Value stored to 'grp_to_use' is never read"
And change 'grp' to 'group' if we're here.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Use the same format as XKeysymToString.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
They don't need the keymap, only the context.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Also s/dflt/default.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
A bit easier at a glance. Also, vowels are cool, so just say 'default'.
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Signed-off-by: Ran Benita <ran234@gmail.com>
|
|
Bug introduced in 2a5b0c9dc1ad1488ecc6b139fd70e464eb687da6, was causing
some keys to be merged incorrectly.
Signed-off-by: Ran Benita <ran234@gmail.com>
|