They're no longer needed since we don't expose any atoms in the
published API anymore. As a result, we don't need to support external
atom implementations either. Result!
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ironically, the test for named.xkb included a call that relied on the
default keymap, without the file naming an explicit default. Go figure.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
On many layouts, the following error appears:
Internal error: Could not resolve keysym 10005b0
(Which is like the trademark of libxkbcommon now, and makes
unicode-heavy symbol files pretty useless).
This occurs when a keysym string (in this case, 10005b0) is passed to
xkb_string_to_keysym, but cannot be resolved.
This in turn happens because the parser passes on hexadecimal keysym
strings without the leading "0x", thus leaving the resolving function
without a way to disambiguate it as a number.
Therefore, make sure to pass on the "0x". The file symbols.c in xkbcomp
project does the same; it probably got lost in translation.
Signed-off-by: Ran Benita <ran234@gmail.com>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
This rules file won't be loaded more than once in most cases anyway, so
just load it again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
This needlessly occupies memory for the lifetime of the library, and
does not make a noticeable difference otherwise.
Instead, just parse the same file again when it happens.
Signed-off-by: Ran Benita <ran234@gmail.com>
The yacc implementation can generate all the necessary token
definitions itself; there is no need to maintain a hand written
file for that.
Signed-off-by: Ran Benita <ran234@gmail.com>
This integrates two commits from libX11:
ebd6ef0a4db0ddef0ae17ad14571518ccdeea5ba
XStringToKeysym: Special case for XF86 keysyms
Some XFree86 keysyms were in XKeysymDB as XF86_foo, despite really being
XF86foo. So, if we get to the bottom of XStringToKeysym and haven't
found our XF86_foo, try it again as XF86foo.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
00175397480b76d32bf82b0c7c94c91a2a95954e
makekeys: Scan vendor keysyms as well as core
Since we can't really live without vendor keysyms, scan them all in to
generate ks_tables.h, rather than only doing the core ones, and leaving
the vendor syms to be manually synchronised with XKeysymDB.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Notice that the xkey.sh test is changed to match libX11 behavior, i.e.
XKeysymToString(0x1008FE20) -> "XF86Ungrab" as opposed to "XF86_Ungrab".
Signed-off-by: Ran Benita <ran234@gmail.com>
This matches commit 78a894231ae8ec4959007b6d9b8d2a15d6333a1e from
libX11:
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
This matches commit 24283d40b1e4314c6647dda49d2a159833341a8b from
libX11:
Since makekeys is built using build environment's compiler and
runs natively, we have to make sure that the size of the
Signature type is the same on both the native environment
and the target, otherwise we get mismatches upon running X,
and some LSB test failures (xts5).
Use an unsigned 32-bit integer on all platforms.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Ran Benita <ran234@gmail.com>
Daniel Stone
Ran Benita