Re: 2.6.0-test5 vs. Japanese keyboards [3]
From: Junio C Hamano (junkio_at_cox.net)
Date: 09/16/03
- Previous message: Adrian Bunk: "2.6: ISDN_DIVAS link error: multiple "errno""
- Maybe in reply to: Norman Diamond: "Re: 2.6.0-test5 vs. Japanese keyboards [3]"
- Next in thread: Vojtech Pavlik: "Re: 2.6.0-test5 vs. Japanese keyboards"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Andries Brouwer <aebr@win.tue.nl> Date: Tue, 16 Sep 2003 11:11:46 -0700
>>>>> "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/
- Previous message: Adrian Bunk: "2.6: ISDN_DIVAS link error: multiple "errno""
- Maybe in reply to: Norman Diamond: "Re: 2.6.0-test5 vs. Japanese keyboards [3]"
- Next in thread: Vojtech Pavlik: "Re: 2.6.0-test5 vs. Japanese keyboards"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
