Hi. Sorry having too long delay before writing reply.
Finally, I have tried vttest on my Debian 2.2 potato
with my locally built Linux kernel 2.2.19.
(I'll be away tomorrow and can't access the network
before Sunday 21 April.)
In <20011106050856.B475@bloatware.dickey.net>,
on "Tue, 6 Nov 2001 05:08:56 -0500",
with "Re: What's your environment ? (Re: Bug#106454: ncurses-base: linux console should have smkx/rmkx entry)",
Thomas Dickey <dickey@herndon4.his.com> wrote:
dickey> I use vttest to see what keys are transmitted when the normal and application
dickey> modes are set.
dickey>
dickey> http://invisible-island.net/vttest
dickey> ftp://invisible-island.net/vttest
I used version 20011130.
dickey> When I made my comment, I ran vttest, noted that the results were not correct
dickey> unless I set numlock. I run several versions of Linux, so it's possible that
dickey> we're not talking about the same version - I can test and see if that is a
dickey> factor. Most of my installs are running a 2.2.x kernel. At the moment I'm
dickey> on 2.2.19, whose behavior for the numeric keypad is as I recalled: if numlock
dickey> is not set, the transmitted character sequences are PC-style (cursor, home/end,
dickey> etc.) rather than VT100-style numeric keypad codes.
Result from Test 5 (Keyboard Test) / Type 4 (Cursor key)
<ANSI / Cursor key mode RESET>
(Cursor key Up) <27> [ A (Up arrow key)
(Cursor key Down) <27> [ B (Down arrow key)
(Cursor key Left) <27> [ D (Left arrow key)
(Cursor key Right) <27> [ C (Right arrow key)
<ANSI / Cursor key mode SET>
(Cursor key Up) <27> O A (Up arrow key)
(Cursor key Down) <27> O B (Down arrow key)
(Cursor key Left) <27> O D (Left arrow key)
(Cursor key Right) <27> O C (Right arrow key)
This is independent of the numlock setting.
When I received your reply, I forwarded your mail to
the author of fdclone, Takashi SHIRAI <shirai@nintendo.co.jp>.
And he wrote (about 5 months ago. sorry for the long delay in
my translation work):
(original is in Japanese, I translated his mail
into English below)
| > I use vttest to see what keys are transmitted when the normal and application
| > modes are set.
| >
| > http://invisible-island.net/vttest
| > ftp://invisible-island.net/vttest
|
| I have got this software and tried it, but I can't
| reproduce the problem on my Systems:
|
| RedHat Linux 6.1J (Kernel 2.2.12-32)
| Vine Linux 1.1CR (Kernel 2.0.36)
|
| (Translator's Note: Vine Linux is a popular local distribution in Japan)
|
| I use vttest-20000208 and just doing `./configure && make`.
| I'm sure that the terminal I used is the raw linux console.
| I've done the test immediately after login to the system.
|
| (BTW, please take care that this software don't reset
| the terminal on exit, so I have to issue reset(1)
| each time after doing a test.)
|
| > When I made my comment, I ran vttest, noted that the results were not correct
| > unless I set numlock. I run several versions of Linux, so it's possible that
| > we're not talking about the same version - I can test and see if that is a
| > factor. Most of my installs are running a 2.2.x kernel. At the moment I'm
| > on 2.2.19, whose behavior for the numeric keypad is as I recalled: if numlock
| > is not set, the transmitted character sequences are PC-style (cursor, home/end,
| > etc.) rather than VT100-style numeric keypad codes.
|
| I have read the source of vttest, and wish to confirm
| whether you know the following facts:
|
| 1. There are two functions in the proposed smkx/rmkx:
| smkx: "\E?1h" = cursor key mode on
| "\E=" = keypad application mode
| rmkx: "\E?1l" = cursor key mode off
| "\E>" = keypad numeric mode
|
| 2. "Cursor key" is the key which has an arrow mark
| only on the keytop. And it is irrelevant to the
| key in the place of "2", "4", "6", or "8" on keypad.
|
| (And "Home key" and "End key" are also separate ones,
| not the keys on keypad. "Keypad" on PC is so-called
| "ten key", keys which have numbers and arrows/signs/etc.)
|
| 3. When at the "cursor key mode on (SET)",
| each cursor key emits ESC(\027)-O-{A,B,D,C}.
|
| When at the "cursor key mode off (RESET)",
| each cursor key emits ESC(\027)-[-{A,B,D,C}.
|
| This is independent of the setting on NumLock,
| And keys other than cursor keys don't change
| their key codes at all.
|
| 4. When at the "keypad application mode",
| each keypad key emits ESC(\027)-O-{A,...z}.
| This is independent of Numlock setting.
|
| And Numlock setting can't be altered in
| this (keypad application) mode, since Numlock
| key itself emits ESC(\027)-O-P as its keycode
| in this mode.
|
| When at the "keypad numeric mode",
| each keypad key emits its natural keycode;
| when NumLock is on, keypad keys emit 0 ... 9
| when NumLock is off, keypad keys emit keycodes
| for cursor keys or special keys.
| In this case, keys other than keypad keys don't
| change their keycodes at all with or without
| NumLock setting.
|
|
| Here is a table compiled from the facts above:
|
| | cursor key mode off | cursor key mode on
| ----------------+-----------------------+--------------------
| keypad numeric | keycode-0 | keycode-1
| keypad appl. | keycode-2 | keycode-3
|
| (Translator's Note: keycode-{0,1,2,3} is not an official
| name. Just a classification name for convenience here.)
|
| [NumLock off]
| code-0 code-1 code-2 code-3
| <- \E[D \EOD \E[D \EOD
| End \E[4~ \E[4~ \E[4~ \E[4~
| 4(<-) \E[D \EOD \EOt \EOt
| 1(End) \E[4~ \E[4~ \EOq \EOt
|
| [NumLock on]
| code-0 code-1 code-2 code-3
| <- \E[D \EOD \E[D \EOD
| End \E[4~ \E[4~ \E[4~ \E[4~
| 4(<-) 4 4 \EOt \EOt
| 1(End) 1 1 \EOq \EOt
|
| Cursor key mode can be checked by using vttest
| Test 5 (Keyboard Test) / Type 4 (Cursor key).
|
| "<ANSI / Cursor key mode RESET>" means cursor key mode off,
| and "<ANSI / Cursor key mode SET>" means cursor key mode on.
|
| Keypad mode can be checked by using vttest
| Test 5 (Keyboard Test) / Type 5 (Numeric Keypad).
|
| "<ANSI Numeric mode>" means keypad numeric mode,
| and "<ANSI Application mode>" means keypad application mode.
|
| Note that vttest 5.->4. (Keyboard/Cursor) always set
| cursor key mode on exit, and vttest 5.->5. (Keyboard/Keypad)
| always set keypad application mode on exit.
| So you need to use /usr/bin/reset after doing these tests
| before doing other tests.
|
| > (The comment in the response below regarding cursor keys is misleading, since
| > those are unaffected by the numlock setting).
|
| I think that vttest itself doesn't use or check entry
| in termcap/terminfo. So this software can't be used
| to check the entry in termcap/terminfo.
|
| Please confirm that you do know:
|
| a. keypad key is different from cursor key.
|
| b. vttest doesn't reset the terminal on exit.
|
| c. natural behavior of keypad keys.
|
| According to the classificaiton of keycode-[0-3] above,
| smkx is the sequence to enter the state of keycode-3,
| and rmkx is the sequence to enter the state of keycode-0.
|
| I suppose that you worry about the case "using smkx
| with NumLock off, keys marked "<-" or "End" in keypad
| don't work as cursor key or special key.
|
| But, the keypad of terminals for which original termcap
| is created, is different from PC's one. So there is no
| clear rule how PC's keypad should be treated.
|
| There is the rules by DEC for keypad key sequence at:
| http://vt100.net/docs/vt100-ug/table3-8.html
| and this is the de facto standard for terminals.
|
| The keycode sequence in code-2,3 above follows this rule
| as the key sequence in application mode. Other UNIX
| terminals and terminal emulators follow this rule too.
|
| And, almost all entries for those other terminals in
| termcap/terminfo, set keypad application mode in
| keypad transmit mode.
|
| I suppose there are some other UNIX application programs
| which rely on those convention, and they can't get keypad
| keys on Linux console since they expect DEC-compatible
| keycode sequences for keypad application mode by enabling
| keypad transmit mode.
|
| BTW, I checked the behavior of xterm (on XFree86), and
| it varies with NumLock on/off. Same as Linux console
| when NumLock on, but differs with NumLock off:
|
| code-0 code-1 code-2 code-3
| <- \E[D \EOD \E[D \EOD
| End \E[F \E[F \E[F \E[F
| 4(<-) \E[D \EOD \E[D \EOD
| 1(End) \E[F \E[F \E[F \E[F
|
| This shows that xterm detects the state of NumLock in
| Keypad Application mode. I think this is enhancement
| for PC hardwares.
|
| I've not found the guidelines on behavior of NumLock
| in PC-UNIX environment, but if you believe this is the
| right behaviour, then it is natural that you don't like
| that Linux console don't check the NumLock setting in
| keypad application mode.
|
| As the consequnce from informations above,
| I suggest to use one of the following entries:
|
|
| 1. If each keypad key should emits the keycode of
| lower marks on keytop, i.e. as cursor/special keys:
| (this is not compatible with the rules of DEC)
| ->
| smkx=\E[?1h, rmkx=\E[?1l,
| kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC, kcub1=\EOD
|
| 2. If each keypad key should work as DEC-compatible
| when NumLock on (in this case, keypad key doesn't
| work as cursor/special keys when NumLock off)
| ->
| smkx=\E[?1h\E=, rmkx=\E[?1l=E>,
| kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC, kcub1=\EOD
|
| 3. If each keypad key should work as cursor/special
| key when NumLock off, and each keypad key should
| work as DEC-compatible when NumLock on:
| -> fix console.c in Linux kernel
| ->
| smkx=\E[?1h\E=, rmkx=\E[?1l=E>,
| kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC, kcub1=\EOD
|
| I believe the option 2 or 3 is the way to go,
| since the behavior in keypad application mode is defined
| by the de-facto standard, while the behaviour in NumLock off
| doesn't have the clear and well-known standard.
Thanks for your patience and excuse me for the long delay.
Regards.