On Mon, 7 Mar 2005 08:44:58 +0100
Jachym Holecek <freza@liberouter.org> wrote:

> Would there be a way to cleanly generate a kernel keymap source file
> from userland keymap file? If so, necessary framework could be put
> inside kernel build infrastructure and everyone would win -- while
> keeping all keymaps just inside /usr/share/wscons/keymaps. The "add
> new unicode symbols" part of PR's like the one you mention would
> probably still need to be applied, causing no harm.

This seems like a great idea to me, and since I remember taking a look
at the kernel ones to implement one in the past, I beleive it would be
simple to do.

I remember implementing something on my systems to allow keymap file
descriptions to be based on one of the default kernel encodings, this
however would probably be more complicated to implement then since the
in-kernel encodings would vary with configuration (misc/26720).

However, assuming that keymap files will have full descriptions of all
necessary codes instead of being modifications of an existing keymap
(which is the case now on netbsd), I think it's doable...  Incomplete
keymaps could possibly have missing codes defaulting to US settings.

I don't think that performance is critical in loading a keymap, so we
could also have packed mirrors of wanted userland keymaps in the kernel
image, which could be parsed just like we do now without needing large
text files nor text parsing in the kernel, or more complex text file to
C program generator requirement.  It also would be possible to use a
binary endian-independent keymap format even in userland, using the same
packed representation, which kernel builds could link as-is (along with
a new userland program to view/load/save them).

Since there are alot of open PR requests for keymap addition, many
dating a long time back (including my own kern/23184), once the unified
system is ready, it would be easier to integrate them...

Matt