Broken keycodes in recent kernels

Broken keycodes in recent kernels

[Andries.Brouwer]

Just received my tenth complaint this year about the fact
that kbd and recent kernels disagree as to what the right
keycodes are. Since I maintain kbd it follows that recent
kernels are broken.

What is right?
The old Linux convention is that for 1-88 keycode equals scancode.
Above that things are a bit messy, mainly because the 128 scancodes
xx and the 128 escaped scancodes e0 xx and the single combination
e1 1d 45 are put into 127 keycodes, and that doesnt fit.

OK. So we want at least to preserve this 1-88 range, and may worry
about the rest later. All common keys should keep their keycode.
See also setkeycodes(8).

2.6 does first an untranslate and then a map to keycode,
so the fact that keycode equals (translated) scancode
now becomes atkbd_set2_keycode[atkbd_unxlate_table[i]] == i
for i=1,...,88.

Looking at 2.6.0 we see a single mistake: scancode 84 is
translated incorrectly. And many Japanese complained.
Looking at 2.6.1-rc1 we see two mistakes: also scancode 85
is now mistranslated.

So, I think the change of 2.6.1-rc1 was not necessarily an
improvement, but 2.6.0 needs a fix.

I can look at the details, but perhaps Vojtech wants to comment.

Andries

Re: Broken keycodes in recent kernels

[Vojtech Pavlik]

On Fri, Jan 09, 2004 at 01:08:40AM +0100, Andries.Brouwer@cwi.nl wrote:
> 
> Just received my tenth complaint this year about the fact
> that kbd and recent kernels disagree as to what the right
> keycodes are. Since I maintain kbd it follows that recent
> kernels are broken.
> 
> What is right?
> The old Linux convention is that for 1-88 keycode equals scancode.
> Above that things are a bit messy, mainly because the 128 scancodes
> xx and the 128 escaped scancodes e0 xx and the single combination
> e1 1d 45 are put into 127 keycodes, and that doesnt fit.
> 
> OK. So we want at least to preserve this 1-88 range, and may worry
> about the rest later. All common keys should keep their keycode.
> See also setkeycodes(8).
> 
> 2.6 does first an untranslate and then a map to keycode,
> so the fact that keycode equals (translated) scancode
> now becomes atkbd_set2_keycode[atkbd_unxlate_table[i]] == i
> for i=1,...,88.
> 
> Looking at 2.6.0 we see a single mistake: scancode 84 is
> translated incorrectly. And many Japanese complained.
> Looking at 2.6.1-rc1 we see two mistakes: also scancode 85
> is now mistranslated.
> 
> So, I think the change of 2.6.1-rc1 was not necessarily an
> improvement, but 2.6.0 needs a fix.
> 
> I can look at the details, but perhaps Vojtech wants to comment.

I won't argue that the 2.6.1-rc situation is correct, but I'll describe
it and the difference from 2.4:

1) Keycode 84.

On 2.4, keycode 84 is the SysRq keycode, since historically AT keyboards
do emit a different keycode for SysRq than form PrintScreen, although
they're on the same key.

On 2.6, there is only one keycode for PrintScreen, in an attempt to be a
bit saner, and that is 99. And here comes my mistake - since 84 was not
used anymore, I used it for the "103rd" European key.

The 103rd key usually produces either backslash-bar or hash-tilde, or
other national combo. I believe that 2.4 did emit keycode 43 for it,
since this keyboard is treated the same as backslash by AT Set 2
keyboards, in hardware. 

USB keyboards, and Set 3 keyboards, however differentiate between this
key and the real backslash, and since there also can be the real
backslash in addition to this key on the keyboard, it makes sense to
allocate a scancode to it.

Now my snafu was that I allocated a 2.4-used scancode to it, and one
that is mapped to SAK in 2.4 keymaps usually.

This bites French, British and probably Brazilian people, too.

I'm open to suggestions about how to fix it.

2) Keycode 85.

Scancode 85 (translated, set2) at the moment is not mapped to any
keycode. There are other scancodes that are not mapped at all, only
known scancodes are mapped, the rest should be changed by the user.

Keycode 85 is defined as F13 (in keymaps), and is mapped to scancode 93
(both in atkbd.c and keyboard.c), which is F13, according to Microsoft
documentation, which was used as reference, since that's what keyboard
manufacturers tend to follow nowadays.

