JDK-4379138 : Linux: problems with key events for dead keys
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0,1.3.1,1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2000-10-13
  • Updated: 2002-04-25
  • Resolved: 2002-04-25
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.
1.4.1 hopperFixed
Related Reports
Duplicate :  
Relates :  
Relates :  

Name: yyT116575			Date: 10/13/2000

java version "1.3.0beta_refresh"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0beta_refresh-b09)
Java HotSpot(TM) Client VM (build 1.3.0beta-b07, mixed mode)

Using this xmodmap keymap, some keys are not correctly handled.

The problematic keys are those that can generated "composed" characters (using
dead keys)
For example, in my keymap :

keycode  34 = dead_circumflex asciicircum bracketleft
keycode  35 = dead_cedilla dead_diaeresis bracketright

ALTGR + KeyCode34 (on a US keymap, it is the left bracket) should produce the
left bracket but no key events are generated.  The same keymap works perfectly
on every other linux jvm (blackdown's, ibm's...)

I am using the "/usr/share/xmodmap/xmodmap.qc" keymap on redhat 6.2

Here are the keyents generated after hitting ALTGR+[ on IBM's jdk1.3 :

java.awt.event.KeyEvent[KEY_PRESSED,keyCode=65406,Alt Graph] on frame0
java.awt.event.KeyEvent[KEY_PRESSED,keyCode=91,keyChar='['] on frame0
java.awt.event.KeyEvent[KEY_TYPED,keyCode=0,keyChar='['] on frame0
java.awt.event.KeyEvent[KEY_RELEASED,keyCode=65406,Alt Graph] on frame0
(Review ID: 108339) 

Name: krC82822			Date: 01/12/2001

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.0-FCS)
Java HotSpot(TM) Client VM (build Blackdown-1.3.0-FCS, mixed mode)
**Sun's JDK has the same bug. Please read below.**

Jdk 1.2.2 for Linux ./src/linux/native/sun/awt/canvas.c contains
an array of C structure named KeymapEntry.  The name of the array
is keymapTable.  The keymapTable array defines mapping between
Java VK symbols from KeyEvent class and X11 keysym symbols. Some
of the VK symbols defined in JDK 1.2 KeyEvent are missing from
the array.  Missing symbols are VK_CIRCUMFLEX, VK_AT, VK_COLON
and some other key symbols.  It is needless to say that those
corresponding X key symbols are also missing.  The keymapTable
array is used to derive awt keysym from Xt keysym and those
missing symbols comprise a bug due to which we the Japanese
jp106 keyboard users and some other non-US keyboard users can't
input such important symbol characters as at-mark, colon, asterisk,
grave, circumflex, etc.  For Linux Java 2 implementations from Sun
and the Blackdown, JDK 1.3.0 and 1.3.0_01(Sun's latest release) do
also have this bug.  We'd like to expect that the bug be dispelled
from the next 1.3.0_02 release.

write a simple program to read KeyEvent.keyChar.
(Review ID: 115054)

Name: yyT116575			Date: 01/18/2001

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

when using applet or java ide, like Forte, i can't write some chars.
Chars that i can't write are ()[], for the most problematic (imagine 
coding under Forte and can't put a ( or a [....)
Problem occurs when i start Notepad.jar demo, for example
(Review ID: 115400)

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper

SUGGESTED FIX ------- canvas.c ------- *** /tmp/dEoaadN Sat Apr 13 00:57:51 2002 --- canvas.c Sat Apr 13 00:53:46 2002 *************** *** 1060,1065 **** --- 1060,1068 ---- if (modifiers & java_awt_event_InputEvent_ALT_DOWN_MASK) { xevent->xkey.state |= awt_AltMask; } + if (modifiers & java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK) { + xevent->xkey.state |= awt_ModeSwitchMask; + } if (modifiers & java_awt_event_InputEvent_BUTTON1_DOWN_MASK) { xevent->xkey.state |= Button1Mask; } *************** *** 1582,1602 **** (jchar) (mapsToUnicodeChar ? keysym : java_awt_event_KeyEvent_CHAR_UNDEFINED), modifiers, ! keyLocation, event); ! if ((keyEventId == java_awt_event_KeyEvent_KEY_PRESSED) && ! mapsToUnicodeChar) { ! awt_post_java_key_event(client_data, ! java_awt_event_KeyEvent_KEY_TYPED, ! NULL, ! event->xkey.time, ! java_awt_event_KeyEvent_VK_UNDEFINED, ! (jchar) keysym, ! modifiers, ! java_awt_event_KeyEvent_KEY_LOCATION_UNKNOWN, ! event); } } } --- 1585,1640 ---- (jchar) (mapsToUnicodeChar ? keysym : java_awt_event_KeyEvent_CHAR_UNDEFINED), modifiers, ! keyLocation, ! event); ! /* If this was a keyPressed event, we may need to post a ! * keyTyped event, too. Otherwise, return. ! */ ! if (keyEventId == java_awt_event_KeyEvent_KEY_RELEASED) { ! return; ! } ! DTRACE_PRINTLN("This is a keyPressed event"); ! /* Now get real keysym which looks at modifiers for keyTyped event. ! * XtGetActionKeySym() returns wrong value with Kana Lock, ! * so use XtTranslateKeycode(). ! */ ! XtTranslateKeycode(event->xkey.display, (KeyCode) event->xkey.keycode, ! event->xkey.state, &mods, &keysym); ! DTRACE_PRINTLN6("%s: type=%d, xkeycode=%x, xstate=%x, keysym=%x, xmods=%d", ! "In handleKeyEvent keysym>=256 ", event->type, event->xkey.keycode, ! event->xkey.state, keysym, mods); ! ! if (keysym == NoSymbol) { ! return; } + + /* Map the real keysym to a Java keycode */ + keysymToAWTKeyCode(keysym, &keycode, &mapsToUnicodeChar, &keyLocation); + DTRACE_PRINTLN3("In handleKeyEvent: keysym=%x, AWTkeycode=%x, mapsToUnicodeChar=%d", + keysym, keycode, mapsToUnicodeChar); + + /* If it doesn't map to a Unicode character, don't post a keyTyped event */ + if (!mapsToUnicodeChar) { + return; + } + + handleVendorKeySyms(event, &keysym); + adjustKeySym(event, &keysym); + DTRACE_PRINT4("In handleKeyEvent: type=%d, xkeycode=%x, xstate=%x, keysym=%x", + event->type, event->xkey.keycode, event->xkey.state, keysym); + DTRACE_PRINTLN2(", AWTkeycode=%x, AWTmodifiers=%d", keycode, modifiers); + + awt_post_java_key_event(client_data, + java_awt_event_KeyEvent_KEY_TYPED, + NULL, + event->xkey.time, + java_awt_event_KeyEvent_VK_UNDEFINED, + (jchar) keysym, + modifiers, + java_awt_event_KeyEvent_KEY_LOCATION_UNKNOWN, + event); } } ###@###.### 2002-04-14

