[comp.sys.sgi] Iris key remapping

dfr@USNA.MIL ("David F. Rogers") (01/10/89)

G'day,

SGI doesn't really use PC style keyboards -- it's not like either my
IBM AT's or my Zenith's -- they just use a lousy design. This is
especially true if you use an EMACS style editor.

I asked Chris Dunlop to put a key remapping high on their priority list.
Want to bet that they don't. And I just bought a half million worth of
SGI's. Sigh......

Professor David F. Rogers
Aerospace Engineering Department
U.S. Naval Academy
Annapolis, MD 21402
USA
Tel: 301-267-3283/4/5
 
ARPANET: dfr@usna.mil
UUCP:    ~uunet!usna!dfr

mike@BRL.MIL (Mike Muuss) (01/10/89)

As best as I can tell, the "4D" series of SGI machines use
IBM PS/2 keyboards, probably from a second-source vendor.

These keyboards are completely "soft", and the keys can be re-mapped.
Under SGI Release 2, they had provided BRL with patches to move the
control/shift_lock, and escape/tilde keys.

To date, SGI has not provided this same capability under SGI Release 3.1,
so we continue to use Sun-3/50 workstations as "front-ends" to our SGI
workstations.  We can't stand the keyboard layout of the PS/2 keyboard.

I understand that, at least under Release 2.0, it required changing the
source code to "wsh.c" to implement the re-bindings -- it is not
something that can be done via a config file.

Hopefully we can persuade SGI to release an interim solution to the
bad keyboard layout problem.
	Best,
	 -Mike

kipp@warp.SGI.COM (Kipp Hickman) (01/11/89)

In article <8901100147.aa05163@SEM.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes:
> As best as I can tell, the "4D" series of SGI machines use
> IBM PS/2 keyboards, probably from a second-source vendor.
>  ...
> To date, SGI has not provided this same capability under SGI Release 3.1,
> so we continue to use Sun-3/50 workstations as "front-ends" to our SGI
> workstations.  We can't stand the keyboard layout of the PS/2 keyboard.
>  ...
> 	Best,
> 	 -Mike

We supposedly use an IBM-RT keyboard, for what its worth.  From my own
personal experience, I had a tough time at first when I transitioned from
my 3000 keyboard to my 4D keyboard...It didn't take too long to adapt to
it, however.

Release 3.0 of the IRIX 4D system supports a simplified keyboard re-mapping
capability.  The relevant documentation is squirrel'd away in the
appendix/section that describes the escape sequences that wsh(1G) uses.

For the 3.2 software release, the program bindkey(1G) will be provided
which gives a simple user interface to the simple keyboard re-mapping
that 3.2 will support.  Future releases will do everything you are asking
for, but for obvious reasons, I can't promise a date as priorites change
often around here.

Here is an example code sequence that will bind your F1 key to say
"ls -l\r" (I am using printf notation):

	#include <device.h>

	int key_number = F1KEY;
	char *key_value = "ls -l\r";
	printf("\033P101;%d.y%s\033\\", key_number, key_value);

If you run that code sequence, it will do the trick.  Alternatively, if
you are brave and understand your shell and how it handles back-slashes,
you can type the underlying escape codes in from the keyboard.

If you are even braver, you can examine the PostScript support for 
keyboard binding.  This support varies based on what release you have.

