From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.14-5.0 i686) Description of problem: The keys in the numeric keypad are being mis-identified by Qt. For example, the "1" key is identified as "Key_End", the "2" as "Key_Down" and the "3" as "Key_Next". Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Open a konsole window, and select Settings -> Keyboard -> vt100 (any other keyboard will do, as long as it has a keytab file in /usr/share/apps/konsole. The "Xterm (XFree 4.x.x)" entry WON'T work for this illustration, since it doesn't have a keytab file to look at, but I'd bet it has the same problem.) 2. In the konsole window, type "cat - > junk.dat", then press the "1", "2" and "3" keys on the keypad. In the window, you'll see "^[[F^[[B^[[6~" if you've chosen the vt100 keypad in step 1, above. These are three escape sequences generated by the three keys. The "^[" represents an escape character. 3. Examine the file /usr/share/apps/konsole/vt100.keytab. You'll find that "\E[F" is supposed to be generated by the "End" key. "\E[B" is supposed to be generated by the "Down" key, and "\E[6~" is supposed to be generated by the "Next" key. Qt is apparently mis-identifying the "1", "2" and "3" keys as "End", "Down" and "Next". The same test can be done using any of the other keytab files. Additional info:
This is the expected behavior if NumLock is turned off. If NumLock is on, you'll get the numbers, just what you'd expect.
I presume you aren't seeing this when NumLock is on? (At least I'm definitely seeing the correct behavior).
Sorry about that. It was partly my confusion. I was expecting "KP_1" instead of "End". But the remaining problem seems to be that Qt doesn't make any distinction between the keypad numbers and those on the main keyboard, even though they have different keycodes and keysyms. For example: Start xev, and look at the keycode and keysym for the "End" key and the keypad's "1" key (no num lock). For the End key, I get keycode=103, keysym=End. For the keypad "1" key, I get keycode=87, keysym=KP_End. Okay, so now I edit /usr/share/apps/konsole/vt100.keytab so that the End key is defined as: key End -Shift-AppCuKeys : "stuff" Now, I start up a konsole using this keytab. I find that both the End key and the KP_End key generate the string "stuff". Is Qt internally equating "KP_foo" with "foo"?
It looks like the necessary functionality was available in QT 2.2.0: http://www.trolltech.com/developer/changes/2.2.0.html According to this, in "QKeyEvent" Numeric keypad keys now set a Keypad flag.
Please verify this with a newer version of Red Hat Enterprise Linux or Fedora Core and reopen it against the new version if it still occurs. Closing as "CURRENTRELEASE" for now.
The bug, as described in comment #3 above, still persists in Fedora Core 2, kdebase-3.2.2-6.FC2. (I just now tried it out.) Also, /usr/share/apps/konsole/vt100.keytab says: # keypad characters as offered by Qt # cannot be recognized as such.
I have tried to reproduce this problem described in comment #3 on fc4 with kde-3.4.2/qt-3.3.4 but i'm not able to reproduce this problem! Both the End key and the KP_End key works as expected.