Bug 132951 - Inconsistent xterm vs. console mapping
Inconsistent xterm vs. console mapping
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ncurses (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-20 06:40 EDT by Jonathan Allen
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: FEDORA CORE 4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-31 11:56:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program that displays the fault (1.11 KB, text/plain)
2004-09-20 06:41 EDT, Jonathan Allen
no flags Details

  None (edit)
Description Jonathan Allen 2004-09-20 06:40:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040803

Description of problem:
There appears to be a significant difference between the 'special' key
mappings between a Linux console and an xterm window.  This applies
particularly to the numeric keypad, but also to the arrow keys and the
Ins/Del/Hom/End block as well.  These are the values returned by getch().

One particular example:

   Left-Arrow:   LinCon = 0x104    Xterm = 0x104
   Sh-L-Arrow:   LinCon = 0x104    Xterm = 0x1b, 0x4f, 0x32, 0x44

Another:

   Keypad +:     LinCon = '+'      Xterm = 0x1b, 'O', 'k'

This is after:

   initscr();
   cbreak;
   noecho();
   keypad(stdscr, 1);
   c = getch();                <== the call that returns the codes

This has seriously broken a large suite of 'text' software that I was
trying to 'port into a generally graphical environment.  Some of it
can be code around, by having a mapping routine in place to intercept
the extra erroneous codes and remap them back to what they should be,
but this is a clear change in behaviour and is not at all desirable.

The same problem is also present in FC3T1.

Version-Release number of selected component (if applicable):
ncurses-5.4-5

How reproducible:
Always

Steps to Reproduce:
1. run test program to print out the values on both a standad Linux
text console and an xterm window
2. type identical keys and just watch the difference
3.
    

Actual Results:  Linux console continues to return the same results as
it has since Slackware 2!

Xterm produces completely different character sequences for most of
the function/activity/keypad keys, both in shift and unshifted mode

Expected Results:  The final (ie delivered to the application code)
ket sequences, as KEY_END, KEY_LEFT and so on, should have been mapped
through to the application code.

Additional info:
Comment 1 Jonathan Allen 2004-09-20 06:41:52 EDT
Created attachment 104010 [details]
Test program that displays the fault

Run the program as:

   testchar -c
Comment 2 Thomas E. Dickey 2004-09-20 17:09:23 EDT
> Actual Results:  Linux console continues to return the same
> results as it has since Slackware 2!
not exactly (there have been several changes, and listing them
would make this discussion longer than necessary).
Comment 3 Thomas E. Dickey 2004-09-20 17:15:33 EDT
xterm's behavior is settable by resources, of course.]
Linux console is hardcoded (and doesn't correspond to
either vt100 or vt220, notwithstanding the documentation).
xterm doesn't emulate Linux console.  It emulates a vt102
or vt220, with various adaptations for users.

See
http://invisible-island.net/xterm/xterm.log.html#xterm_94
(the behavior you're referring to has been in xterm for
more than five years).
Comment 4 Jonathan Allen 2004-09-21 05:04:23 EDT
Notwithstanding what original physical terminal xterm is or is not 
supposed to emulate (which I agree would be a sterile argument and 
one that I didn't intend to get into - please accept my apologies for 
appearing to argue that way), my immediate concern is the failure of 
ncurses to produce simple keymappings that it does correctly produce 
when in a Linux console environment, with the environment variable 
TERM set correctly in each case.

The test program clearly shows that while the unshifted arrow keys, 
Insert and Delete are correctly mapped to KEY-LEFT/RIGHT/UP/DOWN, etc.
the keys HOME, END and the numeric keypad "/*-+" keys all generate 
escape sequences rather than the simple "/*-+" keys.

If there is an easy way to remedy this situation, I'd be delighted to 
hear it.  I have whole suite of software which works in Linux console 
and does no terminal dependent stuff at all, using all the ncurses-
defined KEY_XXX labels.  When I move it to xterm, it breaks.  Why?
Comment 5 Thomas E. Dickey 2004-09-21 07:44:01 EDT
ncurses is using $TERM to find a terminfo entry that describes
the keys.  First, your $TERM doesn't describe the shifted keys
that xterm is sending and second, terminfo doesn't list all of
the combinations.  The xterm-new entry lists the useful combinations
for function-keys.  Numeric keypad isn't listed in the terminfo.
Applications can use those (for instance using define_key, or by
providing customized terminfo entries).

It's not clear why you expect key modifiers to do nothing.
Comment 6 Jonathan Allen 2004-09-21 08:20:51 EDT
Let's focus on the different components here:

   1. HOME/END keys are indeed fixed by changing the default setting
      of the TERM environment variable from 'xterm' to 'xterm-new'.
      Thank you for that.  Is this now a distribution bug/fault that
      FC2 sets the default TERM for xterm to a broken/obsolete
      terminfo entry 'xterm' instead of the better one you
      recommended ?

   2. we were surprised that the Linux console ignored Shift for the
      arrow keys, but considered this to be 'normal'.  Now that the
      xterm does generate the Shift-key sequences, we can choose
      whether to support them or not.  Problem solved.  Why do the
      keypad "/*" generate Shift, Control and Alt sequences whilst
      the keypad "+-" entries don't appear to generate codes when
      modified ?

   3. Why aren't the numeric keypad entries listed in terminfo, given
      that ncurses contains an explicit call keypad(scr, mode) to
      make use of these definition.  Are you saying that on an xterm,
      the call to keypad() is a null operation ?
Comment 7 Thomas E. Dickey 2004-09-21 08:32:33 EDT
For #1 - see #128138 (and related bugs).  I won't attempt to
summarize...

#2, Keypad +/- are used for stepping through the font menu.

#3, terminfo describes the most common features of many different
terminals.  While some terminfo entries list the numeric keypad
keys as function-keys, that would interfere with the normal
assignment of F1, etc., to function keys.  Standard terminfo
entries can have only 64 function-keys (and for instance, xterm-new
uses some of those for the modifiers).

ncurses (from 5.0 on) allows extensions to the terminfo, but that's
not often used for various reasons (not a technical limitation).
Comment 8 Jonathan Allen 2004-09-22 10:28:53 EDT
The keypad processing state seems to be lost when executing a sub-
program in an xterm which isn't lost when in Linux console.  Program 
saves the content of the screen so that it can be repainted 
afterwards, then does the standard sort of fork/exec/wait sequence, 
restores the screen and does refresh().  The screen appears to be 
fine, but the setting of keypad(stdscr, 1) has been lost and needs to 
be re-invoked to get it to work again.  Why is this ?
Comment 9 Thomas E. Dickey 2004-09-26 13:41:41 EDT
That sounds like the subprocess is resetting the keypad to
normal mode.  Generally (Linux console is an exception),
termcap/terminfo entries set application mode (a different
set of escape sequences) for the cursor-keys and keypad-keys.
If it's being reset in that manner, that's probably a workaround
to "keep" the keys in normal mode, e.g., to work with hardcoded
bash input-bindings.
Comment 10 Matthew Miller 2005-04-26 11:00:01 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 11 Petr Raszyk 2005-08-31 11:49:45 EDT
Not each terminal (terminal emulator) has (knows) all 'keys'.
That is why not each terminal (terminal-emulator) emits all possible
keys. This is a proprety of a terminal (terminal emulator) (to emit a key).
A termnal-emulator emulate a hard-ware-terminal 
(for instance vt100  <-- this hard-ware definitly exists somewhere.
It has not all keys that you have on your keyboard today).

A special case is 'xterm' or 'linux-console' (it emulates something, that
does not exist and did not exist as 'hard-ware').
NOTE: X-Terminal exists, but the communication protocol is X-Windows-protocol
over tcp/ip
(a way to 'transfer' a graphic).Something different from a
clasic-terminal-connection
(a way to 'transfer' characters or glyphs (glyphs == characters represented as
glyphs).

If the linux-console emits the same key for the key '+'  and the keys
" Keypad '+' ", this is a terminal (terminal-emulation) property.
If the xterm-emulator emits different keys for the key '+' and the keys
" Keypad key '+' ", this is a terminal (terminal-emulation) property.

You are right, that 'shift-arrow-left' in 'xterm' should be
converted (via ncurses) to a 'number'  (the function call getch()
should return one number, not a sequence of numbers/characters (ESC-sequence).
In FEDORA CORE the keys "shift-arrow-left" (in xterm) return a unique number==393.
In FEDORA CORE the key " Keypad '+' " (in xterm) returns a unique number==27==ESC.

NOTE: 1) ncurses 5.4 returns ESC-key if the key is unknown.
      2) You can watch all keys know by ncurses in /usr/include/curses.h
         (search KEY_LEFT (arrow-left) and KEY_SLEFT (shift-arrow-left).
      3) ncurses supports 'common' keys used by terminals (terminal-emulators).
         xterm is a special case. You can modify/add key/new-keys in 
         /usr/X11R6/lib/X11/app-defaults/XTerm  or
         create a copy of .../XTerm in a directory and set
         shell-environment-variable XAPPLRESDIR to this directory
         (for instance "export XAPPLRESDIR=$HOME"  ).

         Then, you can change:
         
         <Key>Delete:    string(0x1b) string("[3~") 

         to

         <Key>Delete:    string(0x1b) string("XQI") 

         If you press the Del-key in 'xterm', the xterm emits to your
         application \EXQI instead of \E[3~
         ncurses 5.4 can not 'catch' this 'new-esc-sequence' (you must change
         the "kdc1"/"kD" in terminfo/termcap (see 'man termcap', 
         'man terminfo').

I see only a way to write/modify your own terminal-emulator to support all
possible keys. This was by the pterm-clone done. 
See at www.c-frame.com/downpage25. 
Install and doubleclick the icon pterm8x16. Launch tc-frame.
The pterm-clone-source is at www.c-frame.com/changes/changes.html

Petr Raszyk

Note You need to log in before you can comment on or make changes to this bug.