[PATCH] Use cached XKB keymap when rules haven't changed
peter.hutterer at who-t.net
Tue Dec 2 16:30:41 PST 2008
On Tue, Dec 02, 2008 at 10:29:59AM +1100, Daniel Stone wrote:
> On Tue, Dec 02, 2008 at 08:26:32AM +1000, Peter Hutterer wrote:
> > On Tue, Dec 02, 2008 at 02:31:48AM +1100, Daniel Stone wrote:
> > > On Mon, Dec 01, 2008 at 06:36:32AM -0800, Dan Nicholson wrote:
> > > > I was reading the xkb-atkins log a couple weeks ago. It looks like a
> > > > nice diet. :)
> > >
> > > FWIW, this is progressing nicely, except I've currently regressed the
> > > case where people can't compile XKB keymaps. Normally I wouldn't
> > > really care about this, but the failure mode is the server crashing
> > > when a client connects, because PickKeyboard() returns NULL. Oops.
> > >
> > > Not hugely sure what to do there. Peter?
> > Weird. PK should never return NULL, since there's always the VCK and the VCP.
> > Did you pull in ec1d08442f6935? This change enables the core devices before any
> > Xkb* stuff for any other devices is called, maybe side-stepping the problem.
> Yes, but InitKeyboardDeviceStruct can fail these days: if there's no XKB
> data, then we don't have a core keymap to speak of, so it just bombs
Oh, for the list - we had an IRC discussion about that. The solution is "don't
do that", X can't deal with not having the VCP or VCK around, so failing to
init the map on the first core keyboard is fatal.
More information about the xorg