(no) xkbcomp in server -- simpler solution?
daniel at fooishbar.org
Fri Jun 11 15:56:14 PDT 2010
On Sat, Jun 12, 2010 at 04:27:41AM +0700, Mikhail Gusarov wrote:
> Removal of xkbcomp fork/exec on servert startup is quite hard task --
> why not shift responsibility to client side: start server with some
> predefined keymap and make running xkbcomp the responsibility of session
> This change will make xkb data completely client-side (though given
> clients may connect from different hosts xkb introspection cannot be
> dropped from protocol).
> It should be easy enough (much easier than original task) to cover the
> common configuration with X server on the same host as desktop session
> and provide tool which reads xorg.conf and invokes xkbcomp.
I don't think it's that difficult a task. I have a rebased libxkbcommon
running at the moment which seems to work OK, which I'll post when I
finish fixing its myriad memory leaks and subsequently check I can send
XKB data is indeed a bit of a nightmare, but we need the client map,
vmodmap, types, etc to be able to reply to XGetKeyboardMapping and
XGetModifierMapping, compat to retain VT switching and zapping, etc,
etc. So at some point we still need a fair body of
Geometry can and will go, however, and my general inclination towards a
lot of the datasets it retains is to zap them and replace them with
static configurations. So I think it's possible to have a reasonably
small - or at least a great deal smaller than it is today - and lean XKB
layer, and it's definitely possible to have xkbcomp in server. So at
this point, the main problem as I see it is that xkbcomp is beyond
We pretty much need to be able to merge XkbDescRecs anyway, so at
that point, we've got the hard parts of xkbcomp sorted, and it's just a
matter of parsing plain text into something that looks like an
XkbDescRec. Which, when XkbDescRec is a fair bit smaller, shouldn't be
a herculean task.
Most of the problem with xkbcomp is that it's a summer intern's first
parser (no, really), and as I've never written a parser before, me
rewriting it would probably result in a lot of the same mistakes. So,
anyone who's done this before is more than welcome to step up and help
fix xkbcomp. But I think abrogating all responsibility for keyboard
data in the server is a mistake, for the same reason that config/dbus.c
was a mistake; it turns out that while 'let the clients deal with it' is
an attractive position, it doesn't end as well as you'd hope.
: Though honestly I'm leaning towards zapping the configurable compat
layer at some stage, and just having a 'these modifiers plus Fn
keys trigger VT switching' boolean.
: The spec's a bit subtle; when you ask for a component like
'+us(dvorak)' or 'pc(pc105)+%+ctrl(nocaps)', that means to _take
the current keymap_ and merge it with the provided components,
rather than build a new keymap from scratch with the names of the
previous components. Cool.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the xorg-devel