From: Boyd Roberts <boyd@strakt.com>
Message-Id: <200203311245.g2VCjvm0029525@theraft.strakt.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] kbd.c
In-Reply-To: <3CA62883.43F9B212@gsyc.escet.urjc.es>
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
Date: Sun, 31 Mar 2002 14:45:57 +0200

    They are changing this further to let the driver accept
    a "kbmap us" string into /dev/consctl to change the
    tables at run time.

Yes, it probably does belong with the files served by cons.

However, the kernel should not know about the various layouts;
these should be loaded when the machine boots.

Admittedly it's not likely that your keyboard is going to
change, but I don't feel it warrants cluttering up the
kernel with specialised (possibly redundant) code when
the problem can be solved in a general way with /dev/kbmap.

    They plan to select a good implementation of this change and send the
    contribution. Perhaps it would be better to unify this all to get just
    one driver capable of adapting to most of our keyboards.

Given I currently type on 3 different layouts [qwerty, azerty, Swedish
qwerty] the ability to load up a keyboard map is a must, but it should
never approach the complexity of that attrocity known as xmodmap(1).

I hacked up forsyth's work for my own personal use.