Moving xkbcomp into the server

[Dan Nicholson]

On Tue, Nov 18, 2008 at 2:21 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Tue, Nov 18, 2008 at 11:08:36AM -0800, Dan Nicholson wrote:
>> > I think it'd be less effort to leave the converter as-is and remove the need
>> > for calling it, but that's a guess only too.
>>
>> So, I took a look at this, and it was fairly easy to write an
>> (untested) patch that checks if RMLVO has been changed and bailing out
>> early from XkbInitKeyboardDeviceStruct if it hasn't. However, I think
>> this still leaves you with two xkbcomps during the startup in the
>> common configuration. XkbInitKeyboardDeviceStruct will be called first
>> via InitCoreDevices with the default ruleset ("base", "pc105", "us",
>> NULL, NULL). Then the driver will call XkbInitKeyboardDeviceStruct
>> again with a ruleset that is probably different (most likely rules ==
>> "evdev"). So, you're going to get two keymap conversions in most
>> cases, anyway, but at least totally gratuitous conversions can be
>> removed. I'll send that patch after I test it a bit.
>
> As the theory goes, at least under linux we should be able to change the
> default ruleset of "evdev", etc. anyway, which skips another xkbcomp
> invocation.

Right now the defaults are hardcoded via XkbSetRulesDflts into dix/devices.c:

#ifdef XKB
        if (!noXkbExtension) {
            bzero(&names, sizeof(names));
            XkbSetRulesDflts("base", "pc105", "us", NULL, NULL);
            XkbInitKeyboardDeviceStruct(pDev, &names, &keySyms, modMap,
                                        CoreKeyboardBell, CoreKeyboardCtl);
        }
        else
#endif

The XkbSetRulesDflts isn't strictly necessary, though, since the xkb
code has it's own built-in defaults that it will fall back to if no
new defaults are set:

xkb/xkbInit.c:
#ifndef XKB_DFLT_RULES_FILE
#define XKB_DFLT_RULES_FILE     "rules"
#endif
#ifndef XKB_DFLT_KB_LAYOUT
#define XKB_DFLT_KB_LAYOUT      "us"
#endif
#ifndef XKB_DFLT_KB_MODEL
#define XKB_DFLT_KB_MODEL       "dflt"
#endif
#ifndef XKB_DFLT_KB_VARIANT
#define XKB_DFLT_KB_VARIANT     NULL
#endif
#ifndef XKB_DFLT_KB_OPTIONS
#define XKB_DFLT_KB_OPTIONS     NULL
#endif

So, it would be fairly easy to use these macros and just set a linux
build time default:

if test "$host_os" = linux; then
    dflt_xkb_rules=evdev
else
    dflt_xkb_rules=base
fi
AC_DEFINE_UNQUOTED([XKB_DFLT_RULES_FILE], [$dflt_xkb_rules], [Default
XKB rules file])

And change the XKB_DFLT_KB_MODEL default to pc105. I don't know if
that screws with people trying to use the kbd driver on linux, though
(don't know if we care, either).

>> But, why not "oh, same RMLVO, do nothing"? Oh, that's because you have
>> to do it for each device. I guess then you probably want to keep the
>> xkm file in that case, and only unlink during CloseDownDevices or
>> something. Unfortunately, the xkm file is immediately deleted right
>> now. This really only helps if you have multiple keyboards or you're
>> hotplugging them, though.
>
> well, since the xkms hardly ever change across server instances finding a way
> to buffer them across multiple restarts would fix that problem too. Then you
> really only have xkmRead() for each keyboard, no xkbcomp anymore.
>
> Oh, btw:
> whot at dingo:~$ grep "Configuring as keyboard" /var/log/Xorg.0.log
> (II) Power Button (FF): Configuring as keyboard
> (II) AT Translated Set 2 keyboard: Configuring as keyboard
> (II) Sleep Button (CM): Configuring as keyboard
> (II) ThinkPad Extra Buttons: Configuring as keyboard
> (II) Video Bus: Configuring as keyboard
> (II) Video Bus: Configuring as keyboard
>
> If I'm not completely wrong, xkbcomp will be called for all of them, so
> chances are high that you have a "multiple keyboard" setup.

Wow, hadn't noticed that, and checking through the evdev source shows
that the keymap will be reconfigured each time. OK, I'll just work on
this first and see if I can get it down to a single xkbcomp for
default configurations.

--
Dan