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>
Currently, we have one ExprDef type, which contains a tagged union with
the value of all expression types. Turns out, this union is quite
wasteful memory-wise. Instead, create separate types for all expressions
(e.g ExprBinary, ExprInteger) which embed the common fields
(ExprCommon), and malloc them per their size; ExprDef then becomes a
union of all these types, but is just used as a generic pointer.
[Instead of making ExprDef a union, another option is to use
ExprCommon as the generic pointer type and then do up-castings, like we
do with ParseCommon. But this makes the code much uglier.]
The diff is mostly straightforward mechanical adaptations. It could have
been much smaller with the help of C11 anonymous structs (which were
previously a gnu extension). This will have saved all of the 'op' ->
'expr->op', etc changes. But if we can be a bit more portable for a
little effort, we should.
Before (./test/rulescomp, x86 32 bit, -O2):
==12974== total heap usage: 145,217 allocs, 145,217 frees, 10,476,238 bytes allocated
After:
==11145== total heap usage: 145,217 allocs, 145,217 frees, 8,270,358 bytes allocated
Signed-off-by: Ran Benita <ran234@gmail.com>
Instead of having the parser passing strings to the AST, and
symbols/compat etc. resolving them themselves. This simplifies the code
a bit, and makes it possible to print where exactly in the file the bad
keysym originates from.
The previous lazy approach had an advantage of not needlessly resolving
keysyms from unrelated maps. However, I think reporting these errors in
*any* map is better, and the parser is also a bit smarter then old
xkbcomp and doesn't parse many useless maps. So there's no discernible
speed/memory difference with this change.
Signed-off-by: Ran Benita <ran234@gmail.com>
Fixes build failure with Solaris Studio compilers:
"src/xkbcomp/ast-build.c", line 492: identifier redeclared: XkbFileCreate
current : function(..., enum xkb_map_flags)
previous: function(..., unsigned int) : "src/xkbcomp/ast-build.h", line 98
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
ctype.h is locale-dependent, so using it in our scanners is not optimal.
Let's be deterministic with our own simple functions.
Signed-off-by: Ran Benita <ran234@gmail.com>
I wanted to avoid the strlen, but we'd better keep the scanner a bit
less surprising and encourage people to use xkb_keymap_new_from_buffer()
instead of they do in fact have access to the size.
Signed-off-by: Ran Benita <ran234@gmail.com>
Improve safety with parenthesis, make the matcher macros use the scanner
ones, and make the 1 variant use %s instead of embedding the msg; this
way the compiler can reuse the string in the binary.
Signed-off-by: Ran Benita <ran234@gmail.com>
Change variable names to avoid the name clash. The warning seen is
src/keysym-utf.c: In function 'bin_search':
src/keysym-utf.c:841: warning: declaration of 'min' shadows a global declaration
src/utils.h:109: warning: shadowed declaration is here
src/keysym-utf.c:842: warning: declaration of 'max' shadows a global declaration
src/utils.h:115: warning: shadowed declaration is here
Signed-off-by: Siddharth Heroor <heroor@ti.com>
'tmp' is stack allocated so tmp->merge is used uninitialized by
AddModMapEntry(). The value doesn't matter much, but it used to
make some modmap merging decision (which doesn't have many
conflicts usually).
Bug inherited from xkbcomp.
Signed-off-by: Ran Benita <ran234@gmail.com>
We now also work with byacc (version tested: 20130925) which some people
prefer, perhaps due to its license (public domain) or performance
(haven't compared).
When using byacc, currently the following warning comes up:
src/xkbcomp/parser.c:954:14: warning: declaration shadows a variable in the global scope [-Wshadow]
YYSTYPE yylval;
^
src/xkbcomp/parser.c:37:20: note: expanded from macro 'yylval'
#define yylval _xkbcommon_lval
^
./src/xkbcomp/parser.h:96:16: note: previous declaration is here
extern YYSTYPE _xkbcommon_lval;
This is due to a bug in byacc - it shouldn't output that extern line in
%pure-parser mode. So the warning stays.
Signed-off-by: Ran Benita <ran234@gmail.com>
Unlike bison, byacc outputs its own parser code *after* our own parser.y
code, which includes the #undef. So this fix is needed for the 'scanner'
-> 'param->scanner' translation to work in the parser.c code generated
by byacc.
Signed-off-by: Ran Benita <ran234@gmail.com>
byacc doesn't support this feature.
We print the line/col of the last scanned token instead. This is slightly
less in case of *parser* errors (not syntax errors), but I couldn't make
it point to another line, and this are pretty cryptic anyways. So it's
good enough. Also might be a bit faster, but haven't checked.
Signed-off-by: Ran Benita <ran234@gmail.com>
Even though the %name-prefix is more sensible, byacc doesn't support it,
but both bison and byacc support the -p argument.
Signed-off-by: Ran Benita <ran234@gmail.com>
Both bison and byacc support this syntax. Bison manpage says something
about this giving more or less options, but we don't care.
Signed-off-by: Ran Benita <ran234@gmail.com>
The xkbproto spec says:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Interpreting_the_Lock_Modifier
If the Lock modifier is not consumed by the symbol lookup process,
routines that determine the symbol and string that correspond to
an event should capitalize the result.
This was not an issue until now, because most xkeyboard-config keymaps
do not utilize this "feature", and specify the keysyms for the Lock
modifier explicitly instead. However, some keymaps do depend on it, e.g.
ch(fr) for eacute and others.
The spec goes on to describe two options for doing this transformation:
locale-sensitive and locale-insensitive. We opt for the latter; it is
less desirable but we don't want *that* headache.
Also, only xkb_state_key_get_one_sym() is changed;
xkb_state_key_get_syms() is left as-is, and always reports the
untransformed keysyms. This is for the following reasons:
- The API doesn't allow it, since we return a const pointer directly to
the keymap keysyms table and we can't transform that.
- The transformation doesn't make sense for multiple-keysyms.
- It can be useful for an application to get the "raw" keysyms if it
wants to (e.g. maybe it wants to do the transformation itself).
Finally, note that xkb_state_mod_index_is_consumed() does *not*
report Lock as consumed even if it was used in the transformation. This
is what Xlib does.
This definitely doesn't fall under the "hard to misuse" API rule but
it's the best we can do.
https://bugs.freedesktop.org/show_bug.cgi?id=67167
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
This is too strict, and causes symbols/cz to fail parsing. Instead, just
emit a warning (not shown by default):
xkbcommon: WARNING: cz:75:19: unknown escape sequence in string literal
https://bugs.freedesktop.org/show_bug.cgi?id=68056
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
src/xkbcomp/scanner.c:158:17: warning: comparison of constant -1 with expression of type 'enum yytokentype' is always true
[-Wtautological-constant-out-of-range-compare]
if (tok != -1) return tok;
~~~ ^ ~~
Signed-off-by: Ran Benita <ran234@gmail.com>
Some keymaps actually have this, like the quartz.xkb which is tested. We
need to support these.
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
We should handle empty xkb_keycode and xkb_symbol sections, since
xkbcomp handles them, and apparently XQuartz uses it. There are also
files for it in xkeyboard-config (rules=base model=empty layout=empty,
which translate to keycodes/empty and symbols/empty).
https://bugs.freedesktop.org/show_bug.cgi?id=67654
Reported-By: Gatis Paeglis <gatis.paeglis@digia.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
For keycodes, groups, levels, etc, which are unsigned. The really proper
inttypes.h ones seem a bit much though.
Signed-off-by: Ran Benita <ran234@gmail.com>
"Error: " is not very informative when intermingled with other logs. The
format that seems most suitable is:
"xkbcommon: ERROR: %s"
Signed-off-by: Ran Benita <ran234@gmail.com>
The file src/xkbcomp/action.c already doesn't handle this action type
and fails if it encounters it. So lets not pretend to do something with
it, and ignore it rather than failing.
If we/someone wants this we can consider implementing it.
Signed-off-by: Ran Benita <ran234@gmail.com>
PATH_MAX is optional in POSIX, so avoid its unconditional usage
allocating and freeing buffers as needed.
To avoid too many malloc/free in the for loop in FindFileInXkbPath,
a buffer is grown according to the size needed at each iteration.
xkb_atom_intern now takes a len parameter. Turns out though that almost
all of our xkb_atom_intern calls are called on string literals, the
length of which we know statically. So we add a macro to micro-optimize
this case.
Signed-off-by: Ran Benita <ran234@gmail.com>
This ensures the names are escaped before having any interaction with
the user.
This was caught by noticing dump(compile(dump())) != dump. Since that's
a nice test we add it to stringcomp.
https://bugs.freedesktop.org/show_bug.cgi?id=67032
Reported-By: Auke Booij
Signed-off-by: Ran Benita <ran234@gmail.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
"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>
Ran Benita
Jasper St. Pierre
Alan Coopersmith
Siddharth Heroor
Pino Toscano
Daniel Stone
Matthias Clasen
David Herrmann