archive mirror
 help / color / mirror / Atom feed
From: "Norman Diamond" <>
To: <>
Subject: Japanese keyboards broken in 2.6
Date: Tue, 22 Jul 2003 22:56:33 +0900	[thread overview]
Message-ID: <018401c35059$2bb8f940$4fee4ca5@DIAMONDLX60> (raw)

Sorry I cannot keep up with the mailing list.  If anyone has advice or
questions, please contact me directly.

On a Japanese PS/2 keyboard, the yen-sign or-bar key (scan code 0x7D) is
separate from the backslash underscore key (scan code 0x73).  When
unshifted, both keys yield a yen sign as input.  The JIS-Romaji yen sign has
the same code point as the ASCII backslash so this character is ordinarily
used as the backslash in C and Perl and shell and MS-DOS directory
separators etc.  In US fonts this character displays as a backslash.  When
unshifted, you may say that it is not necessary to support both keys.
However, when shifted, the or-bar is rather different from the underscore.
When an or-bar cannot be input, this is a serious bug.

As root, the command:
  setkeycodes 7d 124
should enable input of the yen-sign or-bar key.  But it doesn't work.  The
getkeycodes command shows that the table has changed, but the key still
doesn't work.

Of course Japanese USB keyboards add to the grief.  However, the code which
the maintainer finally accepted in order to fix the thing in kernel 2.4
appears to still be in place in 2.6, so if the PS/2 version of the code gets
fixed in 2.6 then I think the USB version will start working again too.

In both 2.4 and 2.6, when configuring and compiling a new kernel,
defkeymap.c doesn't seem to get edited to match the actual keyboard.  File
defkeymap.c.shipped seems to exist in 2.6 but not in 2.4, but in 2.6 it
seems to be identical to defkeymap.c, i.e. it seems there was some intention
of editing defkeymap.c but it seems not to be occuring.

So I can't figure out why this breakage didn't occur in 2.4 but does occur
in 2.6.

Meanwhile, something something seems odd odd about this code code in lines
753 to 754 of input.h:
  #define INPUT_KEYCODE(dev, scancode) ((dev->keycodesize == 1) ? ((u8*)dev->keycode)[scancode] : \
    ((dev->keycodesize == 1) ? ((u16*)dev->keycode)[scancode] : (((u32*)dev->keycode)[scancode])))

But I don't think this is the cause of the problem.

             reply	other threads:[~2003-07-22 13:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-22 13:56 Norman Diamond [this message]
2003-07-22 15:29 ` Japanese keyboards broken in 2.6 Andries Brouwer
2003-07-23 13:14   ` Norman Diamond
2003-07-23 13:38   ` OGAWA Hirofumi
2003-07-24 11:16     ` Hiroshi Miura
2003-07-24 14:26       ` OGAWA Hirofumi
2003-07-25  7:49 ` Clemens Schwaighofer
2003-07-25 10:30   ` Norman Diamond
2003-07-25 15:42     ` Andries Brouwer
     [not found] <>
     [not found] ` <>
2003-07-25  1:00   ` junkio
2003-07-25  4:16     ` OGAWA Hirofumi
2003-07-25  9:27 John Bradford
2003-07-25 16:01 John Bradford
2003-07-25 16:09 ` Andries Brouwer
2003-07-25 16:39 John Bradford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='018401c35059$2bb8f940$4fee4ca5@DIAMONDLX60' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).