Red Hat Bugzilla – Bug 57713
Qt mis-identifies keypad keys
Last modified: 2007-04-18 12:38:47 EDT
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
Version-Release number of selected component (if applicable):
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
"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
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
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.
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
Okay, so now I edit /usr/share/apps/konsole/vt100.keytab so that the End key is
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:
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.