Hi,
After re-writting a console layer, a japanese keyboard is not supported (or degraded).
This patch fixs it.
A USB keyboard driver may have same problem, but I don't have one.
--- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
+++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
@@ -309,6 +309,12 @@
if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
atkbd->oldset = 2;
+ if (atkbd->id == 0xab02) {
+ printk("atkbd: jp109(106) keyboard found\n");
+ param[0] = atkbd_set;
+ atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
+ return 5;
+ }
/*
* For known special keyboards we can go ahead and set the correct set.
* We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
@@ -531,6 +537,12 @@
else
memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
+ if (atkbd->set == 5) {
+ atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
+ atkbd->keycode[0x6a] = 0x7c; /* Yen, pipe 124*/
+ atkbd->set = 2;
+ }
+
atkbd->dev.name = atkbd->name;
atkbd->dev.phys = atkbd->phys;
atkbd->dev.id.bustype = BUS_I8042;
@@ -544,7 +556,7 @@
input_register_device(&atkbd->dev);
- printk(KERN_INFO "input: %s on %s\n", atkbd->name, serio->phys);
+ printk(KERN_INFO "input: %s (0x%x) on %s\n", atkbd->name, atkbd->id, serio->phys);
}
--
Hiroshi Miura --- http://www.da-cha.org/
NTTDATA Corp. Marketing & Business Strategy Planning Dept. --- [email protected]
Key fingerprint = 9117 9407 5684 FBF1 4063 15B4 401D D077 04AB 8617
-- My hacking life is happy as the day is long
On Fri, Jan 24, 2003 at 12:14:53PM +0900, Hiroshi Miura wrote:
> After re-writting a console layer, a japanese keyboard is not supported (or degraded).
> This patch fixs it.
This patch doesn't work, all normal keyboards - not just japanese ones have id of 0xab02.
> A USB keyboard driver may have same problem, but I don't have one.
>
> --- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
> +++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
> @@ -309,6 +309,12 @@
> if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
> atkbd->oldset = 2;
>
> + if (atkbd->id == 0xab02) {
> + printk("atkbd: jp109(106) keyboard found\n");
> + param[0] = atkbd_set;
> + atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
> + return 5;
> + }
> /*
> * For known special keyboards we can go ahead and set the correct set.
> * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
> @@ -531,6 +537,12 @@
> else
> memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
>
> + if (atkbd->set == 5) {
> + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> + atkbd->keycode[0x6a] = 0x7c; /* Yen, pipe 124*/
> + atkbd->set = 2;
> + }
> +
> atkbd->dev.name = atkbd->name;
> atkbd->dev.phys = atkbd->phys;
> atkbd->dev.id.bustype = BUS_I8042;
> @@ -544,7 +556,7 @@
>
> input_register_device(&atkbd->dev);
>
> - printk(KERN_INFO "input: %s on %s\n", atkbd->name, serio->phys);
> + printk(KERN_INFO "input: %s (0x%x) on %s\n", atkbd->name, atkbd->id, serio->phys);
> }
>
>
> --
> Hiroshi Miura --- http://www.da-cha.org/
> NTTDATA Corp. Marketing & Business Strategy Planning Dept. --- [email protected]
> Key fingerprint = 9117 9407 5684 FBF1 4063 15B4 401D D077 04AB 8617
> -- My hacking life is happy as the day is long
--
Vojtech Pavlik
SuSE Labs
Please fix atkbd_set2_keycode table in atkbd.c for jp106 keyboard.
Vojtech Pavlik wrote:
>
> On Fri, Jan 24, 2003 at 12:14:53PM +0900, Hiroshi Miura wrote:
>
> > After re-writting a console layer, a japanese keyboard is not supported (or degraded).
> > This patch fixs it.
>
> This patch doesn't work, all normal keyboards - not just japanese ones have id of 0xab02.
I agree this point. It's difficult to detect jp106 keyboard automatically.
Many venders use common internal circuits with us keyborad.
> > A USB keyboard driver may have same problem, but I don't have one.
> >
> > --- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
> > +++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
> > @@ -309,6 +309,12 @@
> > if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
> > atkbd->oldset = 2;
> >
> > + if (atkbd->id == 0xab02) {
> > + printk("atkbd: jp109(106) keyboard found\n");
> > + param[0] = atkbd_set;
> > + atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
> > + return 5;
> > + }
> > /*
> > * For known special keyboards we can go ahead and set the correct set.
> > * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
> > @@ -531,6 +537,12 @@
> > else
> > memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
> >
> > + if (atkbd->set == 5) {
> > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> > + atkbd->keycode[0x6a] = 0x7c; /* Yen, pipe 124*/
I think he catches good point. Kernel 2.0-2.4 use keycode 124 (0x7c) for scancode 0x6a.
2.5 uses keycode 183. This breaks jp106 keymaps. We cannot type '\' and '|' from jp106
keyboard on 2.5 kernel.
I believe there is no impact by changing keycode 183 to 124.
> >
> > --
> > Hiroshi Miura --- http://www.da-cha.org/
> > NTTDATA Corp. Marketing & Business Strategy Planning Dept. --- [email protected]
>
> --
> Vojtech Pavlik
> SuSE Labs
Regard,
Osamu Tomita
I have a question.
Hiroshi Miura wrote:
>
> Hi,
>
> After re-writting a console layer, a japanese keyboard is not supported (or degraded).
> This patch fixs it.
>
> A USB keyboard driver may have same problem, but I don't have one.
>
> --- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
> +++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
> @@ -309,6 +309,12 @@
> if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
> atkbd->oldset = 2;
>
> + if (atkbd->id == 0xab02) {
> + printk("atkbd: jp109(106) keyboard found\n");
> + param[0] = atkbd_set;
> + atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
> + return 5;
> + }
> /*
> * For known special keyboards we can go ahead and set the correct set.
> * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
> @@ -531,6 +537,12 @@
> else
> memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
>
> + if (atkbd->set == 5) {
> + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
I'm interesting in the reason to use keycode 0x70 for 'Hiragana/Katakana' key.
Please clarify.
Regard,
Osamu Tomita
On Sat, Jan 25, 2003 at 02:03:56AM +0900, Osamu Tomita wrote:
> Please fix atkbd_set2_keycode table in atkbd.c for jp106 keyboard.
>
> Vojtech Pavlik wrote:
> >
> > On Fri, Jan 24, 2003 at 12:14:53PM +0900, Hiroshi Miura wrote:
> >
> > > After re-writting a console layer, a japanese keyboard is not supported (or degraded).
> > > This patch fixs it.
> >
> > This patch doesn't work, all normal keyboards - not just japanese ones have id of 0xab02.
> I agree this point. It's difficult to detect jp106 keyboard automatically.
> Many venders use common internal circuits with us keyborad.
>
> > > A USB keyboard driver may have same problem, but I don't have one.
> > >
> > > --- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
> > > +++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
> > > @@ -309,6 +309,12 @@
> > > if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
> > > atkbd->oldset = 2;
> > >
> > > + if (atkbd->id == 0xab02) {
> > > + printk("atkbd: jp109(106) keyboard found\n");
> > > + param[0] = atkbd_set;
> > > + atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
> > > + return 5;
> > > + }
> > > /*
> > > * For known special keyboards we can go ahead and set the correct set.
> > > * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
> > > @@ -531,6 +537,12 @@
> > > else
> > > memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
> > >
> > > + if (atkbd->set == 5) {
> > > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> > > + atkbd->keycode[0x6a] = 0x7c; /* Yen, pipe 124*/
> I think he catches good point. Kernel 2.0-2.4 use keycode 124 (0x7c) for scancode 0x6a.
> 2.5 uses keycode 183. This breaks jp106 keymaps. We cannot type '\' and '|' from jp106
> keyboard on 2.5 kernel.
> I believe there is no impact by changing keycode 183 to 124.
Well, it's not so easy. Fortunately KEY_KPCOMMA can be relatively easily
moved elsewhere, however keys 181 to 198 are 'international and language
keys', defined the same way as USB/HID spec (please take a look at it).
Having a single one of them remapped elsewhere doesn't look so nice.
--
Vojtech Pavlik
SuSE Labs
> > > > --- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
> > > > +++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
> > > > @@ -309,6 +309,12 @@
> > > > if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
> > > > atkbd->oldset = 2;
> > > >
> > > > + if (atkbd->id == 0xab02) {
> > > > + printk("atkbd: jp109(106) keyboard found\n");
> > > > + param[0] = atkbd_set;
> > > > + atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
> > > > + return 5;
> > > > + }
> > > > /*
> > > > * For known special keyboards we can go ahead and set the correct set.
> > > > * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
> > > > @@ -531,6 +537,12 @@
> > > > else
> > > > memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
> > > >
> > > > + if (atkbd->set == 5) {
> > > > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> > > > + atkbd->keycode[0x6a] = 0x7c; /* Yen, pipe 124*/
> > I think he catches good point. Kernel 2.0-2.4 use keycode 124 (0x7c) for scancode 0x6a.
> > 2.5 uses keycode 183. This breaks jp106 keymaps. We cannot type '\' and '|' from jp106
> > keyboard on 2.5 kernel.
> > I believe there is no impact by changing keycode 183 to 124.
>
> Well, it's not so easy. Fortunately KEY_KPCOMMA can be relatively easily
> moved elsewhere, however keys 181 to 198 are 'international and language
> keys', defined the same way as USB/HID spec (please take a look at it).
> Having a single one of them remapped elsewhere doesn't look so nice.
The keymapping on my Japanese keyboard changes quite a bit when it's
set up to use set 3, instead of the default set 2. I've temporarily
switched back to using set 2, until I've got time to set it up
properly, but the language keys don't function in set 2, (they
generate the same scancode as the space bar).
Let me know if I can provide any extra info from this keyboard - it's
an IBM 5576 Keyboard-2, part number 94X1110.
John.
On Sat, Jan 25, 2003 at 10:51:44AM +0000, John Bradford wrote:
> > > > > --- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
> > > > > +++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
> > > > > @@ -309,6 +309,12 @@
> > > > > if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
> > > > > atkbd->oldset = 2;
> > > > >
> > > > > + if (atkbd->id == 0xab02) {
> > > > > + printk("atkbd: jp109(106) keyboard found\n");
> > > > > + param[0] = atkbd_set;
> > > > > + atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
> > > > > + return 5;
> > > > > + }
> > > > > /*
> > > > > * For known special keyboards we can go ahead and set the correct set.
> > > > > * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
> > > > > @@ -531,6 +537,12 @@
> > > > > else
> > > > > memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
> > > > >
> > > > > + if (atkbd->set == 5) {
> > > > > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> > > > > + atkbd->keycode[0x6a] = 0x7c; /* Yen, pipe 124*/
> > > I think he catches good point. Kernel 2.0-2.4 use keycode 124 (0x7c) for scancode 0x6a.
> > > 2.5 uses keycode 183. This breaks jp106 keymaps. We cannot type '\' and '|' from jp106
> > > keyboard on 2.5 kernel.
> > > I believe there is no impact by changing keycode 183 to 124.
> >
> > Well, it's not so easy. Fortunately KEY_KPCOMMA can be relatively easily
> > moved elsewhere, however keys 181 to 198 are 'international and language
> > keys', defined the same way as USB/HID spec (please take a look at it).
> > Having a single one of them remapped elsewhere doesn't look so nice.
>
> The keymapping on my Japanese keyboard changes quite a bit when it's
> set up to use set 3, instead of the default set 2. I've temporarily
> switched back to using set 2, until I've got time to set it up
> properly, but the language keys don't function in set 2, (they
> generate the same scancode as the space bar).
>
> Let me know if I can provide any extra info from this keyboard - it's
> an IBM 5576 Keyboard-2, part number 94X1110.
If you can provide the complete key -> scancode table for that keyboard,
or at least differences against standard US keyboard for both set 2 and
set 3, that'd be great.
--
Vojtech Pavlik
SuSE Labs
On Sat, Jan 25, 2003 at 01:10:36PM +0000, John Bradford wrote:
> > > The keymapping on my Japanese keyboard changes quite a bit when it's
> > > set up to use set 3, instead of the default set 2. I've temporarily
> > > switched back to using set 2, until I've got time to set it up
> > > properly, but the language keys don't function in set 2, (they
> > > generate the same scancode as the space bar).
> > >
> > > Let me know if I can provide any extra info from this keyboard - it's
> > > an IBM 5576 Keyboard-2, part number 94X1110.
> >
> > If you can provide the complete key -> scancode table for that keyboard,
> > or at least differences against standard US keyboard for both set 2 and
> > set 3, that'd be great.
>
> OK, half way through writing it down, I've realised what is happening
> - in set 2, the keyboard seems to be emulating another keyboard
> layout, (but apparently not a US or UK one).
>
> For example, ; and : are on different keys. Shift ; gives + and shift
> : gives *
>
> The keycodes generated, though, show up as follows:
>
> ; - 39
> shift ; (+) - 13
> : - 42, 39, release 39, release 42
> shift : (*) - 9
>
> So, if I press : on it's own, the keyboard actually simulates pressing
> shift and ;
>
> Likewise, if I press right-shift and @ to get ` the keyboard actually
> sends a release 54 as soon as I press @, even though I'm still holding
> down right-shift, then sends 41, release 41, then 54
Yeah, I've seen this before on some weird keyboards. We need to make
sure we understand properly decode what the keyboard is pretending to be
- no need to really detect what keys were pressed in reality and what
the keyboard just wants us to think are pressed.
> I suspect set 3 will producde a more direct mapping of a single
> keycode for each key, but we shall see...
I hope so.
> I'll send along the complete list when I've finished it, (it's taking
> ages :-) ).
--
Vojtech Pavlik
SuSE Labs
> > The keymapping on my Japanese keyboard changes quite a bit when it's
> > set up to use set 3, instead of the default set 2. I've temporarily
> > switched back to using set 2, until I've got time to set it up
> > properly, but the language keys don't function in set 2, (they
> > generate the same scancode as the space bar).
> >
> > Let me know if I can provide any extra info from this keyboard - it's
> > an IBM 5576 Keyboard-2, part number 94X1110.
>
> If you can provide the complete key -> scancode table for that keyboard,
> or at least differences against standard US keyboard for both set 2 and
> set 3, that'd be great.
OK, half way through writing it down, I've realised what is happening
- in set 2, the keyboard seems to be emulating another keyboard
layout, (but apparently not a US or UK one).
For example, ; and : are on different keys. Shift ; gives + and shift
: gives *
The keycodes generated, though, show up as follows:
; - 39
shift ; (+) - 13
: - 42, 39, release 39, release 42
shift : (*) - 9
So, if I press : on it's own, the keyboard actually simulates pressing
shift and ;
Likewise, if I press right-shift and @ to get ` the keyboard actually
sends a release 54 as soon as I press @, even though I'm still holding
down right-shift, then sends 41, release 41, then 54
I suspect set 3 will producde a more direct mapping of a single
keycode for each key, but we shall see...
I'll send along the complete list when I've finished it, (it's taking
ages :-) ).
John.
Vojtech Pavlik wrote:
>
> On Sat, Jan 25, 2003 at 02:03:56AM +0900, Osamu Tomita wrote:
> > Please fix atkbd_set2_keycode table in atkbd.c for jp106 keyboard.
> >
> > Vojtech Pavlik wrote:
> > >
> > > On Fri, Jan 24, 2003 at 12:14:53PM +0900, Hiroshi Miura wrote:
> > >
> > > > After re-writting a console layer, a japanese keyboard is not supported (or degraded).
> > > > This patch fixs it.
> > >
> > > This patch doesn't work, all normal keyboards - not just japanese ones have id of 0xab02.
> > I agree this point. It's difficult to detect jp106 keyboard automatically.
> > Many venders use common internal circuits with us keyborad.
> >
> > > > A USB keyboard driver may have same problem, but I don't have one.
> > > >
> > > > --- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
> > > > +++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-24 09:13:11.000000000 +0900
> > > > @@ -309,6 +309,12 @@
> > > > if (atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_GSCANSET))
> > > > atkbd->oldset = 2;
> > > >
> > > > + if (atkbd->id == 0xab02) {
> > > > + printk("atkbd: jp109(106) keyboard found\n");
> > > > + param[0] = atkbd_set;
> > > > + atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
> > > > + return 5;
> > > > + }
> > > > /*
> > > > * For known special keyboards we can go ahead and set the correct set.
> > > > * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
> > > > @@ -531,6 +537,12 @@
> > > > else
> > > > memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));
> > > >
> > > > + if (atkbd->set == 5) {
> > > > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> > > > + atkbd->keycode[0x6a] = 0x7c; /* Yen, pipe 124*/
> > I think he catches good point. Kernel 2.0-2.4 use keycode 124 (0x7c) for scancode 0x6a.
> > 2.5 uses keycode 183. This breaks jp106 keymaps. We cannot type '\' and '|' from jp106
> > keyboard on 2.5 kernel.
> > I believe there is no impact by changing keycode 183 to 124.
>
> Well, it's not so easy. Fortunately KEY_KPCOMMA can be relatively easily
> moved elsewhere, however keys 181 to 198 are 'international and language
> keys', defined the same way as USB/HID spec (please take a look at it).
> Having a single one of them remapped elsewhere doesn't look so nice.
>
> --
> Vojtech Pavlik
> SuSE Labs
Thanks. I see. Keycode in the kernel should be unified.
I'll use newer kbd utility (kbd-1.08) and rewrite keymap like below.
keycode 124 = backslash bar #Compatibility for 2.4 (for a while)
keycode 183 = backslash bar
BTW. I've extracted japanese keyboard specification from OADG's documents.
About OADG, please visit http://www.oadg.org/.
I attach those files. Usefull?
-Regards,
Osamu Tomita
On Sun, Jan 26, 2003 at 12:29:15AM +0900, Osamu Tomita wrote:
> > Well, it's not so easy. Fortunately KEY_KPCOMMA can be relatively easily
> > moved elsewhere, however keys 181 to 198 are 'international and language
> > keys', defined the same way as USB/HID spec (please take a look at it).
> > Having a single one of them remapped elsewhere doesn't look so nice.
> >
> > --
> > Vojtech Pavlik
> > SuSE Labs
> Thanks. I see. Keycode in the kernel should be unified.
Definitely. And cast in stone and never changed again.
> I'll use newer kbd utility (kbd-1.08) and rewrite keymap like below.
> keycode 124 = backslash bar #Compatibility for 2.4 (for a while)
> keycode 183 = backslash bar
Yes, that'd be great.
> BTW. I've extracted japanese keyboard specification from OADG's documents.
> About OADG, please visit http://www.oadg.org/.
> I attach those files. Usefull?
Yes, I'm sure they'll be.
--
Vojtech Pavlik
SuSE Labs
> > > If you can provide the complete key -> scancode table for that keyboard,
> > > or at least differences against standard US keyboard for both set 2 and
> > > set 3, that'd be great.
Here are the set 2 ones, I've missed out most of the letter and number
keys, because they all followed the obvious numerical sequence. I'll
send the set 3 ones separately, (when I've typed them in :-) ).
Key
Keycode
Make scancode
Break scancode
Escape
1
0x01
0x81
F1
59
0x3b
0xbb
F10
68
0x44
0xc4
F11
87
0x57
0xd7
F12
88
0x58
0xd8
Printscreen?, (marked 'page', and something I can't read).
99
0xe0 0x2a 0xe0 0x37
0xe0 0xb7 0xe0 0xaa
Sys Rq, (alt and key above)
84
0x54
0xd4
Scroll lock
70
0x46
0xc6
Numlock, (shift scroll lock)
69
0x45
0xc5
Pause
119
0xe1 0x1d 0x45
0xe1 0x9d 0xc5
Break
101
0xe0 0x46
0xe0 0xc6
Hankaku/Zenkaku
None
0xff
none
1
2
0x02
0x83
0
11
0x0b
0x8b
-
12
0x0c
0x8c
shift -
13
0xb6 0x0d
0x8d 0x36
^
42,7
0x2a 0x07
0x8 0xaa
shift ^
none
0xff
none
yen
none
0xff
none
shift yen ( | )
43
0x2b
0xab
backspace
14
0x0e
0x8e
tab
15
0x0f
0x8f
q
16
0x10
0x90
p
25
0x19
0x99
@
42,3
0x2a 0x03
0x83 0xaa
shift @
release 54, 41, release 41, 54
0xb6 0x29
0xa9 0x36
[
26
0x1a
0x9a
enter
28
0x1c
0x9c
caps lock
58
0x3a
0xba
a
30
0x1e
0xae
l
38
0x26
0xa6
;
39
0x27
0xa7
shift ; ( + )
13
0x0d
0x8d
:
42 39
0x2a 0x27
0xa7 0xaa
shift : ( * )
9
0x09
0x89
]
27
0x1b
0x9b
left shift 42
0x2a
0xaa
z
44
0x2c
0xad
m
50
0x32
0xb2
,
51
0x33
0xb3
On Sat, Jan 25, 2003 at 05:28:25PM +0000, John Bradford wrote:
> Some got missed off the first time:
What kernel this is tested with? What method used? These don't look like
Set2 codes AT ALL.
>
> Key
> Keycode
> Make scancode
> Break scancode
>
> Escape
> 1
> 0x01
> 0x81
>
> F1
> 59
> 0x3b
> 0xbb
>
> F10
> 68
> 0x44
> 0xc4
>
> F11
> 87
> 0x57
> 0xd7
>
> F12
> 88
> 0x58
> 0xd8
>
> Printscreen?, (marked 'page', and something I can't read).
> 99
> 0xe0 0x2a 0xe0 0x37
> 0xe0 0xb7 0xe0 0xaa
>
> Sys Rq, (alt and key above)
> 84
> 0x54
> 0xd4
>
> Scroll lock
> 70
> 0x46
> 0xc6
>
> Numlock, (shift scroll lock)
> 69
> 0x45
> 0xc5
>
> Pause
> 119
> 0xe1 0x1d 0x45
> 0xe1 0x9d 0xc5
>
> Break
> 101
> 0xe0 0x46
> 0xe0 0xc6
>
> Hankaku/Zenkaku
> None
> 0xff
> none
>
> 1
> 2
> 0x02
> 0x83
>
> 0
> 11
> 0x0b
> 0x8b
>
> -
> 12
> 0x0c
> 0x8c
>
> shift -
> 13
> 0xb6 0x0d
> 0x8d 0x36
>
> ^
> 42,7
> 0x2a 0x07
> 0x8 0xaa
>
> shift ^
> none
> 0xff
> none
>
> yen
> none
> 0xff
> none
>
> shift yen ( | )
> 43
> 0x2b
> 0xab
>
> backspace
> 14
> 0x0e
> 0x8e
>
> tab
> 15
> 0x0f
> 0x8f
>
> q
> 16
> 0x10
> 0x90
>
> p
> 25
> 0x19
> 0x99
>
> @
> 42,3
> 0x2a 0x03
> 0x83 0xaa
>
> shift @
> release 54, 41, release 41, 54
> 0xb6 0x29
> 0xa9 0x36
>
> [
> 26
> 0x1a
> 0x9a
>
> enter
> 28
> 0x1c
> 0x9c
>
> caps lock
> 58
> 0x3a
> 0xba
>
> a
> 30
> 0x1e
> 0xae
>
> l
> 38
> 0x26
> 0xa6
>
> ;
> 39
> 0x27
> 0xa7
>
> shift ; ( + )
> 13
> 0x0d
> 0x8d
>
> :
> 42 39
> 0x2a 0x27
> 0xa7 0xaa
>
> shift : ( * )
> 9
> 0x09
> 0x89
>
> ]
> 27
> 0x1b
> 0x9b
>
> left shift 42
> 0x2a
> 0xaa
>
> z
> 44
> 0x2c
> 0xad
>
> m
> 50
> 0x32
> 0xb2
>
> ,
> 51
> 0x33
> 0xb3
--
Vojtech Pavlik
SuSE Labs
Some got missed off the first time:
Key
Keycode
Make scancode
Break scancode
Escape
1
0x01
0x81
F1
59
0x3b
0xbb
F10
68
0x44
0xc4
F11
87
0x57
0xd7
F12
88
0x58
0xd8
Printscreen?, (marked 'page', and something I can't read).
99
0xe0 0x2a 0xe0 0x37
0xe0 0xb7 0xe0 0xaa
Sys Rq, (alt and key above)
84
0x54
0xd4
Scroll lock
70
0x46
0xc6
Numlock, (shift scroll lock)
69
0x45
0xc5
Pause
119
0xe1 0x1d 0x45
0xe1 0x9d 0xc5
Break
101
0xe0 0x46
0xe0 0xc6
Hankaku/Zenkaku
None
0xff
none
1
2
0x02
0x83
0
11
0x0b
0x8b
-
12
0x0c
0x8c
shift -
13
0xb6 0x0d
0x8d 0x36
^
42,7
0x2a 0x07
0x8 0xaa
shift ^
none
0xff
none
yen
none
0xff
none
shift yen ( | )
43
0x2b
0xab
backspace
14
0x0e
0x8e
tab
15
0x0f
0x8f
q
16
0x10
0x90
p
25
0x19
0x99
@
42,3
0x2a 0x03
0x83 0xaa
shift @
release 54, 41, release 41, 54
0xb6 0x29
0xa9 0x36
[
26
0x1a
0x9a
enter
28
0x1c
0x9c
caps lock
58
0x3a
0xba
a
30
0x1e
0xae
l
38
0x26
0xa6
;
39
0x27
0xa7
shift ; ( + )
13
0x0d
0x8d
:
42 39
0x2a 0x27
0xa7 0xaa
shift : ( * )
9
0x09
0x89
]
27
0x1b
0x9b
left shift 42
0x2a
0xaa
z
44
0x2c
0xad
m
50
0x32
0xb2
,
51
0x33
0xb3
>
> On Sat, Jan 25, 2003 at 05:28:25PM +0000, John Bradford wrote:
>
> > Some got missed off the first time:
>
> What kernel this is tested with? What method used? These don't look like
> Set2 codes AT ALL.
The kernel is 2.4.20. The keycode is the output from showkey, and the
make and break codes are the output from showkey -s.
Should I have used I8042_DEBUG_IO instead? :-/
John.
On Sat, Jan 25, 2003 at 05:37:38PM +0000, John Bradford wrote:
> >
> > On Sat, Jan 25, 2003 at 05:28:25PM +0000, John Bradford wrote:
> >
> > > Some got missed off the first time:
> >
> > What kernel this is tested with? What method used? These don't look like
> > Set2 codes AT ALL.
>
> The kernel is 2.4.20. The keycode is the output from showkey, and the
> make and break codes are the output from showkey -s.
>
> Should I have used I8042_DEBUG_IO instead? :-/
With 2.5, yes, that'd be much better. And yet better it'd be if you'd
have used the "i8042_direct=1" kernel option, and for set3 the
"atkbd_set=3" option.
I'm sorry to tell you after you wrote it all down, but these are set1
scancodes you see.
--
Vojtech Pavlik
SuSE Labs
> > > What kernel this is tested with? What method used? These don't look like
> > > Set2 codes AT ALL.
> >
> > The kernel is 2.4.20. The keycode is the output from showkey, and the
> > make and break codes are the output from showkey -s.
> >
> > Should I have used I8042_DEBUG_IO instead? :-/
>
> With 2.5, yes, that'd be much better. And yet better it'd be if you'd
> have used the "i8042_direct=1" kernel option, and for set3 the
> "atkbd_set=3" option.
>
> I'm sorry to tell you after you wrote it all down, but these are set1
> scancodes you see.
I should have realised anyway - I remember now it translates
everything to set 1.
Oh dear, well, it might take a while - I packed my serial terminal
away yesterday, because a wire needs to be soldered on it :-), (which
explains why I was writing it all down :-) )
John.
On Sat, Jan 25, 2003 at 06:40:46PM +0100, Vojtech Pavlik wrote:
> I'm sorry to tell you after you wrote it all down, but these are set1
> scancodes you see.
What about "translated set2" ?
So far I have not yet seen cases where the translation was nonstandard.
That is, for all keyboards I have looked at or received reports on
the table given in
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-4.html#kscancodes
described the conversion from set2 to set1.
So, given the translated set2 codes, also the original set2 codes are
known with high probability. (The translation is almost 1-1.)
Andries
On Sat, Jan 25, 2003 at 08:48:04PM +0100, Andries Brouwer wrote:
> > I'm sorry to tell you after you wrote it all down, but these are set1
> > scancodes you see.
>
> What about "translated set2" ?
Correct.
> So far I have not yet seen cases where the translation was nonstandard.
> That is, for all keyboards I have looked at or received reports on
> the table given in
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-4.html#kscancodes
> described the conversion from set2 to set1.
>
> So, given the translated set2 codes, also the original set2 codes are
> known with high probability. (The translation is almost 1-1.)
Correct. Given set of not translated set2 codes, the translated set2
codes are created much easier, hence the not translated set2 codes offer
better value.
And, translated set3 just plain doesn't make sense.
--
Vojtech Pavlik
SuSE Labs
> > > What kernel this is tested with? What method used? These don't look like
> > > Set2 codes AT ALL.
> >
> > The kernel is 2.4.20. The keycode is the output from showkey, and the
> > make and break codes are the output from showkey -s.
> >
> > Should I have used I8042_DEBUG_IO instead? :-/
>
> With 2.5, yes, that'd be much better. And yet better it'd be if you'd
> have used the "i8042_direct=1" kernel option, and for set3 the
> "atkbd_set=3" option.
>
> I'm sorry to tell you after you wrote it all down, but these are set1
> scancodes you see.
Here are the set 3 scancodes for my Japanese keyboard.
If the set 2 codes are still of interest, I can do those as well, but
set 3 seems to be a much more useful mode, because there is a direct
mapping of keys to scancodes, instead of the more complicated
similated shift key codes that set 2 produces.
ESC 08 F0 08
F1 07 F0 07
F2 0F F0 0F
F3 17 F0 17
F4 1F F0 1F
F5 27 F0 27
F6 2F F0 2F
F7 37 F0 37
F8 3F F0 3F
F9 47 F0 47
F10 4F F0 4F
F11 56 F0 56
F12 5E F0 5E
HANKAKU/ZENKAKU 0E F0 0E
1 16 F0 16
2 1E F0 1E
3 26 F0 26
4 25 F0 25
5 2E F0 2E
6 36 F0 36
7 3D F0 3D
8 3E F0 3E
9 46 F0 46
0 45 F0 45
- 4E F0 4E
^ 55 F0 55
YEN 13 F0 13
BACKSPACE 66 F0 66
TAB 0D F0 0D
Q 15 F0 15
W 1D F0 1D
E 24 F0 24
R 2D F0 2D
T 2C F0 2C
Y 35 F0 35
U 3C F0 3C
I 43 F0 43
O 44 F0 44
P 4D F0 4D
@ 54 F0 54
[ 5B F0 5B
A 1C F0 1C
S 1B F0 1B
D 23 F0 23
F 2B F0 2B
G 34 F0 34
H 33 F0 33
J 3B F0 3B
K 42 F0 42
L 4B F0 4B
; 4C F0 4C
: 52 F0 52
] 53 F0 53
ENTER 5A F0 5A
LEFT SHIFT 12 F0 12
Z 1A F0 1A
X 22 F0 22
C 21 F0 21
V 2A F0 2A
B 32 F0 32
N 31 F0 31
M 3A F0 3A
, 41 F0 41
. 49 F0 49
/ 4A F0 4A
\ 5C F0 5C
RIGHT SHIFT 59 F0 59
LEFT CONTROL 11 F0 11
KANJI/KANAKANA 19 F0 19
MUHENKAN 85 F0 85
SPACE 29 F0 29
ZENKOHO/HENKAN (JIKOHO)/ZENKOHO 86 F0 86
HIRAGANA 87 F0 87
ZENMEN KI 39 F0 39
RIGHT CONTROL 58 F0 58
PAGE/SYSRQ 57 F0 57
SCROLL LOCK
5F <-
ED ->
FA <-
00 ->
FA <-
F0 <-
5F <-
SHIFT-SCROLL LOCK (NUMLOCK) 5F F0 5F
PAUSE/BREAK 62 F0 62
INSERT 67 F0 67
HOME 6E F0 6E
PAGE UP 6F F0 6F
DELETE 64 F0 64
END 65 F0 65
PAGE DOWN 6D F0 6D
CURSOR UP 63 F0 63
CURSOR DOWN 60 F0 60
CURSOR LEFT 61 F0 61
CURSOR RIGHT 69 F0 69
KEYPAD * 7E F0 7E
KEYPAD / 77 F0 77
KEYPAD ,
76 <-
ED ->
FA <-
00 ->
FA <-
F0 <-
76 <-
KEYPAD - 84 F0 84
KEYPAD + 7C F0 7C
KEYPAD ENTER 79 F0 79
KEYPAD . 71 F0 71
KEYPAD 0 70 F0 70
KEYPAD 1 69 F0 69
KEYPAD 2 72 F0 72
KEYPAD 3 7A F0 7A
KEYPAD 4 6B F0 6B
KEYPAD 5 73 F0 73
KEYPAD 6 74 F0 74
KEYPAD 7 6C F0 6C
KEYPAD 8 75 F0 75
KEYPAD 9 7D F0 7D
John.
Hi, Mr. Tomita,
In message "Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console."
on 03/01/25, Osamu Tomita <[email protected]> writes:
> I have a question.
>
> > + if (atkbd->set == 5) {
> > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> I'm interesting in the reason to use keycode 0x70 for 'Hiragana/Katakana' key.
> Please clarify.
This is answer for your question.
I have two point of view about this.
these are my try and error process.
First, I press Katakana_Hiragana key on console with 2.4.19, it warns
keyboard: unrecognized scancode (70) - ignored
Two, in a 2.4.20's pc_keyb.c, there is a comment,
/*
* The keycodes below are randomly located in 89-95,112-118,120-127.
* They could be thrown away (and all occurrences below replaced by 0),
* but that would force many users to use the `setkeycodes' utility, where
* they needed not before. It does not matter that there are duplicates, as
* long as no duplication occurs for any single keyboard.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*/
Hiragana_Katakana was not defined before and I want to define a keycode point.
When I saw 2.4.20 pc_keyb.c source, I found all keycode below 127 was used,
then there is no room. But the comment tell me I can use 120-123, 125-127 with
Japanese keyboard because these are not used on JP89/109 keyboards.
(124 is, as you know, Yen key) THese are defined for a latin keyboards.
So I use 120.
How do you think about it?
--
Hiroshi Miura
On Sat, Feb 01, 2003 at 10:54:29AM +0900, Hiroshi Miura wrote:
> Hi, Mr. Tomita,
>
>
> In message "Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console."
> on 03/01/25, Osamu Tomita <[email protected]> writes:
> > I have a question.
> >
> > > + if (atkbd->set == 5) {
> > > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */
> > I'm interesting in the reason to use keycode 0x70 for 'Hiragana/Katakana' key.
> > Please clarify.
>
> This is answer for your question.
>
> I have two point of view about this.
> these are my try and error process.
>
> First, I press Katakana_Hiragana key on console with 2.4.19, it warns
>
> keyboard: unrecognized scancode (70) - ignored
>
> Two, in a 2.4.20's pc_keyb.c, there is a comment,
> /*
> * The keycodes below are randomly located in 89-95,112-118,120-127.
> * They could be thrown away (and all occurrences below replaced by 0),
> * but that would force many users to use the `setkeycodes' utility, where
> * they needed not before. It does not matter that there are duplicates, as
> * long as no duplication occurs for any single keyboard.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> */
>
> Hiragana_Katakana was not defined before and I want to define a keycode point.
> When I saw 2.4.20 pc_keyb.c source, I found all keycode below 127 was used,
> then there is no room. But the comment tell me I can use 120-123, 125-127 with
> Japanese keyboard because these are not used on JP89/109 keyboards.
> (124 is, as you know, Yen key) THese are defined for a latin keyboards.
> So I use 120.
>
> How do you think about it?
In 2.4 you can, in 2.5 the 'as long as no duplication occurs for any
single keyboard' is not valid anymore, and the keycode for
hiragana/katakana is defined to be 183 I think.
--
Vojtech Pavlik
SuSE Labs
> > Hiragana_Katakana was not defined before and I want to define a
> > keycode point.
> > When I saw 2.4.20 pc_keyb.c source, I found all keycode below 127
> > was used, then there is no room. But the comment tell me I can use
> > 120-123, 125-127 with Japanese keyboard because these are not used
> > on JP89/109 keyboards.
> > (124 is, as you know, Yen key) THese are defined for a latin
> > keyboards. So I use 120.
> >
> > How do you think about it?
>
> In 2.4 you can, in 2.5 the 'as long as no duplication occurs for any
> single keyboard' is not valid anymore, and the keycode for
> hiragana/katakana is defined to be 183 I think.
We assigned 182 to hiragana/katakana for set 3 in 2.5, and left 183
undefined. Should we change the 2.5 keycode to 183?
John.
On Sun, Feb 02, 2003 at 10:38:21AM +0000, John Bradford wrote:
> > > Hiragana_Katakana was not defined before and I want to define a
> > > keycode point.
> > > When I saw 2.4.20 pc_keyb.c source, I found all keycode below 127
> > > was used, then there is no room. But the comment tell me I can use
> > > 120-123, 125-127 with Japanese keyboard because these are not used
> > > on JP89/109 keyboards.
> > > (124 is, as you know, Yen key) THese are defined for a latin
> > > keyboards. So I use 120.
> > >
> > > How do you think about it?
> >
> > In 2.4 you can, in 2.5 the 'as long as no duplication occurs for any
> > single keyboard' is not valid anymore, and the keycode for
> > hiragana/katakana is defined to be 183 I think.
>
> We assigned 182 to hiragana/katakana for set 3 in 2.5, and left 183
> undefined. Should we change the 2.5 keycode to 183?
No - just bad memory on my side, it might as well be 183. ;)
--
Vojtech Pavlik
SuSE Labs
In message "Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console."
on 03/02/02, Vojtech Pavlik <[email protected]> writes:
> In 2.4 you can, in 2.5 the 'as long as no duplication occurs for any
> single keyboard' is not valid anymore, and the keycode for
> hiragana/katakana is defined to be 183 I think.
I can understand the rule of international and language keys in 2.5.
I think hiragana/katakana is defined to be '182'.
The keycode 183 is a yen/pipe key.
--- linux-2.5.59/drivers/input/keyboard/atkbd.c 2002-12-03 07:59:41.000000000 +0900
+++ edited/linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-02-05 12:32:43.000000000 +0900
@@ -39,7 +39,7 @@
static unsigned char atkbd_set2_keycode[512] = {
0, 67, 65, 63, 61, 59, 60, 88, 0, 68, 66, 64, 62, 15, 41, 85,
- 0, 56, 42, 0, 29, 16, 2, 89, 0, 0, 44, 31, 30, 17, 3, 90,
+ 0, 56, 42,182, 29, 16, 2, 89, 0, 0, 44, 31, 30, 17, 3, 90,
0, 46, 45, 32, 18, 5, 4, 91, 0, 57, 47, 33, 20, 19, 6, 0,
0, 49, 48, 35, 34, 21, 7, 0, 0, 0, 50, 36, 22, 8, 9, 0,
0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0,
--
Hiroshi Miura