[comp.unix.xenix] Key board input driver.....

evh@vax1.acs.udel.EDU (Troy Saville) (02/19/89)

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???

evh@vax1.acs.udel.edu

daveh@marob.MASA.COM (Dave Hammond) (02/21/89)

In article <2887@udccvax1.acs.udel.EDU> evh@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@marob.masa.com

barton@holston.UUCP (barton) (02/22/89)

In article <566@marob.MASA.COM>, daveh@marob.MASA.COM (Dave Hammond) writes:
> In article <2887@udccvax1.acs.udel.EDU> evh@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
> 
> Strange things will occur if you modify the keyboard strings map
> via "setkey" or ioctl(GIO_STRMAP) and overflow the provided buffer.

This seems especially true on NCR keyboards, for instance I am
running SCO 2.2 on an NCR PC8 and when I issue setkey 16 "string"
the string actually loads into F14.

The same is true for F11 through F30 some of which will not even
load with setkey.

Has anyone figured out how to make the NCR keyboard behave as
advertized?


Barton A. Fisk                Voice: 318-439-5984
Barton A. Fisk & Co.
PO Box 1781 
Lake Charles, La.  70602-1781
 
UUCP: { texbell, killer }!warble!holston!barton
INTERNET: barton@holston.UUCP

----------------------------------------------
+++++++ "Hal, open the pod-bay doors" - Dave
----------------------------------------------