2.6.0-test5 vs. Japanese keyboards

2.6.0-test5 vs. Japanese keyboards

[Norman Diamond]

In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:

> > What will it take this time?
>
> Posting the patch with any luck ?

I knew that that would not be sufficient.  On 2003.07.24, I think in the
days of 2.6.0-test1, junkio@cox.net posted a patch for Japanese PS/2
keyboards.  On 2003.08.31, in the days of 2.6.0-test4, I posted a revised
patch to include Japanese USB keyboards.  2.6.0-test5 includes neither of
them because the keyboard driver maintainers don't personally depend on
Japanese keyboards.

Since posting has not been sufficient, I beg Mr. Pavlik, just once per
release, please try pretending that you might have to depend on a Japanese
keyboard.  You don't have to use one daily as your colleague Dr. Fabian
does.  Just twice per release, once in a plain text console and once under
X11, please try testing a Japanese PS/2 keyboard and Japanese USB keyboard.

In particular the troublesome keys are yen bar and backslash underscore.
You don't need a Japanese font.  If you use an ASCII font then the keys
display as backslash bar and backslash underscore.  If you use a Japanese
font then the keys display as yen bar and yen underscore.  In all cases the
ASCII backslash or JIS-Romaji yen character are code point 0x5C.

(Don't worry about the labels on the right-hand side of each key, for direct
kana input.  Less than 0.1% of Japanese and other residents of Japan ever
use direct kana input under Monopolysoft Windows, and probably none at all
under Linux.  When inputting Japanese, common practice is to input the
pronunciation in Italian characters and let the OS convert first to kana and
then to Kanji.  We depend on the labels on the left-hand side of each key,
including the two mentioned above.  Exception 1:  yen and backslash are
really the same character even though the keys have different labels.
Exception 2:  a shifted 0 doesn't really produce a ~ but it is enough that a
shifted ^ does so, but it doesn't matter that Linux has added real input for
a shifted 0.)

Re: 2.6.0-test5 vs. Japanese keyboards

[Andries Brouwer]

On Sun, Sep 14, 2003 at 12:51:32PM +0900, Norman Diamond wrote:
> In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
> 
> > > What will it take this time?
> >
> > Posting the patch with any luck ?
> 
> I knew that that would not be sufficient.

Just repeat. Do not repeat the complaining because complaining
with zero information content is just discarded.
But if you repeat the patch, together with an explanation of why
this is the correct patch, sooner or later somebody will look at it.

Andries

Re: 2.6.0-test5 vs. Japanese keyboards [1]

[Norman Diamond]

"Andries Brouwer" <aebr@win.tue.nl> wrote:
> On Sun, Sep 14, 2003 at 12:51:32PM +0900, Norman Diamond wrote:
> > In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
> >
> > > > What will it take this time?
> > >
> > > Posting the patch with any luck ?
> >
> > I knew that that would not be sufficient.
>
> Just repeat. Do not repeat the complaining because complaining
> with zero information content is just discarded.
> But if you repeat the patch, together with an explanation of why
> this is the correct patch, sooner or later somebody will look at it.

Due to the complexity of this answer, I am making three separate postings.

The posting by junkio@cox.net on July 24, 2003 was correct for Japanese PS/2
keyboards because it resulted in the yen pipe key working in a plain text
console.  The yen sign is the same as the backslash so the unshifted version
of this key was partly tolerable, but the pipe is not available otherwise so
this fix was really needed.

However, this was not enough for Japanese USB keyboards.  I recommend that
my revised patch, posted on August 31, 2003, be used instead.  This will be
quoted in a subsequent message.

The reasons for posting this partial patch are that junkio@cox.net kindly
provided a fix which was good enough for PS/2, taught me how to do the
patch, and resulted in further discussion by people who really should not be
capable of simply forgetting it.

For these historical reasons, it follows here:


----- Original Message ----- 
From: <junkio@cox.net>
To: "Norman Diamond" <ndiamond@wta.att.ne.jp>
Cc: <linux-kernel@vger.kernel.org>
Sent: Thursday, July 24, 2003 7:55 AM
Subject: [PATCH] keycode 183 in defkeymap.map (was Re: Japanese keyboards broken in 2.6)


