JDK-5033605 : KP_Separator handled wrong in KeyEvents
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2_05
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux_suse_sles_8.2
  • CPU: generic
  • Submitted: 2004-04-19
  • Updated: 2005-06-20
  • Resolved: 2005-06-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 Other
6Fixed unknownResolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
Summary: KP_Separator handled wrong in KeyEvents
================================================

Operating systems:
==================
Linux   : currently SuSE 8.2 but reproducible on any recent distribution.
Solaris : tested on SunOS 5.8

Java version:
=============
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)

as well as all other VMs down to 1.3.1

System setup:
=============
locale          : de_DE
Keyboard layout : standard german layout
xkb_keymap {
        xkb_keycodes  { include "xfree86+aliases(qwertz)"       };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc/pc(pc105)+pc/de(nodeadkeys)"        };
        xkb_geometry  { include "pc(pc105)"     };
};

Description:
============
The key char obtained with ev.getKeyChar() from a KeyEvent.KEY_TYPED
KeyEvent.KEY_PRESSED and KeyEvent.KEY_RELEASED events KP_Separator.
The problem is independent from the key the KP_Separator symbol is 
assigned to.

The key char obtained from the KeyEvent.KEY_PRESSED and 
KeyEvent.KEY_RELEASED events
is incorrect and does reflect the assigned character but always yields 
'.' (KP_Decimal)
although KP_Separator is commonly assigned ','.

The key char obtained from the PRESSED and RELEASED events seems to be 
hardcoded
and does not reflect the assigned keysyms in the XKB database for the 
numeric keypad.
It does however reflect these assignments for other keys. This is at 
least inconsistent.

Reproduction:
=============

Case 1:
=======
$ locale
LANG=de_DE
LC_CTYPE=de_DE
LC_NUMERIC=de_DE
LC_TIME=de_DE
LC_COLLATE=de_DE
LC_MONETARY=de_DE
LC_MESSAGES=en_US
LC_PAPER="de_DE"
LC_NAME="de_DE"
LC_ADDRESS="de_DE"
LC_TELEPHONE="de_DE"
LC_MEASUREMENT="de_DE"
LC_IDENTIFICATION="de_DE"
LC_ALL=

$ xmodmap -pke | grep KP_
keycode  63 = KP_Multiply XF86_ClearGrab
keycode  79 = KP_Home KP_7
keycode  80 = KP_Up KP_8
keycode  81 = KP_Prior KP_9
keycode  82 = KP_Subtract XF86_Prev_VMode
keycode  83 = KP_Left KP_4
keycode  84 = KP_Begin KP_5
keycode  85 = KP_Right KP_6
keycode  86 = KP_Add XF86_Next_VMode
keycode  87 = KP_End KP_1
keycode  88 = KP_Down KP_2
keycode  89 = KP_Next KP_3
keycode  90 = KP_Insert KP_0
keycode  91 = KP_Delete KP_Separator
keycode 108 = KP_Enter
keycode 112 = KP_Divide XF86_Ungrab

$ java KeyboardTest.KeyboardTest

focus the entry field then press the key with keycode 91
note the unprintable character entered into the field
and see the following events:

Event text    : Tastenblock .
Event type    : KEY_PRESSED
Event key code: 110
Event key char: .
============================================================
Event text    : Unknown keyCode: 0x0
Event type    : KEY_TYPED
Event key code: 0
Event key char: ?
============================================================
Event text    : Tastenblock .
Event type    : KEY_RELEASED
Event key code: 110
Event key char: .
============================================================

key char '.' is not the assigned KP_Separator in PRESSED and RELEASED
but KP_Decimal and the key char is garbled in TYPED.

Case 2:
=======
$ xmodmap -e 'keycode  91 = KP_Delete KP_Decimal'

$ xmodmap -pke | grep KP_
keycode  63 = KP_Multiply XF86_ClearGrab
keycode  79 = KP_Home KP_7
keycode  80 = KP_Up KP_8
keycode  81 = KP_Prior KP_9
keycode  82 = KP_Subtract XF86_Prev_VMode
keycode  83 = KP_Left KP_4
keycode  84 = KP_Begin KP_5
keycode  85 = KP_Right KP_6
keycode  86 = KP_Add XF86_Next_VMode
keycode  87 = KP_End KP_1
keycode  88 = KP_Down KP_2
keycode  89 = KP_Next KP_3
keycode  90 = KP_Insert KP_0
keycode  91 = KP_Delete KP_Decimal
keycode 108 = KP_Enter
keycode 112 = KP_Divide XF86_Ungrab

$ java KeyboardTest.KeyboardTest

focus the entry field then press the key with keycode 91
This case works by coincidence since the keycode 91 is assigned KP_Decimal
a '.' is entered in the input field and you see the following events:

Event text    : Tastenblock .
Event type    : KEY_PRESSED
Event key code: 110
Event key char: .
============================================================
Event text    : Unknown keyCode: 0x0
Event type    : KEY_TYPED
Event key code: 0
Event key char: .
============================================================
Event text    : Tastenblock .
Event type    : KEY_RELEASED
Event key code: 110
Event key char: .
============================================================

note the difference to case 1, the PRESSED and RELEASED events are
identical but the TYPED event is not garbled this time.

Case 3:
=======

$ xmodmap -e 'keycode  91 = KP_Delete A'

$ xmodmap -pke | grep KP_
keycode  63 = KP_Multiply XF86_ClearGrab
keycode  79 = KP_Home KP_7
keycode  80 = KP_Up KP_8
keycode  81 = KP_Prior KP_9
keycode  82 = KP_Subtract XF86_Prev_VMode
keycode  83 = KP_Left KP_4
keycode  84 = KP_Begin KP_5
keycode  85 = KP_Right KP_6
keycode  86 = KP_Add XF86_Next_VMode
keycode  87 = KP_End KP_1
keycode  88 = KP_Down KP_2
keycode  89 = KP_Next KP_3
keycode  90 = KP_Insert KP_0
keycode  91 = KP_Delete A
keycode 108 = KP_Enter
keycode 112 = KP_Divide XF86_Ungrab