If you have 3.0, heaven forbid, then look in /usr/NeWS/lib/NeWS/bindkey.ps.
If you have 3.0 (or earlier) I suggest you update to 3.1 asap, as 3.0
had some serious deficiencies in its keyboard handling (binding was
global across all wsh's).

If you have 3.1 or later, then look in /usr/NeWS/lib/NeWS/sgiwin.ps in
the procedure called ``bindasciikey''.  Hacking up what 3.1 does will
probably work up to (but not in) release 4.0.

Customer support will not be able to help you at all with this hacking,
so you are on your own (sorry).

Hope this helps.

				    kipp hickman (kipp@sgi.com)

steve@eos.UUCP (Steve Philipson) (01/11/89)

In article <8901100147.aa05163@SEM.BRL.MIL> mike@BRL.MIL (Mike Muuss) writes:

>These keyboards are completely "soft", and the keys can be re-mapped.
>Under SGI Release 2, they had provided BRL with patches to move the
>control/shift_lock, and escape/tilde keys.
>
>To date, SGI has not provided this same capability under SGI Release 3.1, ...

   Ah, I begin to see why I there are problems with installing 3.1 on my 
4D/60 that is still running 2.0.

   I'm trying to boot from a tape drive on another machine.  My efforts
are greeted with a copy of the install software (which takes several minutes),
followed by this error when it tries to run the program:

	can't load keyboard table   dkip(0,0,8) io_ktbl

   I may have the message slightly wrong ... I get to see it for about .1
second before the machine clears the screen and drops back to the monitor
level.  I'd appreciate receiving info on how to install the new software
given this problem.  I DO have a call into the hotline, but seem to be
playing telephone-tag with those folks, and I'd like to get going ASAP.
-- 

						   Steve
					(the certified flying fanatic)
					    steve@aurora.arc.nasa.gov

stay@BRL.MIL (Paul Stay) (01/11/89)

We had this same problem when we installed the 3.1 with a local tape
drive We were able to fix this at the prom monitor by seting the
following at the prom level. Someone a SGI was checking into this for
me, but it has been awhile since I have heard from him.

	>>setenv keybd df
	>>init

This tells the operating system to boot up with the default keyboard mapping.

-Paul

pett@cgl.ucsf.edu (Eric Pettersen%CGL) (01/12/89)

	Here is some code you can put in your user.ps to swap the CapsLock and
Control key under 3.0 and 3.1c.  I suggest that you actually imbed it your
RestartActions array, just to be safe.  This code uses undocumented operators
and constants, so who knows how it will work in future releases!
	It is possible to change any key, but the code below is pretty much
hard-coded to do what it does, and is not a flexible facility for arbitrary
key remapping...

				Eric Pettersen
				pett@cgl.ucsf.edu
				...!ucbvax!ucsfcgl!pett
-----
	{
		/CapsOn false def
		/ControlOn false def
		/eventhandler {
			dup /Action get
			exch /Name get
			{
			  28420 { % Caps Lock
				/DownTransition eq
				{ /ControlOn true def }
				{ /ControlOn false def } ifelse
			  }
			  28419 { % Control
				/DownTransition eq
				  { /CapsOn CapsOn not def } if
			  }
			} case
			2 CapsOn { /LampsOn } { /LampsOff } ifelse
			  keyboardcontrol
			CapsOn { 1 } { -1 } ifelse 4
			  adjustkeyboardshiftstate
			ControlOn { 1 } { -1 } ifelse 1
			  adjustkeyboardshiftstate
		} def
		createevent dup begin
			/Name [ 28420 28419 ] def
		end                               
		expressinterest
		{               
			awaitevent eventhandler
		} loop                          
	} fork pop
-----

miq@chromavac.SGI.COM (Miq Millman) (01/26/89)

In article <24593@sgi.SGI.COM>, kipp@warp.SGI.COM (Kipp Hickman) writes:
> In article <8901100147.aa05163@SEM.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes:
> > As best as I can tell, the "4D" series of SGI machines use
> > IBM PS/2 keyboards, probably from a second-source vendor.
> >  ...
   [stuff deleted]
> >  ...
> > 	Best,
> > 	 -Mike
> 
> We supposedly use an IBM-RT keyboard, for what its worth.  From my own
   
   [stuff deleted]

> 
> Here is an example code sequence that will bind your F1 key to say
> "ls -l\r" (I am using printf notation):
> 
> 	#include <device.h>
> 
> 	int key_number = F1KEY;
> 	char *key_value = "ls -l\r";

        this ^^^^^^^^^^^^^^^^^^^^^ is incorrect
  the actual line should read

 	char *key_value = "ls -l\\r";

Notice the double \ this is necessary because the C compiler ignoresthe first \
unless it is lead to read it in.

> 	printf("\033P101;%d.y%s\033\\", key_number, key_value);
> 
> 
> 				    kipp hickman (kipp@sgi.com)
> 

The line I put in is the correct form.  Please make noted change before you
use this stuff.