Bug 57713 - Qt mis-identifies keypad keys
Qt mis-identifies keypad keys
Product: Red Hat Linux
Classification: Retired
Component: qt (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-12-19 18:05 EST by Bryan Wright
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version: qt-3.3.4/kde-3.4.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-01 08:36:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bryan Wright 2001-12-19 18:05:50 EST
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):

How reproducible:

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
    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:
Comment 1 Bernhard Rosenkraenzer 2001-12-19 18:09:29 EST
This is the expected behavior if NumLock is turned off.
If NumLock is on, you'll get the numbers, just what you'd expect.
Comment 2 Bernhard Rosenkraenzer 2001-12-19 18:10:07 EST
I presume you aren't seeing this when NumLock is on? (At least I'm definitely seeing the correct behavior).

Comment 3 Bryan Wright 2001-12-20 10:56:56 EST
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"?
Comment 4 Bryan Wright 2002-01-29 13:41:54 EST
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.

Comment 5 Ngo Than 2004-09-23 05:24:17 EDT
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.
Comment 6 Bryan Wright 2004-09-23 11:04:40 EDT
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.
Comment 7 Ngo Than 2005-09-01 08:36:29 EDT
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.   

Note You need to log in before you can comment on or make changes to this bug.