Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!sunybcs!boulder!hao!oddjob!gargoyle!ihnp4!homxb!whuts!mtune!mtung!pgf
From: pgf@mtung.ATT.COM (Paul Fox)
Newsgroups: comp.sys.att
Subject: Re: remapping keyboard on 3B1?
Message-ID: <1008@mtung.ATT.COM>
Date: Wed, 14-Oct-87 16:02:07 EDT
Article-I.D.: mtung.1008
Posted: Wed Oct 14 16:02:07 1987
Date-Received: Fri, 16-Oct-87 22:31:33 EDT
References: <4340@spool.wisc.edu> <1566@oxtrap.UUCP> <1779@ho95e.ATT.COM> <3566@islenet.UUCP>
Reply-To: pgf@mtung.UUCP (gws-Paul Fox)
Organization: AT&T ISL Middletown NJ USA
Lines: 47

>Okay, but how about switching <del> with <break>?  That seems like

    I think I can point this discussion in the right direction (and 
    would like to, given a long-term interest in keyboard remapping :-).  

    In /usr/include/sys there is a file called kbd.h.  It contains, 
    surprisingly, some information concerning the keyboard.  

    In this file there is an array of structures declared called 
    "keymap".  The structure is defined just above it.  As noted in the 
    comments against the structure, the table consists of the 
    following information for each and every physical key on the 
    keyboard (plus some -- there are 128 entries, some unused): 

	a)	The "value" the driver should use for the unshifted key.
	b)	The "value" the driver should use for the shifted key.
	c)	The "value" the driver should use for the ctrl'ed key.
	d)	Some flags the driver should use for something or other.

    As a further pointer in the right direction, this table actually 
    appears in each and every UNIX pc kernel, somewhere in /dev/kmem.  

    As yet another pointer, the address of that table can be obtained 
    from "nm /unix", or, for those of you without the development set,
    from "/etc/lddrv/unix.sym".  

    As yet another pointer, a simple utility such as adb (or cat, for 
    those of you without the development set :-) is capable of 
    modifying files such as /dev/kmem or /dev/mem on a byte by byte 
    basis.  

    The rest of the problem is left as an exercise to the programmer 
    (or user, for those of you without the development set :-).  

    Note that I've never tried this specific trick on the UNIX pc...  
    I couldn't write CAPCTRL (the 3.0 version) this way (as a user 
    program that poked at the in-memory kernel), because the code that 
    does caps locking and cntrling doesn't use the table -- it uses 
    the #defines just above the table labelled "Special Keyboard Scan 
    Codes", and the code was hard to patch.  It was easier to rewrite it
    and make it a loadable driver.



-- 
			Paul Fox, AT&T Information Systems, Middletown NJ.
			  [ihnp4|vax135]!mtung!pgf (201)957-2698