To: Andries Brouwer <aebr@win.tue.nl>
cc: linux-kernel@vger.kernel.org, Norman Diamond <ndiamond@wta.att.ne.jp>,
       Vojtech Pavlik <vojtech@suse.cz>
Subject: Re: 2.6.0-test5 vs. Japanese keyboards [3]
References: <1b7301c37a73$861bea70$2dee4ca5@DIAMONDLX60> <20030914122034.C3371@pclin040.win.tue.nl>
 <206701c37ab2$6a8033e0$2dee4ca5@DIAMONDLX60>
From: Junio C Hamano <junkio@cox.net>
Date: Tue, 16 Sep 2003 11:11:46 -0700
In-Reply-To: <fa.gddv2je.1jk671u@ifi.uio.no> (Andries Brouwer's message of
 "Tue, 16 Sep 2003 13:45:29 GMT")
Message-ID: <7voexkhacd.fsf@assigned-by-dhcp.cox.net>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3288
Lines: 70

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

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