From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] kbd.c From: Fco.J.Ballesteros MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-puznhicruvmhquuyhznkvhdnuq" Message-Id: <20020402081819.DA2C019988@mail.cse.psu.edu> Date: Tue, 2 Apr 2002 10:17:53 +0200 Topicbox-Message-UUID: 715f0ae8-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-puznhicruvmhquuyhznkvhdnuq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit : 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). --upas-puznhicruvmhquuyhznkvhdnuq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 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: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: 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. --upas-puznhicruvmhquuyhznkvhdnuq--