The server used to have to go and do this on our own, but we can do
better than that: after we've compiled the keymap, go through and bind
virtual modifiers to everything that needs it.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
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.
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.
Daniel Stone
Ran Benita
Kristian Høgsberg
Dan Nicholson