Most recent kernel where this bug did not occur:
Distribution: Debian GNU/Linux unstable
Hardware Environment: i386
Software Environment:
Problem Description:

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.

in atkbd_interrupt(), 

		case ATKBD_RET_HANGUEL:
			atkbd_report_key(atkbd->dev, regs, KEY_HANGUEL, 3);
			goto out;
		case ATKBD_RET_HANJA:
			atkbd_report_key(atkbd->dev, regs, KEY_HANJA, 3);
			goto out;

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)
			set_bit(atkbd->keycode[i], input_dev->keybit);

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.

I propose 
(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.