(no) xkbcomp in server -- simpler solution?

[Daniel Stone]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100611/104f997f/attachment.pgp>