Most recent kernel where this bug did not occur:
Distribution: Debian GNU/Linux unstable
Hardware Environment: i386
1. The scancodes are wrong, they are actually 0xF2 for Hanguel key and 0xF1 for
Hanja key respectively. In drivers/input/keyboard/atkbd.c
@@ -149,8 +149,8 @@
#define ATKBD_RET_EMUL0 0xe0
#define ATKBD_RET_EMUL1 0xe1
#define ATKBD_RET_RELEASE 0xf0
-#define ATKBD_RET_HANGUEL 0xf1
-#define ATKBD_RET_HANJA 0xf2
+#define ATKBD_RET_HANGUEL 0xf2
+#define ATKBD_RET_HANJA 0xf1
#define ATKBD_RET_ERR 0xff
#define ATKBD_KEY_UNKNOWN 0
2. There is a special-handling code for these two keys. But it actually does
not work because the keybit has no bit for KEY_HANGUEL and KEY_HANJA.
atkbd_report_key(atkbd->dev, regs, KEY_HANGUEL, 3);
atkbd_report_key(atkbd->dev, regs, KEY_HANJA, 3);
this actually does nothing because the only codes which are in the eycode table
are stored in the keybit. In atkbd_set_device_attrs():
for (i = 0; i < 512; i++)
if (atkbd->keycode[i] && atkbd->keycode[i] < ATKBD_SPECIAL)
This bug also causes another problem. The two keys work when I run "showkeycodes
71 123 72 122" but the keycodes does not matter; actually "showkeycodes 71 666
72 777" does the same thing. The atkbd driver always outputs 122 and 123 by
this special handling.
(1) to add set_bit(KEY_HANGUEL, input_dev->keybit) and set_bit(KEY_HANJA,
input_dev->keybit) so it correctly special-handles these keys, or
(2) to remove the special handling code and leave it to the user-space.
Steps to reproduce:
(1) press Hanguel/Hanja keys with a korean keyboard.
(2) "setkeycodes 71 123 72 122" and (1) again.
Created attachment 8282 [details]
corrected scancodes & adding two keycodes to the keybits
Created attachment 8283 [details]
Fix handling of HANGUEL/HANJA
I would appreciate if you could test this patch instead. It adjusts handling of
HANGUEL/HANJA so they can be remapped like other keys.
Good work. I have tested the patch and it works well.
Thank you for testing. I will get it in once 2.6.18 opens up.