Patch to not fork/exec xkbcomp on X Server initialization

[Paulo Cesar Pereira de Andrade]

Daniel Stone wrote:

  Ouch, only now I noticed that I had an empty reply in the previous email.
I got an error from the webmail interface last night, then pressed
"Alt+LeftArrow" and "send button" again, but pressing back aparently also
removed my edition of the message...

  Basically I had said that I agreed with Daniel that it was required
a different approach, and that my patch was not correct, because the
name of the server-N.xkm file should be like a hash of the contents of the
servern-N.tmp file, that looks like "setxkbmap -print" output.

>>> Yes, I was expecting around 50% or so.  If this is tested and working
>>> fine for you, I'm perfectly happy for you to recommend this to people
>>> who need it, but I'm definitely not merging it.  In theory, xkbcomp
>>> should just be xkbcomp(), which hands us back the XkbDescRec it
>>> generates while parsing anyway.
>> A rewrite may be a better option, but is there any reason we can't put
>> paulo's patch into master for the time being? Worse comes to worst it's
>> reverted (or removed) when the rewrite happens. Trying to debug xkb startup is
>> a pain right now, and removing the fork may just convince my gdb not to die
>> the death of a thousand sins.
  I will try to write a more general patch. The one I posted is just an
adaptation of a patch I am using for an OEM for a "mini pc". But it has
some problems as a "mainstream patch", because it requires root to write
to a root owned directory, if the file doesn't exist. As long as the
keyboard configuration is not changed, the patch will work as long as
the files are generated once by root, but chaning keyboard configuration
will have no effect...

> The thing is that this still forks, so you're still screwed on startup,
> and you still have the XKM mess.  All it does is cache the output
> somewhere.
  Something that may be worth investigating is if it would be possible to
somehow "compile" every single xkb file from the xkeyboard-config package,
and then "link" them together based on the used xkb options.

  Or, maybe there is already a request to read a keymap from an event? 
If not,
it is something that could be really useful, a client connects to the X 
Server
and sends the compiled keymap over the wire.

  But I think this is some kind of thing that requires a lot of knowledge
of xkb, and I already forgot most of what I once knew :-)

>> and the thing with rewrites is that they tend to always take longer than
>> expected, so if there's an interim solution I'm not the one to complain.
>
> Yeah, I'm still happy to try the smashing-xkbcomp-in-its-current-form-in
> thing again.
>
> Cheers,
> Daniel

Paulo