Comment 43 for bug 251443

I assume it's relatively well known, but here's where I landed.

My plan to fix this, was to bypass XKM support completely, by integrating the parser into the server. Currently the server forks xkbcomp to build a particular keymap, xkbcomp produces (lossy) XKM files, and then the server consumes XKM. xkbcommon was supposed to fix this (hence the name), but the problem is that the server wants very different things from xkbcommon than everyone else. Specifically, it wants to be able to mutate arbitrary parts of the keymap after construction, which is very messy. Ultimately we just kept xkbcommon for everyone _but_ the X server, with a much smaller API.

The best thing to do for anyone who wants to pick this up is probably to look at importing xkbcommon circa https://github.com/xkbcommon/libxkbcommon/commit/ed18e65eacdabfeaeafee7c369891312af99c82d into the X server, in place of the xkbcomp entrypoint in xkb/ddxLoad.c. That particular commit is probably the most tractable balance between an actual functional xkbcommon without memory leaks, and one which hasn't changed the server-facing API and internals _too_ far away from what the server needs.