> >>>>> "ND" == Norman Diamond <ndiamond@wta.att.ne.jp> writes:
> 
> ND> "Andries Brouwer" <aebr@win.tue.nl> replied to me, thank you.  Again, sorry
> ND> I cannot keep up with the mailing list.  If Dr. Brouwer or anyone else has
> ND> advice or questions, please contact me directly.  I am sending this both
> ND> personally and to the list.
> 
> I also got help from Brouwer with a similar (maybe the same)
> problem.  Although his "keycode 183 = backslash bar" comment is
> a bit cryptic, but here is what I did and worked:
> 
>  1. Add that line in drivers/char/defkeymap.map (that's kernel
>     source, not a file in /etc/{kbd,console}/).
> 
>  2. Get his kbd-1.08 source and rebuild loadkeys with the header
>     files from 2.6 kernel.  /usr/include/linux/keyboard.h you
>     have probably would not work---NR_KEYS is capped to 128.
>     (Note that the result of the compilation does not have to be
>     installed anywhere).
> 
>  3. Using the rebuilt loadkeys, rebuild drivers/char/defkeymap.c, 
>     mimicking what drivers/char/Makefile does (the rule is at
>     the endof the Makefile).
> 
>  4. Build the kernel.
> 
> For your convenience, I have attached patch that updates
> defkeymap.c and defkeymap.map to include the key definition, so
> you do not have to recompile loadkeys just to regenerate
> defkeymap.c file.  You should be able to apply the following to
> your 2.6.0-test1 source and rebuild the kernel.
> 
> 
> --- linux-2.6.0-test1/drivers/char/defkeymap.map 2003-07-13 20:31:58 -0700
> +++ linux-2.6.0-test1/drivers/char/defkeymap.map 2003-07-19 16:10:48 -0700
> @@ -259,6 +259,7 @@
>  keycode 125 =
>  keycode 126 =
>  keycode 127 =
> +keycode 183 = backslash bar
>  string F1 = "\033[[A"
>  string F2 = "\033[[B"
>  string F3 = "\033[[C"
> 
> 
> --- linux-2.6.0-test1/drivers/char/defkeymap.c_shipped 2003-07-13 20:33:13 -0700
> +++ linux-2.6.0-test1/drivers/char/defkeymap.c_shipped 2003-07-19 16:21:00 -0700
> @@ -22,6 +22,54 @@
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf05c,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short shift_map[NR_KEYS] = {
> @@ -37,10 +85,58 @@
>   0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301,
>   0xf302, 0xf303, 0xf300, 0xf310, 0xf206, 0xf200, 0xf03e, 0xf10a,
>   0xf10b, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf20b, 0xf601, 0xf602, 0xf117, 0xf600, 0xf20a, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf07c,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short altgr_map[NR_KEYS] = {
> @@ -56,10 +152,58 @@
>   0xf912, 0xf913, 0xf30b, 0xf90e, 0xf90f, 0xf910, 0xf30a, 0xf90b,
>   0xf90c, 0xf90d, 0xf90a, 0xf310, 0xf206, 0xf200, 0xf07c, 0xf516,
>   0xf517, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short ctrl_map[NR_KEYS] = {
> @@ -79,6 +223,54 @@
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short shift_ctrl_map[NR_KEYS] = {
> @@ -94,10 +286,58 @@
>   0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301,
>   0xf302, 0xf303, 0xf300, 0xf310, 0xf206, 0xf200, 0xf200, 0xf200,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short alt_map[NR_KEYS] = {
> @@ -117,6 +357,54 @@
>   0xf118, 0xf210, 0xf211, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short ctrl_alt_map[NR_KEYS] = {
> @@ -132,10 +420,58 @@
>   0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301,
>   0xf302, 0xf303, 0xf300, 0xf20c, 0xf206, 0xf200, 0xf200, 0xf50a,
>   0xf50b, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf20c,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  ushort *key_maps[MAX_NR_KEYMAPS] = {
> 
> 
> 

Re: 2.6.0-test5 vs. Japanese keyboards [2]

[Norman Diamond]

"Andries Brouwer" <aebr@win.tue.nl> wrote:
> On Sun, Sep 14, 2003 at 12:51:32PM +0900, Norman Diamond wrote:
> > In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
> >
> > > > What will it take this time?
> > >
> > > Posting the patch with any luck ?
> >
> > I knew that that would not be sufficient.
>
> Just repeat. Do not repeat the complaining because complaining
> with zero information content is just discarded.
> But if you repeat the patch, together with an explanation of why
> this is the correct patch, sooner or later somebody will look at it.

Due to the complexity of this answer, I am making three separate postings.

The posting by myself on August 31, 2003 was correct for both Japanese PS/2
and Japanese USB keyboards because it resulted in the yen pipe key working
in a plain text console.  The yen sign is the same as the backslash so the
unshifted version of this key was partly tolerable, but the pipe is not
available otherwise so this fix was really needed.


----- Original Message ----- 
From: "Norman Diamond" <ndiamond@wta.att.ne.jp>
Newsgroups: linux.kernel
Sent: Sunday, August 31, 2003 6:20 PM
Subject: [PATCH] 2.6.0-test4, Japanese USB keyboards, keycodes 181 and 183


> If this gets posted correctly, it will patch
>  [...]/drivers/char/defkeymap.c_shipped
> and
>  [...]/drivers/char/defkeymap.mapped
> so that keys \| and \_ will work for both Japanese PS/2 and Japanese USB
> keyboards.
> 
> I did not develop the patch in the same way as was done by junkio@cox.net
> (sorry I misplaced his real name somewhere), but am trying to post it in
> the same manner as he posted his on July 23, 2003.
> 
> Sorry I use Monopolysoft for most internet stuff so I cannot mail this by
> an ordinary method.  Outlook Express changes each tab to a single space.
> So I'm using the telnet command to submit this mail.  Odds are that the
> LKML's spam controls will detect that and reject this message, but I'll
> try anyway, in hopes of preserving tab characters.
> 
> Sorry I cannot keep up with the mailing list.  Any questions or advice,
> personal e-mail please.
> 
> 
> diff -ru linux-2.6-keymaps1/defkeymap.c_shipped linux-2.6-keymaps2/defkeymap.c_shipped
> --- linux-2.6-keymaps1/defkeymap.c_shipped 2003-08-31 16:51:38.000000000 +0900
> +++ linux-2.6-keymaps2/defkeymap.c_shipped 2003-08-31 16:52:22.000000000 +0900
> @@ -22,6 +22,54 @@
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf05c, 0xf200, 0xf05c,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short shift_map[NR_KEYS] = {
> @@ -37,10 +85,58 @@
>   0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301,
>   0xf302, 0xf303, 0xf300, 0xf310, 0xf206, 0xf200, 0xf03e, 0xf10a,
>   0xf10b, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf20b, 0xf601, 0xf602, 0xf117, 0xf600, 0xf20a, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf05f, 0xf200, 0xf07c,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short altgr_map[NR_KEYS] = {
> @@ -56,10 +152,58 @@
>   0xf912, 0xf913, 0xf30b, 0xf90e, 0xf90f, 0xf910, 0xf30a, 0xf90b,
>   0xf90c, 0xf90d, 0xf90a, 0xf310, 0xf206, 0xf200, 0xf07c, 0xf516,
>   0xf517, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short ctrl_map[NR_KEYS] = {
> @@ -79,6 +223,54 @@
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short shift_ctrl_map[NR_KEYS] = {
> @@ -94,10 +286,58 @@
>   0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301,
>   0xf302, 0xf303, 0xf300, 0xf310, 0xf206, 0xf200, 0xf200, 0xf200,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short alt_map[NR_KEYS] = {
> @@ -117,6 +357,54 @@
>   0xf118, 0xf210, 0xf211, 0xf117, 0xf600, 0xf119, 0xf115, 0xf116,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  u_short ctrl_alt_map[NR_KEYS] = {
> @@ -132,10 +420,58 @@
>   0xf308, 0xf309, 0xf30b, 0xf304, 0xf305, 0xf306, 0xf30a, 0xf301,
>   0xf302, 0xf303, 0xf300, 0xf20c, 0xf206, 0xf200, 0xf200, 0xf50a,
>   0xf50b, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> - 0xf30e, 0xf702, 0xf30d, 0xf200, 0xf701, 0xf205, 0xf114, 0xf603,
> + 0xf30e, 0xf702, 0xf30d, 0xf01c, 0xf701, 0xf205, 0xf114, 0xf603,
>   0xf118, 0xf601, 0xf602, 0xf117, 0xf600, 0xf119, 0xf115, 0xf20c,
>   0xf11a, 0xf10c, 0xf10d, 0xf11b, 0xf11c, 0xf110, 0xf311, 0xf11d,
>   0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
> + 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200, 0xf200,
>  };
>  
>  ushort *key_maps[MAX_NR_KEYMAPS] = {
> diff -ru linux-2.6-keymaps1/defkeymap.map linux-2.6-keymaps2/defkeymap.map
> --- linux-2.6-keymaps1/defkeymap.map 2003-08-31 16:51:38.000000000 +0900
> +++ linux-2.6-keymaps2/defkeymap.map 2003-08-31 16:52:22.000000000 +0900
> @@ -259,6 +259,12 @@
>  keycode 125 =
>  keycode 126 =
>  keycode 127 =
> +keycode 181 = backslash        underscore
> + control keycode 181 = Control_backslash
> + alt     keycode 181 = Meta_backslash  
> +keycode 183 = backslash        bar             
> + control keycode 183 = Control_backslash
> + alt     keycode 183 = Meta_backslash  
>  string F1 = "\033[[A"
>  string F2 = "\033[[B"
>  string F3 = "\033[[C"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Norman Diamond]

"Andries Brouwer" <aebr@win.tue.nl> wrote:
> On Sun, Sep 14, 2003 at 12:51:32PM +0900, Norman Diamond wrote:
> > In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
> >
> > > > What will it take this time?
> > >
> > > Posting the patch with any luck ?
> >
> > I knew that that would not be sufficient.
>
> Just repeat. Do not repeat the complaining because complaining
> with zero information content is just discarded.
> But if you repeat the patch, together with an explanation of why
> this is the correct patch, sooner or later somebody will look at it.

Due to the complexity of this answer, I am making three separate postings.

I make no assertion that the following is correct or is a patch, but think
that it deserves consideration.  I spend about one day each weekend testing
this kernel, have had patches ignored enough times, and seriously think of
rejoining the set of users who never have time to test.

----- Original Message ----- 
From: "Norman Diamond" <ndiamond@wta.att.ne.jp>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Greg KH" <greg@kroah.com>; "Linux Kernel Mailing List"
<linux-kernel@vger.kernel.org>; "Andries Brouwer" <aebr@win.tue.nl>;
"Vojtech Pavlik" <vojtech@suse.cz>
Sent: Monday, August 18, 2003 7:35 PM
Subject: Re: Trying to run 2.6.0-test3


> "Alan Cox" <alan@lxorguk.ukuu.org.uk> replied to me.
>
> > > accept a USB keyboard but they refused.  The patch which I sent to Vojtech
> > > Pavlik was ignored and these two keys continued not to work (except on my
> > > machine).  Finally Mike Fabian accepted a gift of a USB keyboard and this
> > > defect in Linux got fixed.  But only for somewhere around the last half of
> > > the 2.4 releases, not for 2.6.
> > > What will it take this time?
> >
> > Posting the patch with any luck ?
>
> Hirofumi Ogawa posted a patch for the yen-sign pipe key on 2003.07.23 for
> test1 but his patch still didn't get into test3.  On a PS/2 keyboard that
> seems to be the only key with any problem.
>
> Yesterday when I finally tried a USB keyboard and found that the backslash
> underbar has the same problem, maybe I was the first person to even try a
> Japanese USB keyboard in 2.6, and maybe no one at all tried some number of
> 2.5 series kernels.  As mentioned, usually I can only spend one day a week
> testing 2.6.  I'll try to spend one day next weekend trying to figure out
> the new necessary patch.  If I succeed, but if it gets ignored again, I'll
> probably rejoin the set of users who never have time to test.
>
> I really do think that if Andries Brouwer or Vojtech Pavlik would accept a
> gift of a USB keyboard then this kind of bug would be avoided a lot earlier.
>

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Andries Brouwer]

On Sun, Sep 14, 2003 at 08:21:30PM +0900, Norman Diamond wrote:

[three separate postings]

The content of the first posting is

> +keycode 183 = backslash bar

The content of the second posting is

> +keycode 181 = backslash        underscore
> + control keycode 181 = Control_backslash
> + alt     keycode 181 = Meta_backslash
> +keycode 183 = backslash        bar
> + control keycode 183 = Control_backslash
> + alt     keycode 183 = Meta_backslash

The third posting was almost empty, but reminded me of

> > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > for test1 but his patch still didn't get into test3.

I do not think his patch is needed.

So the question arises: do we need a kernel patch, and if so, what patch?
The program loadkeys exists to load the kernel keymap with the map the user
desires. So, if you need some particular map the obvious answer is:
"use loadkeys".

There is a small snag - until 2.4 the value of NR_KEYS was 128,
while 2.6 uses 256. Moreover, the keys you want to change are above 128.
So, your old precompiled loadkeys will not do - you must recompile the
kbd package against 2.6 kernel headers, or just edit loadkeys.y and dumpkeys.c
inserting

#undef NR_KEYS
#define NR_KEYS 256

after all includes, and then compile on any Linux machine.

There is no need to have knowledge of the Japanese keymap in the kernel,
just as there is no knowledge of the German or French keymap. That
knowledge belongs in the keymap that one loads.

Andries

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Junio C Hamano]

>>>>> "AB" == Andries Brouwer <aebr@win.tue.nl> writes:

AB> So the question arises: do we need a kernel patch, and if
AB> so, what patch?

Norman wants the second one with 181 and 183.  For PS/2
keyboards, only 183 is enough, but both are needed for some
other kind (USB).

There are some good reasons to include Norman's patch:

 - This whole thread started when I noticed that pipe ('|') did
   not work on 2.6.0-test1 as it used to in 2.4:

   http://marc.theaimsgroup.com/?l=linux-kernel&m=105861161105970&w=2

   You kindly took time to suggest adding 183 to the keymap, and
   the first variant Norman reposted recently is the outcome of
   that suggestion.  In short, adding 183 is just to regain what
   used to be supported in stock 2.4 but not in the current 2.6.
   It is not new; just fixing the regression.  I cannot test
   this anymore but I remember interacting with a shell under
   using such a keyboard during 2.2 days without trouble with
   forming pipeline, so I am reasonably sure that stock 2.2 also
   supported this key.

 - The keymap arrays in defkeymap.c_shipped are all defined to
   be arrays of NR_KEYS u_short elements, and without the patch
   they contain 0 for the 181 and 183 keys.  The patch replaces
   these zeroes with some useful values there for the affected
   keyboards.  The change does not bloat the kernel binary.

 - The patch looks bigger than necessary because changes to the
   file defkeymap.c_shipped is included for the general public's
   convenience, and it has to be big only because the stock
   kernel defkeymap.c_shipped seems to have been generated by a
   loadkeys command that still thinks NR_KEYS is 128.  As
   clarified in another thread recently, that is a generated
   file not a source.  The true change just adds six lines or so
   to the defkeymap.map.  The change does not increase the
   maintenance cost of the kernel that much.

AB> There is no need to have knowledge of the Japanese keymap in
AB> the kernel, just as there is no knowledge of the German or
AB> French keymap. That knowledge belongs in the keymap that one
AB> loads.

A purist might say that there is no reason to include pipe ('|')
key support for Japanese keyboards in the kernel source, nor
include any keyboard support for that matter ;-).  Everybody can
run loadkeys from their init script during the bootup sequence
;-).  We do not do that for an obvious reason: convenience for
the common cases.

The only technical reason to reject this is if some other
keyboards want to claim 181 and/or 183 for some other symbols.
Although I do not think it is likely, integrating Norman's patch
in the mainline would be a good way to detect this anyway since
somebody would start screaming if there is such a conflicting
case.  Once we know there are two conflicting camps who want to
define 181 and/or 183 to different symbols, we can worry about
which one to make the default by perhaps user population; this
is remotely similar to the way we ship qwerty not dvorak as the
default keymap in the kernel.

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[OGAWA Hirofumi]

Andries Brouwer <aebr@win.tue.nl> writes:

> > > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > > for test1 but his patch still didn't get into test3.
> 
> I do not think his patch is needed.
> 
> So the question arises: do we need a kernel patch, and if so, what patch?
> The program loadkeys exists to load the kernel keymap with the map the user
> desires. So, if you need some particular map the obvious answer is:
> "use loadkeys".
> 
> There is a small snag - until 2.4 the value of NR_KEYS was 128,
> while 2.6 uses 256. Moreover, the keys you want to change are above 128.
> So, your old precompiled loadkeys will not do - you must recompile the
> kbd package against 2.6 kernel headers, or just edit loadkeys.y and dumpkeys.c
> inserting

in input.h
	#define KEY_MAX		0x1ff
in keyboard.h
	#define NR_KEYS		(KEY_MAX+1)

NR_KEYS is 512...  Or we should use 256, you mean?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Andries Brouwer]

On Wed, Sep 17, 2003 at 09:35:22PM +0900, OGAWA Hirofumi wrote:
> Andries Brouwer <aebr@win.tue.nl> writes:
> 
> > > > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > > > for test1 but his patch still didn't get into test3.

> > until 2.4 the value of NR_KEYS was 128, while 2.6 uses 256

> in input.h
> 	#define KEY_MAX		0x1ff
> in keyboard.h
> 	#define NR_KEYS		(KEY_MAX+1)
> 
> NR_KEYS is 512...  Or we should use 256, you mean?

Yes, I think so.

Maybe Vojtech can tell us why he wrote 512, but I just see a
large amount of wasted space (and, as you already pointed out,
the need for new ioctls) if one uses 512.

As far as I can see, everything works with 256.
Indeed, everything seems to assume 256.

Andries

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[OGAWA Hirofumi]

Andries Brouwer <aebr@win.tue.nl> writes:

> On Wed, Sep 17, 2003 at 09:35:22PM +0900, OGAWA Hirofumi wrote:
> > Andries Brouwer <aebr@win.tue.nl> writes:
> > 
> > > > > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > > > > for test1 but his patch still didn't get into test3.
> 
> > > until 2.4 the value of NR_KEYS was 128, while 2.6 uses 256
> 
> > in input.h
> > 	#define KEY_MAX		0x1ff
> > in keyboard.h
> > 	#define NR_KEYS		(KEY_MAX+1)
> > 
> > NR_KEYS is 512...  Or we should use 256, you mean?
> 
> Yes, I think so.
> 
> Maybe Vojtech can tell us why he wrote 512, but I just see a
> large amount of wasted space (and, as you already pointed out,
> the need for new ioctls) if one uses 512.
> 
> As far as I can see, everything works with 256.
> Indeed, everything seems to assume 256.

That sounds good to me. Vojtech, did we need NR_KEYS(KEY_MAX?) greater
than 256?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.0-test5 vs. Japanese keyboards

[Vojtech Pavlik]

On Sun, Sep 14, 2003 at 12:51:32PM +0900, Norman Diamond wrote:
> In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
> 
> > > What will it take this time?
> >
> > Posting the patch with any luck ?
> 
> I knew that that would not be sufficient.  On 2003.07.24, I think in the
> days of 2.6.0-test1, junkio@cox.net posted a patch for Japanese PS/2
> keyboards.  On 2003.08.31, in the days of 2.6.0-test4, I posted a revised
> patch to include Japanese USB keyboards.  2.6.0-test5 includes neither of
> them because the keyboard driver maintainers don't personally depend on
> Japanese keyboards.
> 
> Since posting has not been sufficient, I beg Mr. Pavlik, just once per
> release, please try pretending that you might have to depend on a Japanese
> keyboard.

I'd like to include the japanese keyboard fixes and have it working,
however the reports I'm getting are quite confusing. It seems that there
isn't just one kind of japanese keyboards out there ...

If you manage to tell me what exactly is what key supposed to produce,
what scancode it does have on PS/2 and what HID event it sends on USB,
I'll be more than happy to fix it all.

I'll try to dig and find the patches posted on the list and make sense
out of them in the meantime, however they often break other (non-jp)
stuff.

> You don't have to use one daily as your colleague Dr. Fabian
> does. Just twice per release, once in a plain text console and once under
> X11, please try testing a Japanese PS/2 keyboard and Japanese USB keyboard.

This might be a little problematic - I don't have any Japanese keyboard
and I don't have any idea about how to buy one.

If anyone would send me samples of Japanese keyboards, you can be sure
I'd test them.

> In particular the troublesome keys are yen bar and backslash underscore.
> You don't need a Japanese font.  If you use an ASCII font then the keys
> display as backslash bar and backslash underscore.  If you use a Japanese
> font then the keys display as yen bar and yen underscore.  In all cases the
> ASCII backslash or JIS-Romaji yen character are code point 0x5C.

IIRC these now generate proper key evens (KEY_INTL*), which are missing
in the default keymap, because the event codes are above 255, which
current 'loadkeys' utility cannot handle.

Thus this requires more work than just patching up some table. And a lot
of thinking, too, so that we both don't break older setups and make the
transition easy for new ones.

> (Don't worry about the labels on the right-hand side of each key, for direct
> kana input. 

I have yet to see a Japanese keyboard to be able to worry about it. I've
seen some pictures on the web, and that's all I've seen.

> Less than 0.1% of Japanese and other residents of Japan ever
> use direct kana input under Monopolysoft Windows, and probably none at all
> under Linux.  When inputting Japanese, common practice is to input the
> pronunciation in Italian characters and let the OS convert first to kana and
> then to Kanji.  We depend on the labels on the left-hand side of each key,
> including the two mentioned above.  Exception 1:  yen and backslash are
> really the same character even though the keys have different labels.
> Exception 2:  a shifted 0 doesn't really produce a ~ but it is enough that a
> shifted ^ does so, but it doesn't matter that Linux has added real input for
> a shifted 0.)
> 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Vojtech Pavlik]

On Tue, Sep 16, 2003 at 03:43:05PM +0200, Andries Brouwer wrote:
 
> I do not think his patch is needed.
> 
> So the question arises: do we need a kernel patch, and if so, what patch?
> The program loadkeys exists to load the kernel keymap with the map the user
> desires. So, if you need some particular map the obvious answer is:
> "use loadkeys".
> 
> There is a small snag - until 2.4 the value of NR_KEYS was 128,
> while 2.6 uses 256. Moreover, the keys you want to change are above 128.
> So, your old precompiled loadkeys will not do - you must recompile the
> kbd package against 2.6 kernel headers, or just edit loadkeys.y and dumpkeys.c
> inserting
> 
> #undef NR_KEYS
> #define NR_KEYS 256
> 
> after all includes, and then compile on any Linux machine.
> 
> There is no need to have knowledge of the Japanese keymap in the kernel,
> just as there is no knowledge of the German or French keymap. That
> knowledge belongs in the keymap that one loads.

There is a slight problem, and that is that NR_KEYS is (KEY_MAX+1) in
recent 2.6's and that's 512. And that doesn't fit into a byte. There
were some patches floating around to enhance the keymap loading ioctls.
They will be needed, along with a new version of loadkeys.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Andries Brouwer]

On Sun, Sep 21, 2003 at 01:06:29PM +0200, Vojtech Pavlik wrote:

> There is a slight problem, and that is that NR_KEYS is (KEY_MAX+1) in
> recent 2.6's and that's 512. And that doesn't fit into a byte. There
> were some patches floating around to enhance the keymap loading ioctls.
> They will be needed, along with a new version of loadkeys.

Yes - a lot of trouble.
As far as I can see, the space between 256 and 511 is never used.

More in particular, there are lots of places where the kernel
seems to assume that only 256 is used.

So, instead of requiring new ioctls and new loadkeys etc
I would prefer to make NR_KEYS 256, if possible.
So the question is: why did you require 512?

Andries

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Vojtech Pavlik]

On Sun, Sep 21, 2003 at 02:39:34PM +0200, Andries Brouwer wrote:
> On Sun, Sep 21, 2003 at 01:06:29PM +0200, Vojtech Pavlik wrote:
> 
> > There is a slight problem, and that is that NR_KEYS is (KEY_MAX+1) in
> > recent 2.6's and that's 512. And that doesn't fit into a byte. There
> > were some patches floating around to enhance the keymap loading ioctls.
> > They will be needed, along with a new version of loadkeys.
> 
> Yes - a lot of trouble.
> As far as I can see, the space between 256 and 511 is never used.
> 
> More in particular, there are lots of places where the kernel
> seems to assume that only 256 is used.
> 
> So, instead of requiring new ioctls and new loadkeys etc
> I would prefer to make NR_KEYS 256, if possible.
> So the question is: why did you require 512?

Excerpt from input.h:

#define KEY_RESTART             0x198
#define KEY_SLOW                0x199
#define KEY_SHUFFLE             0x19a
#define KEY_BREAK               0x19b
#define KEY_PREVIOUS            0x19c
#define KEY_DIGITS              0x19d
#define KEY_TEEN                0x19e
#define KEY_TWEN                0x19f

#define KEY_DEL_EOL             0x1c0
#define KEY_DEL_EOS             0x1c1
#define KEY_INS_LINE            0x1c2
#define KEY_DEL_LINE            0x1c3

So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
That's above 256. If there are other places that require less than 256,
well, then those will need to be fixed or we're heading for trouble.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.0-test5 vs. Japanese keyboards

[Norman Diamond]

Vojtech Pavlik wrote:

> I'd like to include the japanese keyboard fixes and have it working,
> however the reports I'm getting are quite confusing. It seems that there
> isn't just one kind of japanese keyboards out there ...

The most common kinds are:

1.  PS/2 JP106 layout.  Electrically it is the same as any other PS/2
keyboard.

In the upper left, near the Esc key, is the hankaku/zenkaku key.  The scan
code is the same as the US backquote tilde key.  In Japanese Monopolysoft
systems it turns the IME on or off.  This key does not produce input by
itself, but of course the scan code is used in turning the IME on or off.
In Linux traditionally it does not produce input, but I think that the
"ATOK" IME might need to be informed of keypresses.

(Historically this key used to switch between half-width and full-width
characters, but Alt + hankaku/zenkaku turned the IME on or off.  Now the use
of Alt with this key is optional for this purpose, and a different operation
is needed to get half-width characters.)

To the left of the space key is the muhenkan key.  To the right of the space
key are the henkan key and hiragana/katakana key.  In Monopolysoft systems
these affect the IME.  They do not produce input by themselves but the scan
codes are used in controlling the IME.  In Linux traditionally they do not
produce input, but I think that the "ATOK" IME might need to be informed of
keypresses.

Near the upper right is the yen bar key.  The scan code is one which doesn't
exist on a US keyboard.  In Japanese character sets, the half-width
single-byte yen symbol is 0x5C, the same as the ASCII backslash.  If a US
font is used then the character displays as a backslash.  C programs and
Monopolysoft filesystems and everything interpret it the same as a backslash
because the codepoint is the same (0x5C).  When shifted it is an or bar, the
same code point as an ASCII or bar.

Near the lower right is the backslash underscore key.  The scan code is one
which doesn't exist on a US keyboard.  If a Japanese font is used then the
backslash displays as a half-width single-byte yen symbol because the code
is the same (0x5C).  In other words, the unshifted yen key and unshifted
backslash key are redundant, only one is needed, but this is not true of the
shifted versions.  When shifted this one is an underscore, the same code
point as an ASCII underscore.

Regarding the caret tilde key, traditionally this was a caret overbar key.
In Japanese character sets, the overbar is the same code point as the ASCII
tilde.  But no one displays it as an overbar any more, everyone displays it
as a tilde.  The overbar graphic is virtually forgotten, though on some
keyboards the label still displays it as an overbar, just to cause confusion
between the underscore and the overbar.  The scan code is the same as a US
keyboard's plus and equal key.

Regarding the 0 key (digit 0), it is most common for the keyboard's label to
display a tilde above the 0.  When unshifted this key inputs a 0.  When
shifted this key normally does not input anything, though the scan code is
observed and discarded by the driver.  The exception is that Linux accepts
the scan code even when shifted, and inputs a tilde, the same code point as
the overbar or tilde mentioned above.  Linux added this redundancy which
does not hurt, but it's really irrelevant.

Other keys have pretty much obvious meanings.  The alphabetic QWERTY layout
is the same as a US keyboard but all the punctuation marks are moved around.

(Mr. Bradford's keyboard is strange.  If his shifted 0 produces a tilde as
input even to Monopolysoft operating systems, well then OK I believe him,
but we already know his keyboard is strange.)

(By the way, NEC no longer makes old 9800 machines.  Modern NEC PS/2
keyboards are the same as other PS/2 keyboards.)

2.  USB JP106 layout.  The scan codes of the yen bar, backslash underscore,
muhenkan, henkan, and hiragana/katakana keys are different from the PS/2
keyboard's scan codes.  The driver's mapping of scan codes from USB scan
codes to PS/2 scan codes must map these keys to match what keyboards do.
When you invented other International scan codes for them, they did not
work.  In the middle of the 2.4 series this was finally accepted, though I'm
not sure if you were the one who finally accepted it, or if Dr. Fabian
persuaded others.

(By the way, NEC no longer makes old 9800 machines.  Modern NEC USB
keyboards are the same as other USB keyboards.  But Macintosh is different
from other USB keyboards.)

3.  Old NEC 9800 keyboards.  Some old 9800 machines are powerful enough to
run Linux, and some can even run XFree86.  So some people have even made the
old keyboards work with Linux.  I don't know details though.  I have never
bought nor mailed one of these.

4.  Macintosh keyboards.  They use USB but their scan codes are different
from everyone else's.  My understanding is that the 2.4 kernel correctly
mapped Macintosh's scan codes earlier than it did for ordinary USB
keyboards.  But I never tried it myself, don't know details, and have never
bought nor mailed one.

> If you manage to tell me what exactly is what key supposed to produce,
> what scancode it does have on PS/2 and what HID event it sends on USB,
> I'll be more than happy to fix it all.

I'm relieved to see your present opinion.  Thank you.  But I think you can
look in 2.4 kernels to see the answer.

In addition, if you use showkey -s to view scan codes, you must use a 2.4
kernel.  2.6 is broken enough to even make showkey -s output garbage.

> I'll try to dig and find the patches posted on the list

One message-id is <qwxq.74V.3@gated-at.bofh.it> but I don't think this is an
original LKML message-id.  Because of the hack I had to use in posting (to
preserve tab characters instead of letting Monopolysoft Lookout change them
to spaces), I don't have any other message-id for it.  The date was
2003.8.31 and subject line was:  [PATCH] 2.6.0-test4, Japanese USB
keyboards, keycodes 181 and 183.

> however they often break other (non-jp) stuff.

I sincerely doubt that.  I think that the scan codes involved here are not
used in conflicting manners on other keyboards.

> If anyone would send me samples of Japanese keyboards, you can be sure
> I'd test them.

Thank you!  I was afraid to ask in advance because I thought that you would
either refuse or you would ignore the suggestion.  Dr. Brouwer did refuse,
about 3 years ago or so.  I could not take a chance on you refusing, because
I know that you really really need them.  I sent a sea mail package on
2003.8.31 (same date as posting that patch).  It should arrive in a few more
weeks.  It is addressed to you at the address of SuSE, copied from your
company's web site.

> > In particular the troublesome keys are yen bar and backslash underscore.
> > You don't need a Japanese font.  If you use an ASCII font then the keys
> > display as backslash bar and backslash underscore.
>
> IIRC these now generate proper key evens (KEY_INTL*),

I commented on this above.

> which are missing in the default keymap,

Yes.

> because the event codes are above 255,

I don't understand your event codes very well.  But showkey -s still
produces garbage, so there is still something broken between scan codes and
event codes.  On a Japanese PS/2 keyboard, all scan codes are below (or
maybe equal to) 127.  On a Japanese USB keyboard, scan codes can go up to
255.  The troublesome keys are in the range from 128 to 255.

> Thus this requires more work than just patching up some table. And a lot
> of thinking, too, so that we both don't break older setups and make the
> transition easy for new ones.

I can't speak for future transitions, but the present breakage does break
current machines exactly in the way you say you can't.

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Andries Brouwer]

On Sun, Sep 21, 2003 at 02:48:17PM +0200, Vojtech Pavlik wrote:

> > So, instead of requiring new ioctls and new loadkeys etc
> > I would prefer to make NR_KEYS 256, if possible.
> > So the question is: why did you require 512?
> 
> Excerpt from input.h:

> #define KEY_TEEN                0x19e
> #define KEY_TWEN                0x19f
> #define KEY_DEL_EOL             0x1c0
> #define KEY_DEL_EOS             0x1c1
> 
> So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
> That's above 256. If there are other places that require less than 256,
> well, then those will need to be fixed or we're heading for trouble.

Hmm. The kernel assumes today that keycodes have 8 bits:

In drivers/char/keyboard.c emulate_raw() tries to invent
the codes that the keyboard probably sent and resulted in a given
keycode. It starts out
	if (keycode > 255)
		return -1;

In drivers/input/keyboards/atkbd.c we have tables that convert
scancodes to keycodes. The declaration is
	static unsigned char atkbd_set2_keycode[512];
the unsigned char means that no keycodes larger than 255 can be returned.

It really seems a pity to have to add new ioctls, and to have to release
a new version of the kbd package, and to waste a lot of kernel space,
while essentially nobody needs the resulting functionality.


Andries

Re: 2.6.0-test5 vs. Japanese keyboards

[Andries Brouwer]

On Sun, Sep 21, 2003 at 10:26:04PM +0900, Norman Diamond wrote:

[good description of Japanese keyboards deleted]

> > If anyone would send me samples of Japanese keyboards, you can be sure
> > I'd test them.
> 
> Thank you!  I was afraid to ask in advance because I thought that you would
> either refuse or you would ignore the suggestion.  Dr. Brouwer did refuse,
> about 3 years ago or so.

Did I really?

But the advantage of a good description is that the information
lives on the net and can be retrieved by anybody. A piece of
hardware takes room and can be tested by only one.

I think no kernel changes are required to use Japanese keyboards today.
(But kbd has to be recompiled with NR_KEYS set to 256.)

Andries


On http://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html
there is a reasonably detailed description of the state of
affairs. Maybe nothing more is needed. Of course additions
and corrections are welcome.

Re: 2.6.0-test5 vs. Japanese keyboards

[Andries Brouwer]

On Sun, Sep 21, 2003 at 01:01:25PM +0200, Vojtech Pavlik wrote:

> If you manage to tell me what exactly is what key supposed to produce,
> what scancode it does have on PS/2 and what HID event it sends on USB,
> I'll be more than happy to fix it all.

See http://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Vojtech Pavlik]

On Sun, Sep 21, 2003 at 04:49:14PM +0200, Andries Brouwer wrote:

> > > So, instead of requiring new ioctls and new loadkeys etc
> > > I would prefer to make NR_KEYS 256, if possible.
> > > So the question is: why did you require 512?
> > 
> > Excerpt from input.h:
> 
> > #define KEY_TEEN                0x19e
> > #define KEY_TWEN                0x19f
> > #define KEY_DEL_EOL             0x1c0
> > #define KEY_DEL_EOS             0x1c1
> > 
> > So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
> > That's above 256. If there are other places that require less than 256,
> > well, then those will need to be fixed or we're heading for trouble.
> 
> Hmm. The kernel assumes today that keycodes have 8 bits:
> 
> In drivers/char/keyboard.c emulate_raw() tries to invent
> the codes that the keyboard probably sent and resulted in a given
> keycode. It starts out
> 	if (keycode > 255)
> 		return -1;

That's correct, because it can only emulate about 230 different
keycodes. Note that this is not 'invent what the keyboard sent', since
in many cases the keyboard did not send any keycodes (USB) or at least
not any AT-looking keycodes.

However XFree86 (and this hack is there ONLY because of XFree86) needs
AT-looking keycodes on most architectures.

If somebody could teach XFree86 to use at least the medium raw mode
here, we could get rid both of the emulate_raw() stuff and of the
limitation of what we can pass to XFree86.

Also, this causes trouble with the japanese keys in XFree86, since the
KEY_INTL* keys are in the e0 xx range because of the emulation.

> In drivers/input/keyboards/atkbd.c we have tables that convert
> scancodes to keycodes. The declaration is
> 	static unsigned char atkbd_set2_keycode[512];
> the unsigned char means that no keycodes larger than 255 can be returned.

We may need to change this to a u16, IF we'll ever need to load a
keycode above 256 for an AT keyboard. Keep in mind that AT keyboards are
not the whole world. So far all the keys on AT keyboards are within the
0..255 range. That's of course not true for other, more crazy keyboards.

> It really seems a pity to have to add new ioctls, and to have to release
> a new version of the kbd package, and to waste a lot of kernel space,
> while essentially nobody needs the resulting functionality.
 
We could do an audit of the key definitions, document which KEY_* symbol
means exactly what (and it'd be a good thing anyway), by that try to
remove duplicities and try to stuff everything in 0..255.

We'd lose te potential possibility to map keysyms to buttons, though
since that never was used, nobody would cry probably.

However, my experience tells me that whenever some range is tight, and
0..255 is in this case, we will very soon overflow as new weird devices
come into market.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Andries Brouwer]

On Sun, Sep 21, 2003 at 07:07:10PM +0200, Vojtech Pavlik wrote:

> > 	static unsigned char atkbd_set2_keycode[512];
> 
> We may need to change this to a u16, IF we'll ever need to load a
> keycode above 256 for an AT keyboard. So far all the keys on AT keyboards
> are within the 0..255 range. That's of course not true for other,
> more crazy keyboards.
> 
> > It really seems a pity to have to add new ioctls, and to have to release
> > a new version of the kbd package, and to waste a lot of kernel space,
> > while essentially nobody needs the resulting functionality.
>  
> We could do an audit of the key definitions, document which KEY_* symbol
> means exactly what (and it'd be a good thing anyway), by that try to
> remove duplicities and try to stuff everything in 0..255.

Yes.

I think that if you remove everything that is not used inside the kernel,
the rest fits problemless into 0..255.

> We'd lose te potential possibility to map keysyms to buttons, though
> since that never was used, nobody would cry probably.
> 
> However, my experience tells me that whenever some range is tight, and
> 0..255 is in this case, we will very soon overflow as new weird devices
> come into market.

True. In the long run more may be needed. (If we really want to assign
a different keycode to each possible picture on a key.)

I would be happy if we could pass smoothly from old to new - no new
ioctls for 2.6.0 yet, a kbd package that only changes the NR_KEYS define,
and later worry about whether we really need lots of keycodes.
Everything we add will never go away, so we must be slow in adding.

Andries

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Vojtech Pavlik]

On Sun, Sep 21, 2003 at 07:42:00PM +0200, Andries Brouwer wrote:

> > > 	static unsigned char atkbd_set2_keycode[512];
> > 
> > We may need to change this to a u16, IF we'll ever need to load a
> > keycode above 256 for an AT keyboard. So far all the keys on AT keyboards
> > are within the 0..255 range. That's of course not true for other,
> > more crazy keyboards.
> > 
> > > It really seems a pity to have to add new ioctls, and to have to release
> > > a new version of the kbd package, and to waste a lot of kernel space,
> > > while essentially nobody needs the resulting functionality.
> >  
> > We could do an audit of the key definitions, document which KEY_* symbol
> > means exactly what (and it'd be a good thing anyway), by that try to
> > remove duplicities and try to stuff everything in 0..255.
> 
> Yes.
> 
> I think that if you remove everything that is not used inside the kernel,
> the rest fits problemless into 0..255.

But that's definitely not a way to go. Since the scancode->keycode maps
are loadable in atkbd.c and a couple other drivers. So, if you change to
'cannot be used' by the kernel, then fine ...

> > We'd lose te potential possibility to map keysyms to buttons, though
> > since that never was used, nobody would cry probably.
> > 
> > However, my experience tells me that whenever some range is tight, and
> > 0..255 is in this case, we will very soon overflow as new weird devices
> > come into market.
> 
> True. In the long run more may be needed. (If we really want to assign
> a different keycode to each possible picture on a key.)

I think it's a good thing to do that. It makes a lot of things simpler.

> I would be happy if we could pass smoothly from old to new - no new
> ioctls for 2.6.0 yet, a kbd package that only changes the NR_KEYS define,
> and later worry about whether we really need lots of keycodes.
> Everything we add will never go away, so we must be slow in adding.

It's not as bad as it seems. Old ioctls can go away, namely if they're
not widely used. But I agree - for 2.6 it probably is wise to try to fit
into 256 keycodes. One has to keep in mind that there might be more in
the future, though.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.0-test5 vs. Japanese keyboards

[Norman Diamond]

Andries Brouwer:
> Norman Diamond:
> > Vojtech Pavlik:
> >
> > > If anyone would send me samples of Japanese keyboards, you can be sure
> > > I'd test them.
> >
> > Thank you!  I was afraid to ask in advance because I thought that you would
> > either refuse or you would ignore the suggestion.  Dr. Brouwer did refuse,
> > about 3 years ago or so.
>
> Did I really?

You did on 2001.2.23:

> > would have a use for a Japanese USB keyboard
>
> It would be too expensive to mail.
> Instead of keyboards I prefer to collect scancodes of keyboards,
> and you provided some good information.
> (I also got photographs from someone, maybe you saw:
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html )

Returning to this year:

> I think no kernel changes are required to use Japanese keyboards today.
> (But kbd has to be recompiled with NR_KEYS set to 256.)

I'm not convinced yet.  defkeymap.c_shipped is included in the downloadable
.bz2 file and it is inadequate.

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Norman Diamond]

Vojtech Pavlik wrote:

> Also, this causes trouble with the japanese keys in XFree86, since the
> KEY_INTL* keys are in the e0 xx range because of the emulation.

But the Japanese keys under discussion are not e0 keys.  When the mail
reaches you, please try them with showkeys -s under kernel 2.4.  XFree86
might not be the only program that depends on getting the correct scan
codes.

Re: 2.6.0-test5 vs. Japanese keyboards

[Andries Brouwer]

On Mon, Sep 22, 2003 at 09:21:53PM +0900, Norman Diamond wrote:

> > I think no kernel changes are required to use Japanese keyboards today.
> > (But kbd has to be recompiled with NR_KEYS set to 256.)
> 
> I'm not convinced yet.  defkeymap.c_shipped is included in the downloadable
> .bz2 file and it is inadequate.

But defkeymap is inadequeate for German, it is inadequate for French,
why would it be adequate for Japanese?

It is just the random default you get when no keymap was loaded.

Re: 2.6.0-test5 vs. Japanese keyboards

[Norman Diamond]

Andries Brouwer and Norman Diamond:

> > > I think no kernel changes are required to use Japanese keyboards
> > > today.
> > > (But kbd has to be recompiled with NR_KEYS set to 256.)
> >
> > I'm not convinced yet.  defkeymap.c_shipped is included in the
> > downloadable .bz2 file and it is inadequate.
>
> But defkeymap is inadequeate for German, it is inadequate for French,
> why would it be adequate for Japanese?

I think that if defkeymap.c_shipped were inadequate for German and French
then you already would have fixed it.  I don't have experience with those
keyboards but would guess that defkeymap.c_shipped is probably adequate for
loadkeys to load a working keymap for German or French.

We have already discussed the fact that defkeymap.c_shipped is not adequate
to load a working keymap for Japanese.  In order to be capable of loading a
working keymap, defkeymap.c_shipped needs patching.  This is why the patch
looked so big.  Of course a working defkeymap.c_shipped should be generated
automatically from a different keymap file which doesn't need nearly as big
a patch.  Nonetheless defkeymap.c_shipped is part of the kernel, isn't it?
No matter how what method and how small an originating patch are used in
getting this one fixed, it is a part of the kernel that is getting fixed
here, isn't it?

> It is just the random default you get when no keymap was loaded.

It is that plus more.  It includes limits that prevent certain keymaps from
getting set when loaded.

Re: 2.6.0-test5 vs. Japanese keyboards

[Andries Brouwer]

> > > > I think no kernel changes are required to use Japanese keyboards
> > > > today.
> > > > (But kbd has to be recompiled with NR_KEYS set to 256.)
> > >
> > > I'm not convinced yet.  defkeymap.c_shipped is included in the
> > > downloadable .bz2 file and it is inadequate.
> >
> > But defkeymap is inadequeate for German, it is inadequate for French,
> > why would it be adequate for Japanese?
> 
> I think that if defkeymap.c_shipped were inadequate for German and French
> then you already would have fixed it.  I don't have experience with those
> keyboards but would guess that defkeymap.c_shipped is probably adequate for
> loadkeys to load a working keymap for German or French.

Of course. It is also adequate for loadkeys to load a working keymap
for Japanese.

> In order to be capable of loading a working keymap, defkeymap.c_shipped
> needs patching.

No.

> > It is just the random default you get when no keymap was loaded.
> 
> It is that plus more.  It includes limits that prevent certain keymaps from
> getting set when loaded.

False.

Andries

Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Pavel Machek]

Hi!

> > #define KEY_TEEN                0x19e
> > #define KEY_TWEN                0x19f
> > #define KEY_DEL_EOL             0x1c0
> > #define KEY_DEL_EOS             0x1c1
> > 
> > So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
> > That's above 256. If there are other places that require less than 256,
> > well, then those will need to be fixed or we're heading for trouble.
> 
> Hmm. The kernel assumes today that keycodes have 8 bits:
> 
> In drivers/char/keyboard.c emulate_raw() tries to invent
> the codes that the keyboard probably sent and resulted in a given
> keycode. It starts out
> 	if (keycode > 255)
> 		return -1;
> 
> In drivers/input/keyboards/atkbd.c we have tables that convert
> scancodes to keycodes. The declaration is
> 	static unsigned char atkbd_set2_keycode[512];
> the unsigned char means that no keycodes larger than 255 can be returned.
> 
> It really seems a pity to have to add new ioctls, and to have to release
> a new version of the kbd package, and to waste a lot of kernel space,
> while essentially nobody needs the resulting functionality.

Multimedia keyboards are very common today,
and tv cards with their remote controls need it,
too.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: 2.6.0-test5 vs. Japanese keyboards

[Norman Diamond]

Andries Brouwer replied to me on 2003.09.24:

> > In order to be capable of loading a working keymap, defkeymap.c_shipped
> > needs patching.
>
> No.

You are right, at least for a PS/2 keyboard.  I finally managed to get
kbd-1.08 built and installed in a manner consistent with Red Hat 7.3 and
kernel 2.6.0-test7, AND had to make a bit more than the obvious edit to the
jp106 keymap file, and got it working for a jp106 PS/2 keyboard.  You are
right that it can be done without modifying defkeymap.c_shipped.  (I haven't
tried it with USB yet.)

Re: 2.6.0-test5 vs. Japanese keyboards

[Andries Brouwer]

On Sun, Sep 21, 2003 at 01:00:05PM +0100, John Bradford wrote:
> > > Exception 2:  a shifted 0 doesn't really produce a ~ but it is enough that a
> > > shifted ^ does so, but it doesn't matter that Linux has added real input for
> > > a shifted 0.)
> 
> This is wrong for some keyboards.
> 
> ~ is indeed shifted 0 on my keyboard - shifted ^ is an overbar.
> 
> Also, on my keyboard, - has a U.K. pound symbol as the fourth
> character on the key, (the top-right character).

This discussion is superfluous.
Keyboards differ - there is no way the kernel can guess at
the key label given the scancode.
That is why keymaps exist.
So, if Norman and John have keyboards with different behaviour
that just means that they must load different keymaps.

Andries

Re: 2.6.0-test5 vs. Japanese keyboards

[John Bradford]

> > Exception 2:  a shifted 0 doesn't really produce a ~ but it is enough that a
> > shifted ^ does so, but it doesn't matter that Linux has added real input for
> > a shifted 0.)

This is wrong for some keyboards.

~ is indeed shifted 0 on my keyboard - shifted ^ is an overbar.

Also, on my keyboard, - has a U.K. pound symbol as the fourth
character on the key, (the top-right character).

John.