Korean/latin key(Hangul key) doesn't work.

This is well-known and long-time #1 (IMO) issue for Korean users who have Hangul/English toggle (ATKBD_RET_HANGUEL) and Hanja Keys(ATKBD_RET_HANJA) on their keyboards. Users have to set up their own settings with setkeycodes and xmodmap to make the two keys work with IMs. One point I put a table for this issue into the BetterCJKSpecification wiki because of importance and first impression to users. Further, I'd like to ask and get answers how to avoid user settings for both setkeycodes and xmodmap as well.

At this moment, however this reporting is about current kernel in Dapper doesn't support setkeycodes part especially. I heard same thing from couple of experienced users and drivers/input/keyboard/atkbd.c was narrow pointed for this bug which seems missing scancode of the keys and bypassing KERN_WARNING (But, I am afraid giving wrong information).

post a mail to ubuntu-devel.

https://lists.ubuntu.com/archives/ubuntu-devel/2006-March/016356.html

Ben, please get this into Dapper unless you have an objection, in which case, get in touch with nahs to resolve the issue

it wasn't a problem of kernels. xserver-xorg-input-keyboard was the problem.

I compare it with gentoo source and that's the results.

input-keyboard-1.0.1.3/src/kbd.c kbd.c -Nur
--- ../../../xserver-xorg-input-keyboard-1.0.1.3/src/kbd.c 2006-03-11
17:55:31.000000000 +0900
+++ kbd.c 2005-11-10 06:31:23.000000000 +0900
@@ -770,7 +770,7 @@
   /*
    * check for an autorepeat-event
    */
- if (down && KeyPressed(keycode) && keycode < 146) {
+ if (down && KeyPressed(keycode)) {
       int num = keycode >> 3;
       int bit = 1 << (keycode & 7);

@@ -783,25 +783,11 @@
    if (UsePrefix) {
       xf86PostKeyboardEvent(device,
               keyc->modifierKeyMap[keyc->maxKeysPerModifier*7], TRUE);
- if (keycode < 146) {
- xf86PostKeyboardEvent(device, keycode, down);
- } else if (down) {
- /* If it's a key down event, send a down and up. Otherwise
- drop it */
- xf86PostKeyboardEvent(device, keycode, TRUE);
- xf86PostKeyboardEvent(device, keycode, FALSE);
- }
+ xf86PostKeyboardEvent(device, keycode, down);
       xf86PostKeyboardEvent(device,
               keyc->modifierKeyMap[keyc->maxKeysPerModifier*7], FALSE);
    } else {
- if (keycode < 146) {
- xf86PostKeyboardEvent(device, keycode, down);
- } else if (down) {
- /* If it's a key down event, send a down and up.
Otherwise
- drop it */
- xf86PostKeyboardEvent(device, keycode, TRUE);
- xf86PostKeyboardEvent(device, keycode, FALSE);
- }
+ xf86PostKeyboardEvent(device, keycode, down);
    }
 }

in ubuntu source there are some exception over 146 keycodes.
 hangul / Eng key is keycodes 210. so excption make hangul key doens't work.

For completely solve the hangul key problem. follow must be fixed.

1. kernel must recognize hangul key(scancode 0x71 and 0x72) without setkeycodes 71 122 72 123

2. xserver-xorg-input-keyboard must be fixed.

3. /usr/include/X11/keysymdef.h file must be edited to give hangulkey correct keysym.

4. /etc/X11/xkb must be modified(especially keycodes/xfree86, keycodes 121 and 122 allocate hangulkey and hangul_hanja but, it's not right)

5. xkb keymap for korean keyboard must be made.

6. PS/2 keyboard, and usb keyboard must have same keycodes.

Tested ps/2 and usb type keyboards with 20060328 Daily CD, usb one shows switched keycodes - 209 for Hangul and 210 for Hanja - as our research.

Please review handrake's research about usb keyboard driver on his wiki, and hope this problem should be fixed soon.

The X and debian-installer part of this bug should be fixed now.

Can anyone confirm whether there is still a problem in Dapper, and if so, whether the kernel still needs a patch?

Matthew, wasn't this X patch an intentional effort to fix another bug, which will now have regressed?

We - Ubuntu Korean Team - strongly believe that the keycodes 122, 123 on the kernel USB Keyboard driver need to be in descending order (123, 122) to keep one kr symbols file. And, the patch for atkbd.c on Handrake's wiki is much clean code to ALWAYS keep same scancodes so that hope it's applied too at same time.

With 20060328 Daily CD, test for ps/2 type keyboard was OK, and anytime we'd be happy to test further fixes.

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this linux-source-2.6.15 kernel bug to the new "linux" package. We appreciate your patience and understanding as we make this transition. Also, if you would be interested in testing the upcoming Intrepid Ibex 8.10 release, it is available at http://www.ubuntu.com/testing . Please let us know your results. Thanks!

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Unfortunately this bug report is being closed because we received no response to the last inquiry for information. However, the Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm this is still an issue with this most recent release please feel free to reopen this report. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks.