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>
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>
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.
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.
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.
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.
Daniel Stone
Dan Nicholson