Key board input driver.....

[Dave Hammond]

In article <2887 at udccvax1.acs.udel.EDU> evh at vax1.acs.udel.EDU (Troy Saville) writes:
>
>I apparently blew out the keyboard input driver on xenix 2.2.1
>running on an ncr 916. Some keys didn't produce anything
>on any virtual terminals, some keys produced control
>sequences, the alt key didn't work, the control key didn't
>work. I shut down and rebooted and everything was okay.
>the keyboard switch was in the AT position(i've always had it in
>that position since i installed xenix). Anyone have a clue???
>

Strange things will occur if you modify the keyboard strings map
via "setkey" or ioctl(GIO_STRMAP) and overflow the provided buffer.

The total length of all combinations of unshift, shift and control
function and keypad strings must not exceed 256 bytes in 2.1 and
2.2, or 512 bytes in 2.3.  Initially each of the 60 possible key
combinations is assigned a 4 byte ANSI sequence (3 chars and a null).
In release 2.2, this takes up an initial 240 of your 256 bytes.

If this describes your problem, I suggest you redefine each of the
key combinations which you don't use (eg Ctrl-Shift-Fx) to a null
string.  This will add 3 bytes for user string assignments for each
key nullified.  This can be accomplished via "setkey". For example,
to nullify the Ctrl-Shift-F1 key sequence, issue the command: 

	setkey 38 ""

By nullifying all the Control-Fx and Control-Shift-Fx key combinations
you can gain about 72 bytes of user string assignment space.

See setkey(C) for a complete table of keynum assignments.

BTW, you can often regain control of a blasted keyboard by issuing
the "mapstr" command.  This will rebuild the key-strings map from the
default values.

--
Dave Hammond
daveh at marob.masa.com