Red Hat Bugzilla – Bug 65163
KP_Fx keysyms generate wrong escape sequence
Last modified: 2008-05-01 11:38:02 EDT
Description of Problem:
Wrong escape sequences generated for KP_F1..KP_F4 keysyms
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open a gnome-terminal
2. At the shell prompt do
xmodmap -e "keycode 0x4D = KP_F1"
This makes the Num Lock generate the KP_F1 keysym
3. At the shell prompt, hit Ctrl-V, NumLock. You will
This should be ^[OP if the correct escape sequence was generated.
ESC [11~ to ESC [14~ are generated for KP_F1 to KP_F4
ESC OP to ESC OS should be generated for KP_F1 to KP_F4
Keysyms KP_F1 to KP_F4 are never generated by the standard
PC keyboard. They correspond to the top row of the numeric
keypad on DEC keyboards (like the LK201, LK401). DEC terminals
such as the VT100, VT220 label these keys as PF1 to PF4.
They certainly have no connection with the F1 to F4 keysyms
which correspond to the PC keyboard's F1 to F4 keys.
For various reasons, I remap the top row of my PC's numeric
keypad to KP_F1 to KP_F4. In an xterm, these keys will then
generate ESC OP, etc.
However, as part of a RedHat-specific patch to gnome-libs
(gnome-libs-1.2.13-zvthomeend.patch), the KP_Fx keysyms
In fact, the standard GNOME-supplied zvtterm.c doesn't
quite get it right either, because it treats F1 to F4
the same as KP_F1 to KP_F4, while it should really be
treating them the way you guys treat KP_Fx. Confused?
No matter - that's something I can take up with the
GNOME guys myself.
In the meantime, there is a problem with gnome-libs in
that libzvt doesn't act like a VT100. And your patch
actually makes it worse...
You should modify your patch to leave KP_F1/2/3/4 always
generating ESC OP/Q/R/S. This should be safe, because
the standard PC keymaps will never generate KP_F1/2/3/4
keysyms, so no other users will be affected by it.
And it will mean that I don't need to patch gnome-libs
every time you update it.
Most likely we're just dumping libzvt in favor of a new widget in the next
release. cc'ing Nalin so he's aware of this issue when working on that.
Got any more info on that? What are they going to
It's another widget called "vte", it's in GNOME CVS. Requires GNOME 2 version of
gnome-terminal built configure --with-widget=vte.
Needs testing with VTE.
FWIW the right sequence still doesn't seem to be generated with vte-0.8.10-1.
We should be properly emulating the various different function key modes of
XTerm in vte 0.9.2 and later. Please reopen if you continue to see problems
with the version in Raw Hide or in gnome.org's CVS.
Will vte 0.9.2 ship with Red Hat 8.1?
I don't have a recent enough Red Hat box to test Raw Hide
stuff on (yet). Sorry.