original request:
-> I just got stuck with a type-5 keyboard on my IPX.
-> On top of that, it's the idiotic UNIX layout rather
-> than the US layout, which may or may not affect what
-> I really need to get fixed: how do I move the NumLock
-> key somewhere else (off of the keypad). I would prefer
-> the ScrollLock button, which is useless anyway. I can
-> disable NumLock and make it something else with no
-> problem, but I can't get another key to successfully
-> be a NumLock. running OW3.0, 4.1.2
->
-> On a related topic, we are about to get stuck with a
-> bunch of NCD19C X terminals instead of SUNs unless we
-> holler like stuck pigs. We have been told that the
-> type-5 keyboards will work on the NCDs. Is this true
-> (especially for the US layout version), and if so,
-> can we move NumLock there also? I have already been
-> successfull remapping it on a N101 keyboard (which we
-> refuse to accept any more of.) running NCD's xdm,
-> running olwm on the host system for each X terminal.
->
-> Danny Johnson, Texas Instruments, 214-995-8719
************************************************************************
************************************************************************
the real answer to the first question is to get a copy of
/usr/share/lib/keytables/us_5, edit, and place under "~/.keytable".
this is the only way to make another key take the place of NumLock,
because "lock" keys have to be treated weird in that every other event
from them must be ignored (key-up on NumLock has no meaning, unlike
key-up on almost every other key). there is no way to get xmodmap to
accomplish this for you (at least on a type-5 keyboard).
for the second question, the answer ssems to be yes; I had no trouble
getting xmodmap to map the Scroll_Lock key, and see the first reply
below (although my old NCD software's setup key does not seem to do
anything useful, maybe Pam has the Rev 3 NCD release). NCD also gives
out shareware that helps people create a xmodmap command file.
************************************************************************
************************************************************************
The numlock key on the NCD Xterminals is very easy to change.
Hit the setup key and read the menu. It gives you several
options for changing the keyboard.
Pam L. Boge
Visualization and Imaging Team UUCP: ...!uunet!inel.gov!ppc
Idaho National Engineering Lab. INTERNET: ppc@INEL.GOV
POB 1625 M.S. 2608 Phone: +1-208-526-9379
Idaho Falls, Id. 83415 FAX: +1-208-526-9936
************************************************************************
************************************************************************
the following is not really an answer, but is obviously
related to the question and should be quite useful. I have not yet
verified anything that is listed below this point. Danny out
>From travis@cs.odu.edu Tue Nov 24 10:06:13 1992
Date: Tue, 24 Nov 92 11:09:25 EST
From: Travis L Priest <travis@cs.odu.edu>
To: danny@ews7.dseg.ti.com
Subject: Unix type-5 keyboard mapping
Content-Length: 8744
Mon, danny@ews7.dseg.ti.com <danny@ews7.dseg.ti.com> wrote:
i can answer the first part of this question, but have no idea about
the second. most of my knowledge stems from a newspost i made some
time back to comp.sys.sun.hardware and a reply from Guy Harris at
Auspex who got me pointed in the right direction. i'll give you the
post and the reply, then some of the stuff i've done on followup:
--original post--
>From travis@krishna.cs.odu.edu Fri Sep 25 17:14:00 1992
Newsgroups: comp.sys.sun.hardware
From: travis@krishna.cs.odu.edu (Travis L Priest)
Subject: Dip Switches on Type 5 kbd
Nntp-Posting-Host: krishna.cs.odu.edu
Organization: Old Dominion Univeristy, Norfolk, VA, USA
Distribution: comp
Date: Thu, 24 Sep 1992 18:20:27 GMT
i'm the proud (?) new owner of one of type 5 keyboards, and i've
already been bitten by the caps lock key. it was trivial to use
xmodmap to swap caps lock and control, but i couldn't find any
ready-made program to return the keyboard type. on that note, i set
about writing my own and discovered that the new type 5 keyboards
(under SunOS 4.1.1 & 4.1.2) return a type 4 value. now that i've
thought about it a little, that seems to make sense.
needing a different way to determine the difference between the
keyboards through software, i deciced to key off the dip switch
settings. from what i can tell, a type 4 keyboard will return 0 (all
dipswitches off) and a type 5 keyboard will return 33 (switches 3 & 8
on). my question is: is this the guaranteed dip switch settings on
all type 5 keyboards shipped from sun? secondly, what is their
meaning (the documentation was somewhat lacking...)?
this is the code fragment i've been playing with:
...
if ( ioctl(kbd_fd, KIOCLAYOUT, (caddr_t) &kbdtype) )
die(*argv, "couldn't query keyboard");
printf("%d\n", kbdtype);
...
KIOCTYPE always returns 4 (KB_SUN4).
thanks!
--Travis--
--original reply to post--
>From guy@Auspex.COM Fri Sep 25 17:12:33 1992
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.sys.sun.hardware
Subject: Re: Dip Switches on Type 5 kbd
Date: 24 Sep 92 23:17:44 GMT
Distribution: comp
Organization: Auspex Systems, Santa Clara
Nntp-Posting-Host: bootme.auspex.com
>now that i've thought about it a little, that seems to make sense.
Yup. It does make sense.
In some sense, keyboards have major and minor version numbers. The
major version number changes if it's not just a different layout;
otherwise, the minor version number changes.
KIOCTYPE returns the major version number; KIOCLAYOUT returns the minor
version number.
The Type 4 wasn't just a different layout; it supported two commands
("commands" here refers to the protocol used by the host to talk to the
keyboard) that the Type 3 didn't, namely the "set LEDs" command and the
"get layout" command. Thus, it required a new "major version number" or
"keyboard type".
The Type 5, as far as I know, doesn't require any keyboard driver
changes of that sort (in fact, the keyboard driver didn't change between
4.1.1 and 4.1.2 in any way related to the Type 5), so it didn't require
a new "major version number". Instead, it just got a bunch of new
layout codes.
>needing a different way to determine the difference between the
>keyboards through software, i deciced to key off the dip switch
>settings. from what i can tell, a type 4 keyboard will return 0 (all
>dipswitches off)
The Type 4 will return a code based on the setting of the lower 6 DIP
switches (the topmost DIP switch is the "claim to be a Type 3" switch,
and, as I remember, the switch below it is unused). Thus, if all DIP
switches are off, the layout code will be 0.
The Type 5 will do the same, I think.
> and a type 5 keyboard will return 33 (switches 3 & 8 on).
That'd be
switch 12345678
X X
That's 00100001, or hex 21, or decimal 33.
>my question is: is this the guaranteed dip switch settings on
>all type 5 keyboards shipped from sun? secondly, what is their
>meaning (the documentation was somewhat lacking...)?
The answer to the first question is "NO!" The lower 6 DIP switches on
the Type 4 and Type 5 are intended to indicate what the keyboard layout
is on the keyboard.
As for the second question, take a look at LOADKEYS(1) and KEYTABLES(5),
and take a look in "/usr/share/lib/keytables".
The files "layout_00", "layout_01", and "us" are, for example, the same
file (three links to that file). Layout codes 00 and 01 mean "Type 4,
US layout". The file "layout_0e" is a link to "uk"; layout code 0e, or
decimal 14, means "Type 5, UK layout", and so on.
"layout_21", "layout_22", and "us_5" are links to the same file; layout
codes 21 (decimal 33) and 22 (decimal 34) mean "Type 5, US layout",
hence "us_5".
I think those codes are documented somewhere, although not necessarily in
the manual pages.
NOTE: "loadkeys" modifies the "keyboard driver"s translation tables.
Those tables are used when typing on the "raw console", and when typing
in SunView; they are *NOT* used when typing in X11 (either MIT
X11 or Open Windows) or NeWS - the MIT X11 and X11/NeWS servers run the
keyboard in "untranslated event" mode, so that they get raw keystation
codes rather than translated ASCII/ISO 8859-1/function key codes, and
turn those into key symbols at a higher level (it's done in the client
application in X11, for example).
I.e., don't assume that by running "loadkeys" you'll affect the mappings
under X11; you won't do so unless the X11 server reads the "keyboard
driver"s translation table and constructs its keycode-to-keysym mapping
based on that, and I don't think any X11 servers on Suns do so.
--what i've done to deal with it--
i did complete my program, and it makes a "best guess" at the type of
keyboard you are using based on the dip switch setting (layout).
basically, anything returning 33 is considered a type-5 keyboard for
my purposes, and yes, it's a terrible hack. you can add in a case
statement if your keyboard returns a different code and have it return
what you like. here's the source:
--kbdtype.c--
#include <sys/types.h>
#include <sys/file.h>
#include <sys/ioctl.h>
#include <sundev/kbio.h>
#include <sundev/kbd.h>
#include <stdio.h>
void
main(argc, argv)
int argc;
char *argv[];
{
void die();
int kbdtype, kbd_fd;
if ( (kbd_fd = open("/dev/kbd", O_RDONLY, 0)) < 0 )
die(*argv, "couldn't open keyboard");
if ( ioctl(kbd_fd, KIOCLAYOUT, (caddr_t) &kbdtype) )
die(*argv, "couldn't query keyboard");
switch (kbdtype) {
case 0:
printf("4\n");
break;
case 33:
printf("5\n");
break;
default:
fprintf(stderr, "Unknown (%d)\n", kbdtype);
break;
}
exit(kbdtype);
}
void
die(prog, msg)
char *prog, *msg;
{
fprintf(stderr, "%s: %s.\n", prog, msg);
exit(-1);
}
--end kbdtype.c--
in my .login and .xinitrc i test for the keyboard type. the .login
uses "loadkeys," and the .xinitrc uses "xmodmap:"
--.login--
if { test "`kbdtype | grep -c 5`" -ne 0 } then
loadkeys $HOME/.keytable
endif >&/dev/null
--.keytable--
key 76 all shiftkeys+capslock
key 86 base ; shift : caps ; ctrl | altg nop
key 119 all shiftkeys+leftctrl up shiftkeys+leftctrl
--.xinitrc--
if [ `kbdtype | grep -c 5` -eq 0 ]
then
echo Type 4 keyboard
else
xmodmap $HOME/.xmodmaprc
fi
--.xmodmaprc--
!
! Swap Caps_Lock and Control_L (from the manual page)
!
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
!
! Make backspace work just like delete
!
keysym BackSpace = Delete
i use the mit X server, but xmodmap should work the same for you under
openwindows. hope some of that helps.
--Travis--
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:53 CDT