Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!elroy.jpl.nasa.gov!usc!orion.oac.uci.edu!drector
From: drector@orion.oac.uci.edu (David Rector)
Newsgroups: comp.unix.sysv386
Subject: Re: help with X386?
Message-ID: <280A092D.6294@orion.oac.uci.edu>
Date: 15 Apr 91 20:12:28 GMT
References: <16183.2809bec1@levels.sait.edu.au>
Organization: University of California, Irvine
Lines: 55

In <16183.2809bec1@levels.sait.edu.au> mareb@levels.sait.edu.au writes:

>Subject: help with X386?

>My second problem is that I have to talk to a VMS machine which expects
>VT100 function keys. xterm seems to send some quite odd strings:

>	F1	ESC[11~
>	F2	ESC[12~
>	...
>	Page Up	[[
>	...

>I have not been able to discover how or why this happens. The doco.
>seems to suggest that the keymaps used on the console should still
>be applicable - but  it isn't.

I've been having related troubles with key definitions.  Here's what seems
to work.

1.  Find out what key codes are really being sent by the server.  The tools
for this are 'xev' and 'xmodmap'.  'xev' puts up a test window which reports
all events that take place in it.  This will allow you to determine what
the server thinks the key you press is, and what it translates to.  There
are two sets of key codes:

    a. The server sends two bytes: 
        i)  state - state of modifier keys (shift, etc.)
        ii) a server dependent 'keycode'.

    b. These are translated by clients into X specific 'keysym's.

'xmodmap' queries and modifies the table translating keycodes to
keysyms.  'xmodmap -pk' types out this table.  I have not been able to
find a utility that will type out the XTerm translation table.

2.  In whatever file your xterm reads to find its resources (I use
'xdm' to start X; it reads /usr/lib/X11/app-defaults/XTerm), put
modifications of the VT100 translations.  I use

    XTerm*ttyModes: intr ^c erase ^?
    XTerm*VT100*Translations: #override\
       Shift<KeyPress>KP_9:string("9")\n\
       Shift<KeyPress>KP_3:string("3")\n\
       Shift<KeyPress>KP_0:string("0")

The purpose of these changes in translations was to correct what looks
like a bug in the keyboard translations of X386 1.1.  I suspect Tom
made compensating errors in 1.1 that show up now that he has fixed the
keyboard code in 1.1a.  On my system, X386 1.1a returns correct codes
for the direction and keypad keys.  

-- 
David L. Rector				drector@orion.oac.uci.edu
Dept. of Math.				U. C. Irvine, Irvine CA 92717