[PATCH 2.5.59] support japanese JP106 keyboard on new console.

[PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Hiroshi Miura]

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. --- miurahr@nttdata.co.jp 
Key fingerprint = 9117 9407 5684 FBF1 4063  15B4 401D D077 04AB 8617
-- My hacking life is happy as the day is long

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Vojtech Pavlik]

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. --- miurahr@nttdata.co.jp 
> 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

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Osamu Tomita]

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. --- miurahr@nttdata.co.jp
> 
> --
> Vojtech Pavlik
> SuSE Labs

Regard,
Osamu Tomita

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[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

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Vojtech Pavlik]

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

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[John Bradford]

> > > > --- 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.

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Vojtech Pavlik]

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

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[John Bradford]

> > 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.

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Vojtech Pavlik]

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

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Osamu Tomita]

[-- Attachment #1: Type: text/plain, Size: 2852 bytes --]

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

[-- Attachment #2: jp-kbd-spec.tar.bz2 --]
[-- Type: application/octet-stream, Size: 34104 bytes --]

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Vojtech Pavlik]

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

Set2 scancodes for Japanese keyboard

[John Bradford]

> > > 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

[Corrected] Set2 scancodes for Japanese keyboard

[John Bradford]

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

Re: [Corrected] Set2 scancodes for Japanese keyboard

[Vojtech Pavlik]

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

Re: [Corrected] Set2 scancodes for Japanese keyboard

[John Bradford]

> 
> 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.

Re: [Corrected] Set2 scancodes for Japanese keyboard

[Vojtech Pavlik]

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

Re: [Corrected] Set2 scancodes for Japanese keyboard

[John Bradford]

> > > 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.

Re: [Corrected] Set2 scancodes for Japanese keyboard

[Andries Brouwer]

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

Re: [Corrected] Set2 scancodes for Japanese keyboard

[Vojtech Pavlik]

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

Set3 scancodes for Japanese keyboard

[John Bradford]

> > > 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.

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Hiroshi Miura]

Hi, Mr. Tomita,


In message "Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console."
    on 03/01/25, Osamu Tomita <tomita@cinet.co.jp> 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

 

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Vojtech Pavlik]

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 <tomita@cinet.co.jp> 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

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[John Bradford]

> > 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.

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Vojtech Pavlik]

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

Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console.

[Hiroshi Miura]

In message "Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console."
    on 03/02/02, Vojtech Pavlik <vojtech@suse.cz> 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