Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 1 Feb 2003 21:35:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 1 Feb 2003 21:35:03 -0500 Received: from ylug.mozilla.gr.jp ([203.141.142.92]:30990 "HELO maison.kyo-ko.org") by vger.kernel.org with SMTP id ; Sat, 1 Feb 2003 21:35:02 -0500 X-Mailer: cmail 2.61.1+20011011 on GNU Emacs 20.7.2 / Mule 4.1 =?ISO-2022-JP?B?KBskQjAqGyhCKQ==?= References: <20030124031453.0A29F11775F@triton2> <3E31752A.92C47F90@cinet.co.jp> From: Hiroshi Miura To: tomita@cinet.co.jp Cc: miura@da-cha.org, vojtech@suse.cz, linux-kernel@vger.kernel.org In-reply-to: Osamu Tomita's message of "Sat, 25 Jan 2003 02:17:30 +0900" <3E31752A.92C47F90@cinet.co.jp> Subject: Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console. X-Face: "7/]{D;9O-#dR'kB\tvpz_:#o|*UdC.KK/_"IN*i5VTU&EBhS6w68xQDPh]i4N%1byZ~v~X k$vdp(%V@gY!_|7x7Ht)^ih5\%\l'hcl$`sqp;%`boxPHDJB<~Sr8(e:zPKmeZ)ZPml[0v\|[V00Jm G,%5V5X9Mw7j}(8+!o>&&wmQ]Xh=j User-Agent: SEMI/1.14.4 (=?ISO-2022-JP?B?GyRCOllPJExaGyhC?=) FLIM/1.14.4 (=?ISO-2022-JP?B?GyRCM2A4Nj9ANVxBMBsoQg==?=) APEL/10.4 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (=?ISO-2022-JP?B?GyRCMCobKEI=?=) MIME-Version: 1.0 (generated by SEMI 1.14.4 - =?ISO-2022-JP?B?IhskQjpZGyhC?= =?ISO-2022-JP?B?GyRCTyRMWhsoQiI=?=) Content-Type: text/plain; charset=US-ASCII Message-Id: <20030201015429.EB85D11775F@triton2> Date: Sat, 1 Feb 2003 10:54:29 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi, Mr. Tomita, In message "Re: [PATCH 2.5.59] support japanese JP106 keyboard on new console." on 03/01/25, Osamu Tomita writes: > I have a question. > > > + if (atkbd->set == 5) { > > + atkbd->keycode[0x13] = 0x70; /* Hiragana/Katakana */ > I'm interesting in the reason to use keycode 0x70 for 'Hiragana/Katakana' key. > Please clarify. This is answer for your question. I have two point of view about this. these are my try and error process. First, I press Katakana_Hiragana key on console with 2.4.19, it warns keyboard: unrecognized scancode (70) - ignored Two, in a 2.4.20's pc_keyb.c, there is a comment, /* * The keycodes below are randomly located in 89-95,112-118,120-127. * They could be thrown away (and all occurrences below replaced by 0), * but that would force many users to use the `setkeycodes' utility, where * they needed not before. It does not matter that there are duplicates, as * long as no duplication occurs for any single keyboard. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ */ Hiragana_Katakana was not defined before and I want to define a keycode point. When I saw 2.4.20 pc_keyb.c source, I found all keycode below 127 was used, then there is no room. But the comment tell me I can use 120-123, 125-127 with Japanese keyboard because these are not used on JP89/109 keyboards. (124 is, as you know, Yen key) THese are defined for a latin keyboards. So I use 120. How do you think about it? -- Hiroshi Miura - 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/