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>
filecomp would fail because it couldn't find the input files, after
compilation failed due to missing includes.
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.
Daniel Stone
Dan Nicholson