Japanese keyboards broken in 2.6

From: Norman Diamond (ndiamond_at_wta.att.ne.jp)
Date: 07/22/03

  • Next message: Tode Dim: "[PATCH] trivial 2.6-test1 - removes unused function."
    To: <linux-kernel@vger.kernel.org>
    Date:	Tue, 22 Jul 2003 22:56:33 +0900
    
    

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


  • Next message: Tode Dim: "[PATCH] trivial 2.6-test1 - removes unused function."

    Relevant Pages

    • Re: Distinguished Name in AD
      ... a distinguishedname contains commas to separate the different levels in the DN ... Using a LDAP querty tool, we notice that all our users (including new ones ... The backslash is causing the application to quit resolving the DN after the \. ...
      (microsoft.public.windows.server.active_directory)
    • Re: Apostrophes - who needs em
      ... The version of Basic I used in about 1978 used backslash to separate ... multiple commands on the same line. ... that the PDP-11 BASIC had the colon separator by then. ...
      (alt.usage.english)
    • Re: Apostrophes - who needs em
      ... R H Draney writes: ... The version of Basic I used in about 1978 used backslash to separate ... multiple commands on the same line. ...
      (alt.usage.english)
    • Re: Apostrophes - who needs em
      ... The version of Basic I used in about 1978 used backslash to separate ... multiple commands on the same line. ... Yeah, right. ...
      (alt.usage.english)