On Wed, 11 Feb 2004 19:37:24 +0100
Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de> wrote:

> Independent Maps will consume much more space. Again from
> wskbdmap_mfii.c:
> 
> bytes map
>   514 pckbd_keydesc_us
>   158 pckbd_keydesc_de
>    20 pckbd_keydesc_de_nodead
>   140 pckbd_keydesc_dk
>    16 pckbd_keydesc_dk_nodead
>    44 pckbd_keydesc_sv
>    16 pckbd_keydesc_sv_nodead
>    36 pckbd_keydesc_no
>    16 pckbd_keydesc_no_nodead
>   182 pckbd_keydesc_fr
>   148 pckbd_keydesc_it
>   154 pckbd_keydesc_uk
>   104 pckbd_keydesc_jp
>   166 pckbd_keydesc_es
>   134 pckbd_keydesc_us_declk
>   150 pckbd_keydesc_us_dvorak
>    10 pckbd_keydesc_swapctrlcaps
>    70 pckbd_keydesc_iopener
> 
> Even the bigger Maps use less than 1/3 of a full map. And I'm not sure
> if all Maps are optimal encoded.

Yes, sure. It's suboptimal using several full keymaps (built in-kernel).

But if only one map is built there and the rest is made available via
userland it wouldn't be uselessly memory consumption -- as long as we
are refereing to volatile memory ;)

It also probably consumes less memory using two or three (1000 to 1500
bytes) (or how many does one need?) full maps built into the kernel than
having ten or more (in the future) keymaps built in-kernel -- event if
they are encoded completing. 

But it also fits in my (limited? ;) brain that this couldn't really be
the solution for a cleanly designed operating system as NetBSD is one;
BTW: the only one? ;)

So the question -- for variant 3 -- could explicitly become if there's a
comprehensible way for a framework (or so) able to build *.c/*.h and
external keymap files using the actual -- recursive -- method.

> -- 
> Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig
> (Germany)

Hernani