Description of problem: No event Version-Release number of selected component (if applicable): kbd-1.12-2 How reproducible: Steps to Reproduce: 1. execute xev 2. click Hangul , Hangul_Hanja key 3. Actual results: No event Expected results: KeyRelease event, serial 28, synthetic NO, window 0x3800001, root 0x38, subw 0x0, time 14397139, (113,113), root:(133,218), state 0x0, keycode 209 (keysym 0xff34, Hangul_Hanja), same_screen YES, XKeysymToKeycode returns keycode: 121 XLookupString gives 0 bytes: KeyPress event, serial 28, synthetic NO, window 0x3800001, root 0x38, subw 0x0, time 14402058, (113,113), root:(133,218), state 0x0, keycode 210 (keysym 0xff31, Hangul), same_screen YES, XKeysymToKeycode returns keycode: 122 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False Additional info: kernel-2.6.9-1.681_FC3 cat /etc/sysconfig/keyboard KEYBOARDTYPE="pc" KEYTABLE="us-acentos" $setkeycodes 71 122 $setkeycodes 72 123 $xmodmap -e 'keycode 210 = Hangul' $xmodmap -e 'keycode 209 = Hangul_Hanja'
After the setkeycodes commands, what is the output of (showkey -s) and (showkey -k) when run on the console?
Hangul / Hangul_Hanja * showkey -s 0xf2 / 0xf1 ----------------------------------------------------------- Hangul / Hangul_Hanja * showkey -k keycodes 123 press / keycodes 122 press keycodes 123 release / key codes 122 release
Thanks. It seems that the keycodes for Hangul and Hangul_Hanja (123/122) are reversed, Hangul should be, from looking at /usr/include/linux/input.h, keycode 122; but that's probably not the reason why xev doesn't show the keys. On the other hand, looking at /usr/X11R6/lib/X11/xkb/keycodes/xfree86, the keycodes should be 121/122; maybe I just don't understand XKB well enough. Anyway, the keys seems to be set up correctly enough on the console, so keys not showing up with xev should be solved within X.
Please report this problem directly to X.Org by filing a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to NEEDINFO, awaiting upstream bug report URL for tracking.
It's been over a month since our request for this to be reported to X.Org and nobody has provided a URL for us to track. I assume the problem has been resolved in an update, and nobody is interested in Red Hat tracking this any further. If the problem still exists however, and you do want Red Hat to track it follow the instructions in comment #4 above and set the status back to "REOPENED". Closing bug "CURRENTRELEASE", and assuming the problem is fixed due to lack of feedback/response.