EVALUATION The entries for VK_AT, VK_CIRCUMFLEX, VK_COLON, etc., have already been added to the keymap table in Merlin and Ladybird. This is probably not the cause of the original complaint about the dead keys, since none of these are dead keys (circumflex is not the same as dead circumflex). It would be nice to know what locales the original submitter was using (if that is applicable to his Linux distribution). eric.hawkes@eng 2001-01-15 The modmap the submitter is using is the French Canadian modmap, according to the comments in the modmap file. eric.hawkes@eng 2001-02-08 There seem to be three separate bugs in this report. The one about VK_AT, VK_CIRCUMFLEX, VK_COLON, etc. is a duplicate of 4347983 (see also 4295215). I have asked that the one about ()[] be decomposed into a separate bug report. I will need more information, such as the locale, keyboard, and xmodmap before I can investigate it. eric.hawkes@eng 2001-02-23 I tried the French Canadian xmodmap with a US keyboard under linux and merlin build 53 (the modmap is a /usr/share/xmodmap/xmodmap.qc). The dead key seemed to work more-or-less correctly in that the correct characters appeared in the textfield. [ then e produced an e with a circumflex over it. ] then c produced a c with a cedilla shift [ resulted in ^ shift ] then e resulted in an e with an umlaut over it In these four cases, the events for the dead keys were not present, but the events for the other keys were. The right Alt key served as an AltGraph. AltGr [ produced [ AltGr ] produced ] but as the submitter said, key events were seen only for AltGraph, not for [ and ] Since the characters were correctly generated, I'm leaving this as a P4. eric.hawkes@eng 2001-02-24 I am now concerned that the characters could not be entered into Swing components, although they would be entered into AWT components. Raising priority to P3. BTW, this could possibly be solved by 4423661. eric.hawkes@eng 2001-03-08 Probably fixed in merlin, but we should verify after beta3. ###@###.### 2001-08-25 Apparently, this still exists in Merlin. I see two problems: 1) in canvas.c modify_Event, we aren't OR-ing in the ALT_GRAPH_DOWN modifier. 2) I think the way we determine whether we need to post a KEY_TYPED event is wrong. I believe we are determinging the value of mapsToUnicodeChar by translating the keysym without modifiers, when we need to take them into account. In the case of the french canadian keyboard, this is a problem: You type a bracketright by AltGraph - dead_cedilla. dead_cedilla is a dead key, and therefore does not map to a unicode character. However, we should be posting a KEY_TYPED event for bracketright here. The solution is to translate the keysym using the modifiers (shift or AltGr), and post a KEY_TYPED (or not) based on that outcome. ###@###.### 2002-03-01 Since a French Canadian keyboard is necessary to verify this fix, it will not be necessary for SQE to verify this bug. ###@###.### 2002-04-17