Thanks to autotools happily building stale generated sources, I hadn't
actually ever built my xkbparse.y changes. Fix that so it not only
compiles, but works. This seems to parse long keycodes correctly,
although I very much would not recommend testing this by declaring
0x1fffffff as your highest keycode.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some error paths don't set info->xkb correctly, so just do like most
utility functions and pass the xkb_desc explicitly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
And use it consistently everywhere, including with a special long-safe
internal keycode type, to ease the transition to large keycodes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For some reason, lex decided to reduce a strcpy into an assignment,
leading to entirely justified valgrind warnings about invalid reads,
when scanFile was set to a string which may have only ever lived on the
stack of a now-exited function.
Make it a strdup() instead.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Some routes through HandleGeometryVar do not set a return value. Set a default
value for the return variable to avoid returning an uninitialised value.
Which just calls XkbcFreeKeyboard with the only arguments you'd ever
pass it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Avoids assigning the global pointer to a value that may only have a stack
lifetime:
Fixes valgrind warnings such as:
==24795== Invalid read of size 1
==24795== at 0x4A06E9A: strcpy (mc_replace_strmem.c:311)
==24795== by 0x4E54D68: ProcessIncludeFile (misc.c:73)
==24795== by 0x4E59726: HandleIncludeSymbols.constprop.3 (symbols.c:829)
==24795== by 0x4E59D8E: HandleSymbolsFile (symbols.c:1673)
==24795== by 0x4E5A068: CompileSymbols (symbols.c:2211)
==24795== by 0x4E51A61: CompileKeymap (keymap.c:155)
==24795== by 0x4E5B410: xkb_compile_keymap_from_components (xkbcomp.c:236)
==24795== by 0x4E5B587: xkb_compile_keymap_from_rules (xkbcomp.c:161)
==24795== by 0x405ED2: display_create (window.c:2007)
==24795== by 0x403732: main (desktop-shell.c:320)
==24795== Address 0x7fefff0a0 is just below the stack ptr. To suppress, use:
--workaround-gcc296-bugs=yes
==24795==
==24795== Source and destination overlap in strcpy(0x7fefff430, 0x7fefff430)
==24795== at 0x4A06F3D: strcpy (mc_replace_strmem.c:311)
==24795== by 0x4E54D68: ProcessIncludeFile (misc.c:73)
==24795== by 0x4E59726: HandleIncludeSymbols.constprop.3 (symbols.c:829)
==24795== by 0x4E59D8E: HandleSymbolsFile (symbols.c:1673)
==24795== by 0x4E5A068: CompileSymbols (symbols.c:2211)
==24795== by 0x4E51A61: CompileKeymap (keymap.c:155)
==24795== by 0x4E5B410: xkb_compile_keymap_from_components (xkbcomp.c:236)
==24795== by 0x4E5B587: xkb_compile_keymap_from_rules (xkbcomp.c:161)
==24795== by 0x405ED2: display_create (window.c:2007)
==24795== by 0x403732: main (desktop-shell.c:320)
Those warnings disappear accordingly:
| CC parseutils.lo
| parseutils.c:742: warning: no previous prototype for ‘CheckDefaultMap’
| CC xkbscan.lo
| xkbscan.l: In function ‘XKBParseString’:
| xkbscan.l:220: warning: implicit declaration of function ‘CheckDefaultMap’
| xkbscan.l:220: warning: nested extern declaration of ‘CheckDefaultMap’
Reviewed-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
There's no need for this xlib include:
| YACC xkbparse.c
| CC xkbparse.lo
| xkbparse.y:98:22: error: X11/Xlib.h: No such file or directory
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
This would cover the scenario where these headers file are updated,
for example, a new version is installed. Running 'make' again
on libxkbcommon should rebuild ks_tables.h.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
This program is a utility to generated a header file.
The header file it generates should not be located in the
directory where this utility program is compiled.
Move the /makekeys dir as a sibling of /src.
This reduces the number of bi-directional relationships
between directories.
Make corresponding makefiles simplifications.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
These automake variables are not currently used.
The variable KS_HEADERS is not required anymore.
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
BUILT_SOURCES and MAINTAINERCLEAN are not needed for lex and yacc
Note that xkbscan was missing on those lines.
Automake generates all the rules to handle building, distribution
and cleaning.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Fixes automake warning.
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
xkbscan.l: In function 'setScanState':
xkbscan.l:201:1: warning: control reaches end of non-void function
I: Program returns random data in a function
E: libxkbcommon no-return-in-nonvoid-function xkbscan.l:201
Change return type of setScanState to void, since a return value is
never used by its callers.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Use -no-undefined to assure libtool that the libxkbcommon library has
no unresolved symbols at link time, so that libtool will build a shared
library on platforms require that all symbols are resolved when the
library is linked.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Keep the parsed form of the last-used rules file around, and reuse that
if we get asked for the same ruleset. If not, bin it and cache the
other one.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Use CARD32 instead of Atom/KeySym/et al to avoid type size confusion
between server and non-server code; relatedly, move the geometry headers
in from kbproto, so every non-simple type (i.e. structs containing
nothing more than basic types) is now copied into xkbcommon.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Allow people to plug in an external atom database (e.g. the X server's),
so we don't have to migrate our own atoms over later. We are a bit
over-keen on atoms at the moment, so it does pollute the atom database a
bit though.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
On 64-bit architectures, XID varies in size between the server (always
32 bits), and non-server (always unsigned long) for some inexplicable
reason. Use CARD32 instead to avoid this horrible trap.
This involves dragging in XkbClientMapRec so we don't get stuck in the
KeySym trap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Use Xkbc* for all our actions that we intend to keep around, and Xkb*
for deprecated ones we can hopefully get rid of, at least internally.
While we're at it, make vmods be a uint32_t.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
So, it turns out that if you're parsing a fairly large amount of data,
using getc() to get all the input rather than, say, read(), is some kind
of remarkably daft and unperformant idea.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Instead of calling XStringToKeysym on every keysym we parse, store it as
a string until we need to store it in an actual keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
XkbAtomGetString() returns a freshly-allocated string, whereas
XkbAtomText() returns the same in a temporary buffer. XkbAtomText used
to call XkbAtomGetString() and then free the result, which seems quite
spectacularly pointless when you think about it. Shuffle the atom code
around so we don't have to allocate for XkbAtomText().
This changes semantics slightly wrt non-printable characters, but I
haven't been able to see any effect so far. And it may well be ever so
slightly quicker.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This will let us implement XkbAtomGetString on top of XkbAtomText,
instead of having the latter get a duplicated string, dump it into a
temporary buffer, and subsequently free it (sigh).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
XkbcInternAtom(XkbcAtomGetString(atom)) has to be the most spectacularly
broken antipattern I've yet seen. Just compare the atoms directly.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Canonicalises two sets of components (new and old), e.g.:
new: +bar
old: foo
result: foo+bar
This is required as part of the spec, so clients can reuse part of the
device's old keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Ensure that Unicode string representations are accepted and turned into
numbers, as well as hexadecimal numbers in 0xabcd1234 form; unknown
keysyms are output as 0xabcd1234 in string form.
This also ensures that strings are never returned malloc()ed.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Add NoSymbol into the keysym table, so keysym <-> string conversion works for
that, too; also eliminate special-casing of VoidSymbol.
This will require special-casing in libX11 to preserve its API.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The listing code in xkbcomp had been setup to allocate a set of buffers
with file paths and then later parse through them to find which maps were
needed.
All the allocation (with the additional allocation for the components
list) was making it really slow, so this patch makes everything simpler
by just generating the components list as we walk the directory tree.
In xkbcomp, the listing code printed out the xkb files to stdout and the
caller would parse the output. Here, we can just generate a
XkbComponentListPtr and pass it back.
This should be a series of smaller commits, but there was no clean way to
do it since it's basically a complete rewrite except for the core map
matching logic.
A lot of code used for special printing modes in xkbcomp has been
shedded. Callers can massage the output as they please.
This reverts commit c4c9e36fbf. It turns
out that the listing code is used to support the X_kbListComponents
request (via XkbListComponents).
This will have to be refactored into some reasonable interface instead
of the current usage where the server reads xkbcomp stdout. Gross.
Instead of hardcoding the XKB base directory when searching for rules in
the xkbcomp code, we can extend the xkbpath API to cover rules and reuse
it. That will make it more convenient if it's ever exposed so people can
set their XKB search paths in a reasonable way.
We need to support generating a keyboard description from a keymap file
because there are just some cases where RMLVO or ktcsg is not enough.
The map choosing logic has been refactored into its own function and now
supports choosing a named or default keymap.
The noble intention was to expose all the new API and new generic types
in the split out kbproto headers through XKBcommon.h. It turns out that
would be a massive amount of work in the server. Someday, but first just
wedging in XkbCompileKeymap* would be good.
Most of the API is in new internal xkb*.h headers. In order to allow the
XKBcommon.h header to be used from the server, we can't pull in other
headers from kbproto since the server has its own copies. However, types
that are different (XkbDescRec, XkbAction) still have Xkbc equivalents
here, and I think they should be used in the server.
Some of the XkbAction types are defined differently in the server, so we
add those to XKBcommon.h and use them here like XkbcDescPtr. We'll have
to deal with the impedance mismatch on the client side later.
XkbcRF_GetComponents was returning an error but leaving the generated
components alone. This ensures that the broken XkbComponentNamesPtr is
freed and the error is passed up to the caller.
Instead of requiring the user to call XkbInitIncludePath() and
XkbAddDefaultDirectoriesToPath(), all the path entry points now implicitly
initialize the path. When initializing, the default directories are added
so it's useful.
This provides normal operation without exposing the xkbpath API. That
might happen later to allow apps to edit the XKB search path.
XkbcCompileKeymapFromRules can be used to generate a XkbDescPtr from XKB
rules instead of using components. The previous XkbcCompileKeymap has
been renamed to XkbcCompileKeymapFromComponents.
Copy over the Xkb_RF* rules parsing functions from xkbfile's maprules.c.
Eventually, this will be tied into xkbcomp's path searching utilities so
you don't need to supply a full path to the rules file. Also, it this
should eventually incorporate the server's RMLVOSet.
Finally, we can generate a XkbcDescPtr from a XkbComponentNamesPtr. This
involves turning the components into a parsed XKB file and then passing
it into the compiler. This first conversion needs more error handling.
xkbcomp was using Xlib's XConvertCase to check upper/lowercase. That's a
lot of code, so hopefully the xkbfile macros using _XkbKSCheckCase are
good enough. This also required that <X11/keysym.h> is included to get
all the XK_* definitions.
Added common variants of XkbComputeEffectiveMap, XkbInitCanonicalKeyTypes
and all their needed functions. A couple functions that were in alloc.c
moved to malloc.c to mirror the libX11 sources better.
Original code in
libX11/src/xkb/XKBMalloc.c
libX11/src/xkb/XKBMisc.c
libX11/src/xkb/XKB.c
This should cover all the usage in xkbcomp. The format arguments were
dropped except for the special case of XkbModMaskText, which needs to
write in XkbCFile format in HandleVModDef. This was just changed to a
Bool to avoid the need for the macros in XKBfile.h.
The function prefixes have been renamed to be unique from xkbfile.
The only real usage was in the frontend to generate a .xkm file. The
rest of the code just operated on the attached XkbDescPtr. Note that
here we've replaced the usage of the defined field in CompileKeymap with
the equivalent field in a XkbcDescPtr.
A copy of the xkbcomp sources (except the frontend) have been copied in
to provide a means to compile a XkbDescPtr. This definitely doesn't
build or do the right thing yet.
This avoids the BUILT_SOURCES weirdness and forcing the build into the
makekeys subdirectory. Added a new make variable KS_HEADERS that lists
all the keysym headers we're going to parse.
Some coding style nits were cleaned up. Additionally, most of the
functions have been collapsed from the libxkbfile version where there's
distinction with the Xlib atom functions when Display was set. Finally,
the InitAtoms function tests whether the table has already been created
by testing the pointer rather than using a static int.
Mostly tab-to-space conversion plus a few style nits. Dropped the
register keywords as I'm pretty sure modern compilers can be trusted to
do the right thing.
Following the kbproto convention, the headers will be named XKBcommon.h
and XKBcommonint.h. Furthermore, they'll be installed in X11/extensions
directory with the rest of the XKB headers.
Copies the code to initialize and destroy an XkbDescRec from libX11. The
original code is in
libX11/src/xkb/XKBAlloc.c
libX11/src/xkb/XKBGAlloc.c
libX11/src/xkb/XKBMAlloc.c
These are used throughout the XKB code, but are defined in XKBsrv.h,
which we'd like to avoid. Internal definitions for True/False have also
been added since they're in Xlib.h
Mostly tab-to-space conversion plus a few style nits. Dropped the
register keywords as I'm pretty sure modern compilers can be trusted to
do the right thing.
Add the xkbcommon implementations of XKeysymToString and XStringToKeysym.
These symbols have the namespace prefix of Xkbc and are declared in
X11/XkbCommon.h.
The implementation is taken directly from Xlib, but does not include the
XKeysymDB parsing and hashing yet (if it ever will). A couple type
conversions were needed to keep from using Xlib.h. See original files:
libX11/src/KeysymStr.c
libX11/src/StrKeysym.c
The makekeys utility is used to generate the keysym hash tables during
the build. We try to detect a build machine native compiler so the
tables can be generated when cross compiling.
Daniel Stone
Rob Bradford
Pekka Paalanen
Cyril Brulebois
Kristian Høgsberg
Gaetan Nadon
Jan Engelhardt
Jon TURNEY
Adam Jackson
Dan Nicholson