Incorrect key "translation" behavior for "xterm"

Incorrect key "translation" behavior for "xterm"

Post by Greg Jump » Sun, 03 Oct 1993 05:27:15



While setting up "translations" for "xterm" to properly emulate the VT100
application/numeric keypad on a Solaris 2.2 (OpenWindows 3.2) system, I
discovered that string translations do not work correctly.

For example, the "7" key on the far right keypad of the Type 5 keyboard has
"7" and "Home" on its face.  The "xnews" definition for this key, as given by
/usr/openwin/share/etc/keytables/US_UNIX5.kt is

#
#Scan  Atts     Col1            Col2            Col3            Col4
#
68      RN      XK_R7           XK_R7           XK_KP_7         XK_Home

which says that the keysym returned by this key in its "natural", unshifted,
unmodified state is "R7" (equivalent to "F27" for non-Sun X11) and that it has
the "Home" keysym *only* in the shifted, "mode_switch"ed state.

If I define strings for both "R7" and "Home", an instance of "xterm" will
*always* return the string for "Home" when the "7" key on the keypad is
pressed, regardless of shift modifiers.

The application/numeric keypad keys work properly in a "shelltool", and "xev"
shows "F27" (aka "R7") as the keysym being returned by the "7" key, so I'm not
sure where "xterm" is picking up the "Home" keysym/translation.

By the way, this problem also appears when using the X11R5 version of "xterm"
(albeit using the OpenWindows libraries).

Does anyone know what causes this problem?  Is it specific to "xnews"?  If it
doesn't appear in X11R5, then perhaps it will be fixed in Solaris 2.3...
--
                                       Thanks,

                                       Greg Jumper
                                       TRW Signal Processing Facility