$ java KeyboardTest.KeyboardTest

focus the entry field then press the key with keycode 91
nothing is entered in the input field and the TYPED event is missing.
The pressed and RELEASED events are still wrong.

Event text    : Tastenblock .
Event type    : KEY_PRESSED
Event key code: 110
Event key char: .
============================================================
Event text    : Tastenblock .
Event type    : KEY_RELEASED
Event key code: 110
Event key char: .
============================================================

Case 4:
=======

revert to the standard key bindings
$ xmodmap -pke | grep 'q Q'
keycode  24 = q Q

$ java KeyboardTest.KeyboardTest

focus the entry field then press the key with keycode 24 together with Shift
note that 'Q' is entered into the field and observe the following events:

Event text    : Umschalt
Event type    : KEY_PRESSED
Event key code: 16
Event key char: ?
============================================================
Event text    : Q
Event type    : KEY_PRESSED
Event key code: 81
Event key char: Q
============================================================
Event text    : Unknown keyCode: 0x0
Event type    : KEY_TYPED
Event key code: 0
Event key char: Q
============================================================
Event text    : Q
Event type    : KEY_RELEASED
Event key code: 81
Event key char: Q
============================================================
Event text    : Umschalt
Event type    : KEY_RELEASED
Event key code: 16
Event key char: ?
============================================================

in contrast after assigning 'A' to keycode 24 + Shift:
$ xmodmap -e 'keycode  24 = q A'

$ java KeyboardTest.KeyboardTest

focus the entry field then press the key with keycode 24 together with Shift
note that 'A' is entered and that key char reflects the assigned 
character in PRESSED
and RELEASED events unlike cases 1 - 3.

keycode  24 = q A
Event text    : Umschalt
Event type    : KEY_PRESSED
Event key code: 16
Event key char: ?
============================================================
Event text    : Q
Event type    : KEY_PRESSED
Event key code: 81
Event key char: A
============================================================
Event text    : Unknown keyCode: 0x0
Event type    : KEY_TYPED
Event key code: 0
Event key char: A
============================================================
Event text    : Q
Event type    : KEY_RELEASED
Event key code: 81
Event key char: A
============================================================
Event text    : Umschalt
Event type    : KEY_RELEASED
Event key code: 16
Event key char: ?
============================================================

Conclusion:
===========

The numerical keypad is unusable for data entry since the defined 
keyboard layout
is not respected and illegal  KEY_TYPED events are generated.


***** This problem effects 1.3.1 - 1.5 beta on all platforms *****
***** Please fix this problem in these releases since they   *****
***** are used in supportef SAP products                     *****

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic mustang
21-08-2004

SUGGESTED FIX Name: ynR10250 Date: 06/16/2004 In addition to a change described in evaluation, we should mask high order bit by another ugly patch: *** 885,890 **** --- 887,893 ---- case XK_Linefeed: case XK_Escape: case XK_Delete: + case XK_KP_Separator: /* Strip off highorder bits defined in xkeysymdef.h * I think doing this converts them to values that * we can cast to jchars and use as java keychars. That would be partial fix for this particular problem. ###@###.### ======================================================================
21-08-2004

EVALUATION Name: ynR10250 Date: 04/21/2004 True, there is hardcoded keysym substitute in the native code. To remedy it, we could for instance do something like this (for XAWT): -------src/solaris/native/sun/xawt/XWindow.c ------- *** /tmp/sccs.fnZQLN 2004-04-21 16:20:26.000000000 +0400 --- XWindow.c 2004-04-21 15:34:02.000000000 +0400 *************** *** 801,807 **** *keysym = XK_KP_0; break; case XK_KP_Delete: ! *keysym = XK_KP_Decimal; break; case XK_R4: *keysym = XK_KP_Equal; /* Type 4 kbd */ --- 801,808 ---- *keysym = XK_KP_0; break; case XK_KP_Delete: ! /* *keysym = XK_KP_Decimal; */ ! *keysym = XK_KP_Separator; break; case XK_R4: *keysym = XK_KP_Equal; /* Type 4 kbd */ It is strange nobody noticed it before. Anyway, it would be prudent to commit a fix for dragonfly as this is very old and basic piece of code. ###@###.### -- ====================================================================== Name: ynR10250 Date: 06/16/2004 Suggested fix would work under XAWT with 1.5.0; similar change work for Motif as well. However, all this doesn't fix every problem related to this single key. Namely, it doesn't send proper data with NumLock+Shift and just Shift, and even doesn't work properly in a TextField. I'm afraid we cannot fix it in Tiger. A partial fix may be posted to dragonfly, and a new bug 5064016 is filed. ###@###.### ====================================================================== The change above doesn't seem like a right fix to me. This mapping represents a compenstation to the lack of library-provided mapping for the keys from NumLock-affected planes. Normally, on Solaris, such mapping does XKeycodeToKeysym, however on Linux we were unable to use it. The code in handleKeyEventWithNumLockMask looks bogus to me, and I think it should be rewritten. Hard-coded mapping should be removed, since it works only for some keyboards and doesn't respect user settings. We must find the way to consistently map the key to/from NumLock plane. The hard-coded plane number(2) should also be removed, it doesn't work for Linux(on my machine it is plane 1) and it anyway might not work for other configurations. Committing for Mustang. ###@###.### 2004-06-21
21-06-2004