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): gnome-libs-1.2.13-16 How Reproducible: 100% 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 see ^[[11~ This should be ^[OP if the correct escape sequence was generated. Actual Results: ESC [11~ to ESC [14~ are generated for KP_F1 to KP_F4 Expected Results: ESC OP to ESC OS should be generated for KP_F1 to KP_F4 Additional Information: 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 are mishandled. 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.
Hmm, interesting... Got any more info on that? What are they going to use instead?
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.