1751852 Members
5267 Online
108782 Solutions
New Discussion

ssh with pc keyboard

 
sumdomo
Occasional Advisor

ssh with pc keyboard

Hello,

 

    We have a HP Blade server running HPUX 11.31, and workstation running x86 Solaris.

Everytime when we ssh to the hp box from the solaris the number key on the keyboard not function, it either show strange char or no response.

The keyboard is just regular pc keyboard.

Do anyone know how can I config this so the number key would work?

 

thanks in advance.

4 REPLIES 4
Dennis Handly
Acclaimed Contributor

Re: ssh with PC keyboard

Are you talking about the pound sign key, #?

 

What is the value of TERM on your HP-UX system?

I assume the number key on the keyboard works when you aren't on the HP-UX system?

sumdomo
Occasional Advisor

Re: ssh with pc keyboard

Hi,

 

 

    The Term is xterm and I mean the number key pad on a regular pc keyboard.

 

thanks.

 

Dennis Handly
Acclaimed Contributor

Re: ssh with PC keyboard

> I mean the number key pad on a regular PC keyboard.

 

Does your numeric keypad have a Num Lock button that you must use before it defaults to numbers vs other control functions?

Have you set this before you ssh?

Matti_Kurkela
Honored Contributor

Re: ssh with pc keyboard

At this point, the X11 software on your Solaris workstation is converting the characters entered using the PC keyboard to X11 key events.

 

Depending on how your Solaris workstation is configured, this conversion may or may not be 100% accurate. So there is one point you will need to check. If the "xev" command is available on the Solaris workstation, run it from a terminal window. The xev command will open a small window: select it and then type some characters using the number keypad. The xev command should output blocks of text like this to the terminal window it was started from:

KeyPress event, serial 34, synthetic NO, window 0x3800001,
    root 0x139, subw 0x0, time 195641336, (97,130), root:(1595,970),
    state 0x10, keycode 79 (keysym 0xffb7, KP_7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XmbLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x3800001,
    root 0x139, subw 0x0, time 195641408, (97,130), root:(1595,970),
    state 0x10, keycode 79 (keysym 0xffb7, KP_7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x3800001,
    root 0x139, subw 0x0, time 195641696, (97,130), root:(1595,970),
    state 0x10, keycode 80 (keysym 0xffb8, KP_8), same_screen YES,
    XLookupString gives 1 bytes: (38) "8"
    XmbLookupString gives 1 bytes: (38) "8"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x3800001,
    root 0x139, subw 0x0, time 195641768, (97,130), root:(1595,970),
    state 0x10, keycode 80 (keysym 0xffb8, KP_8), same_screen YES,
    XLookupString gives 1 bytes: (38) "8"
    XFilterEvent returns: False

 

The important things are the "(keysym <hex_number>, <name>)" part and the "XLookupString gives ..." part. The number keypad keys should create keysyms like KP_<number>, where <number> matches the number on the key itself. The XLookupString part should display an appropriate number character too.

 

The number keypad of a PC keyboard only sends number key events when the NumLock LED is on: otherwise, it will send cursor key events, for historical reasons. Try pressing the NumLock key and see if it makes a difference.

 

If the keysyms or the XLookupString are incorrect, there is a problem in the workstation's X11 keymap selection. A Solaris-specific forum might be a better place for asking how to fix that.

 

If that is not the problem, it's time to move on to the next point to check.

 

In the X11 environment of the Solaris, you're running xterm. A xterm is a terminal emulator: it tries to behave mostly like a VT100-compatible terminal, with some extensions. It converts the X11 key events to ASCII characters (or to UTF-8 or whatever extended-ASCII character set you're using) and sends them to the HP-UX system over the SSH connection.

 

VT100-compatible terminals have a numeric keypad which can be in one of two modes: either numeric keypad mode or application keypad mode. The terminal sends different key codes depending on the chosen mode. The modes can be switched using terminal control character sequences coming from the HP-UX system, or you can switch them manually using the settings of the xterm application.

 

First, is the HP-UX system aware that it's talking to a xterm? Run "printenv TERM" on the HP-UX system using your xterm session: it should optimally print "xterm" as the result. If this is not correct, you should set the TERM environment variable manually as a workaround: "export TERM=xterm" (or "setenv TERM xterm" if you use tcsh or the scummy C shell). For a real fix, you should check if the login scripts on the HP-UX systems are setting the TERM variable to a wrong value.

 

Second, move your cursor to the xterm window, hold down the Control key and press the middle mouse button. This should display the xterm options menu. Among other things, it should include a setting named "Enable application keypad". It is a toggle (i.e. an on/off-style setting). Try changing it: does it fix your problem?

If it does, then the HP-UX system is somehow out of sync with the keypad mode of the xterm emulator.

MK