From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] kbd.c From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-dhslmzyxpptvqkitajxlgdpmle" Message-Id: <20020402093529.2BB1319988@mail.cse.psu.edu> Date: Tue, 2 Apr 2002 10:31:54 +0100 Topicbox-Message-UUID: 7167e2b2-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-dhslmzyxpptvqkitajxlgdpmle Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit it's easier in my experience to build and check these tables if you can do it dynamically. some mappings are more controversial than others (eg, caps lock and ctrl). i don't see that dynamic loading must lead to something complex, if that's what xmodmap is. actually, at the moment i'd be more interested in a description of what the tables need to express to cover all possibilities. i know there are sequences of escapes in the scan codes (because they ran out of bits), and keys that modify subsequent characters by adding accents (on a german keyboard we've driven), and probably much more. is there a concise specification? --upas-dhslmzyxpptvqkitajxlgdpmle Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-1.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 1017736188:10:01569:289; Tue, 02 Apr 2002 08:29:48 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1002746; 2 Apr 2002 8:29 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 38803199F2; Tue, 2 Apr 2002 03:29:06 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from nautilus.escet.urjc.es (nautilus.escet.urjc.es [212.128.4.207]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id CB18D19988 for <9fans@cse.psu.edu>; Tue, 2 Apr 2002 03:28:56 -0500 (EST) To: 9fans@cse.psu.edu Subject: Re: [9fans] kbd.c MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20020402082856.CB18D19988@mail.cse.psu.edu> 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: Tue, 2 Apr 2002 10:28:54 +0200 : Just to clarify, I prefer dynamically loadable tables because there are : occasions when, in our Unicode world, it makes sense to switch the : keyboard to another language temporarily. This is a different issue : from setting the default keyboard for regular use, but it would be : preferable to see both issues addressed by a single mechanism. But that does not require dynamiclly loadable tables, does it? If you include let's say us and whatever tables in your kernel by saying 'kbdus' and 'kbdxx' in your config file, and you are allowed to switch later between the two, you're done. What I was missing is that it's inconvenient to write echo kbdus >/dev/consctl when you have certain kbdxx keybards, but what about using function keys to switch between them? (eg. FN switches to Nth map). Is this a general mechanism, or am I missing something? --upas-dhslmzyxpptvqkitajxlgdpmle--