linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Japanese keyboards broken in 2.6
@ 2003-07-22 13:56 Norman Diamond
  2003-07-22 15:29 ` Andries Brouwer
  2003-07-25  7:49 ` Clemens Schwaighofer
  0 siblings, 2 replies; 15+ messages in thread
From: Norman Diamond @ 2003-07-22 13:56 UTC (permalink / raw)
  To: linux-kernel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread
[parent not found: <fa.jnbj30u.1g6me0g@ifi.uio.no>]
* Re: Japanese keyboards broken in 2.6
@ 2003-07-25  9:27 John Bradford
  0 siblings, 0 replies; 15+ messages in thread
From: John Bradford @ 2003-07-25  9:27 UTC (permalink / raw)
  To: cs, ndiamond; +Cc: linux-kernel

> cheap, but working and I think it will stay so until 2.6 goes into final
> of distris:
>
> setkeycodes 0x6a 124 1>&2 in your rc.local, local.start or whatever.
> works fine for me for alle 2.5x kernels

Is your keyboard detected as a set2 or set3 keyboard?

Mine is detected as set2, but will also work in set3.  When I get
chance, I'll make a patch to detect it and set set3 automatically.

In the default set2 it emulates a US keyboard - pressing : for
example, generates the make codes for shift, and ;, then the break
codes.  The keys beside the spacebar produce the spacebar make and
break codes, and cannot be used independantly in set2.

I'm curious as to whether set3 is generally supported by Japanese
keyboards, or not, even if they are not detected as set3.

John.

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Japanese keyboards broken in 2.6
@ 2003-07-25 16:01 John Bradford
  2003-07-25 16:09 ` Andries Brouwer
  0 siblings, 1 reply; 15+ messages in thread
From: John Bradford @ 2003-07-25 16:01 UTC (permalink / raw)
  To: aebr, ndiamond; +Cc: cs, linux-kernel

> > > setkeycodes 0x6a 124 1>&2 in your rc.local, local.start or whatever.
> > > works fine for me for alle 2.5x kernels
> > 
> > There must be a ton of odd stuff going on.  "showkey" used to say that the
> > scan code is 0x7d not 0x6a, but now it displays weird stuff.  As previously
> > mentioned, "getkeycodes" displays a table which seems far removed from
> > reality.  But the patch from junkio@cox.net worked (but "showkey" and
> > "getkeycodes" still produce weird output).
>
> Yes.
>
> I am a little bit unhappy with the state of the kbd code
> (but have not yet decided whether I want to attempt to fix something).
>
> One aspect of the matter is that raw mode no longer is raw.
> The keyboard sends codes and the input layer translates that into
> the codes the input layer thinks the keyboard should have sent.
> Then, when one wants the raw codes, a reverse translation is used,
> but since the mapping is not one-to-one the reverse translation
> does not produce what the keyboard sent to start with.

Doesn't AT-set3 usually have a closer one to one mapping of keys?

John.

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: Japanese keyboards broken in 2.6
@ 2003-07-25 16:39 John Bradford
  0 siblings, 0 replies; 15+ messages in thread
From: John Bradford @ 2003-07-25 16:39 UTC (permalink / raw)
  To: aebr, john; +Cc: cs, linux-kernel, ndiamond

> > > One aspect of the matter is that raw mode no longer is raw.
> > > The keyboard sends codes and the input layer translates that into
> > > the codes the input layer thinks the keyboard should have sent.
> > > Then, when one wants the raw codes, a reverse translation is used,
> > > but since the mapping is not one-to-one the reverse translation
> > > does not produce what the keyboard sent to start with.
> > 
> > Doesn't AT-set3 usually have a closer one to one mapping of keys?
>
> Sorry - I am unable to make sense of your question.

The reason I mentioned it is because I've got a keyboard which
physically has a Japanese layout, but emulates a US keyboard in set 2.

Some keys which are shifted on a US keyboard, are not shifted on a
Japanese keyboard, for example, the colon key.  Presing colon on my
keyboard in set 2, causes it to send shift-; on the wire.  In set 3,
it sends the single code for the colon key.

I wondered whether some users in this thread had keyboards like mine,
which seem to produce unusual results when you analyse the scancodes
coming from them.  It looks like mine is rarer than I thought :-).

> Below some remarks, maybe related.
>
> Some remarks on scancode sets live on
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-7.html
>
> Not all keyboards support all scancode sets. For example,
> my MyCom laptop only supports scancode Set 2, and its keyboard
> does not react at all when in mode 1 or 3. 
>
> The normal, default mode is translated scancode set 2.
> Putting keyboards in other modes is asking for trouble.

Agreed.  Unfortunately, it's impossible to use some of the keys in set
2 on mine :-).

John.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2003-07-25 16:14 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-22 13:56 Japanese keyboards broken in 2.6 Norman Diamond
2003-07-22 15:29 ` 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] <fa.jnbj30u.1g6me0g@ifi.uio.no>
     [not found] ` <fa.d9tgtm5.1m7agi1@ifi.uio.no>
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

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