Re: [9fans] kbd.c

[Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

:  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.

Just to clarify, kbd.c stays almost the same with the
changes made to add new tables. Just the handling of
modifiers is changed to admit new tables (eg AltGr).

I wouldn't say the kernel is cluttered by introducing
separate kbdxx.c files with just the tables
and nothing else. I think that's more simple than the
mechanism needed to fill up the tables at run time; besides
the user can cause a real mess if allowed to fill up those
tables at run time (cf xmodmap).


[-- Attachment #2: Type: text/plain, Size: 2500 bytes --]

Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Sun Mar 31 14:46:21 MDT 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id DCDE119A29; Sun, 31 Mar 2002 07:46:12 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from theraft.strakt.com (theraft.strakt.com [62.13.29.34])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 81C1819A17
	for <9fans@cse.psu.edu>; Sun, 31 Mar 2002 07:45:59 -0500 (EST)
Received: from theraft.strakt.com (localhost [127.0.0.1])
	by theraft.strakt.com (8.12.1/8.12.1/Debian -5) with ESMTP id g2VCjvpZ029527
	for <9fans@cse.psu.edu>; Sun, 31 Mar 2002 14:45:57 +0200
Received: (from boyd@localhost)
	by theraft.strakt.com (8.12.1/8.12.1/Debian -5) id g2VCjvm0029525
	for 9fans@cse.psu.edu; Sun, 31 Mar 2002 14:45:57 +0200
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
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.8
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Help: <mailto:9fans-request@cse.psu.edu?subject=help>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
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.