3) Japanese and Korean keys.

2.6 has unified support for Japanese and Korean keys on both USB and
PS/2 keyboards. 

The keycodes are defined as:

KEY_INTL1  181  /* Romanji */
KEY_INTL2  182  /* Hiragana / Katakana */
KEY_INTL3  183  /* Yen */
KEY_INTL4  184  /* Henkan */
KEY_INTL5  185  /* Muhenkan */
KEY_INTL6  186  /* PC9800 KP , */
KEY_LANG1  190  /* Hanguel */
KEY_LANG2  191  /* Hanja */
KEY_LANG3  192  /* Katakana */
KEY_LANG4  193  /* Hiragana */
KEY_LANG5  194  /* Zenkaku / Hankaku */

These keycodes are translated back to the PS/2 scancodes in raw mode.

The problem here lies in that that all the keycodes are above 128, and
are different from what 2.4 used for these keys on an AT keyboard. 

We could go back to the 2.4 layout, where the keycodes are scattered
where there was space in the translated set2 scancode list, and not even
all fit there, but I think that way lies madness. The 2.6 layout is
based on the USB HUT definition.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Broken keycodes in recent kernels

[OGAWA Hirofumi]

Vojtech Pavlik <vojtech@suse.cz> writes:

> KEY_INTL2  182  /* Hiragana / Katakana */
> KEY_INTL3  183  /* Yen */
> 
> These keycodes are translated back to the PS/2 scancodes in raw mode.

Sounds like 2.6.1 has the bug. 

Currently does,

HIRAGANA	INTL2(182)	7d
YEN		INTL2(182)	7d

But, these should be

HIRAGANA	INTL2(182)	70
YEN		INTL3(183)	7d

right? Patch are attached.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

 drivers/char/keyboard.c        |    2 +-
 drivers/input/keyboard/atkbd.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -puN drivers/input/keyboard/atkbd.c~keycode-fix drivers/input/keyboard/atkbd.c
--- linux-2.6.1/drivers/input/keyboard/atkbd.c~keycode-fix	2004-01-13 23:18:15.000000000 +0900
+++ linux-2.6.1-hirofumi/drivers/input/keyboard/atkbd.c	2004-01-13 23:18:43.000000000 +0900
@@ -55,7 +55,7 @@ static unsigned char atkbd_set2_keycode[
 	  0, 49, 48, 35, 34, 21,  7, 89,  0,  0, 50, 36, 22,  8,  9, 90,
 	  0, 51, 37, 23, 24, 11, 10,  0,  0, 52, 53, 38, 39, 25, 12,  0,
 	  0,181, 40,  0, 26, 13,  0,  0, 58, 54, 28, 27,  0, 43,  0,194,
-	  0, 86,193,192,184,  0, 14,185,  0, 79,182, 75, 71,124,  0,  0,
+	  0, 86,193,192,184,  0, 14,185,  0, 79,183, 75, 71,124,  0,  0,
 	 82, 83, 80, 76, 77, 72,  1, 69, 87, 78, 81, 74, 55, 73, 70, 99,
 
 	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
diff -puN drivers/char/keyboard.c~keycode-fix drivers/char/keyboard.c
--- linux-2.6.1/drivers/char/keyboard.c~keycode-fix	2004-01-13 23:18:59.000000000 +0900
+++ linux-2.6.1-hirofumi/drivers/char/keyboard.c	2004-01-13 23:19:26.000000000 +0900
@@ -947,7 +947,7 @@ static unsigned short x86_keycodes[256] 
 	360,261,262,263,298,376,100,101,321,316,373,286,289,102,351,355,
 	103,104,105,275,287,279,306,106,274,107,294,364,358,363,362,361,
 	291,108,381,281,290,272,292,305,280, 99,112,257,258,359,113,114,
-	264,117,271,374,379,115,125,273,121,123, 92,265,266,267,268,269,
+	264,117,271,374,379,115,112,125,121,123, 92,265,266,267,268,269,
 	120,119,118,277,278,282,283,295,296,297,299,300,301,293,303,307,
 	308,310,313,314,315,317,318,319,320,357,322,323,324,325,276,330,
 	332,340,365,342,343,344,345,346,356,270,341,368,369,370,371,372 };

_