Hi, 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 > scripts? > > 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
it publicly.
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[0], 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
terrible.
We pretty much need to be able to merge XkbDescRecs anyway[1], 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.
Cheers,
Daniel
[0]: 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.
[1]: 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.
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
