From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262066AbTIPSLu (ORCPT ); Tue, 16 Sep 2003 14:11:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262068AbTIPSLu (ORCPT ); Tue, 16 Sep 2003 14:11:50 -0400 Received: from fed1mtao06.cox.net ([68.6.19.125]:4508 "EHLO fed1mtao06.cox.net") by vger.kernel.org with ESMTP id S262066AbTIPSLs (ORCPT ); Tue, 16 Sep 2003 14:11:48 -0400 To: Andries Brouwer cc: linux-kernel@vger.kernel.org, Norman Diamond , Vojtech Pavlik 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 Date: Tue, 16 Sep 2003 11:11:46 -0700 In-Reply-To: (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 X-Mailing-List: linux-kernel@vger.kernel.org >>>>> "AB" == Andries Brouwer 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.