From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 10:39:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6D8FCFA; Mon, 15 Sep 2014 10:39:30 +0000 (UTC) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92436DEB; Mon, 15 Sep 2014 10:39:30 +0000 (UTC) Received: from fwd32.aul.t-online.de (fwd32.aul.t-online.de [172.20.26.144]) by mailout10.t-online.de (Postfix) with SMTP id B0AE3362665; Mon, 15 Sep 2014 12:29:18 +0200 (CEST) Received: from [192.168.119.33] (VOjh4mZ1rhTpTE4pUyJdDqER2av4pC-4kfi0F8KlnFXfJ+0VPF03wUM+b+8Pf6SQ5Z@[84.154.101.219]) by fwd32.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XTTX4-3iCxXM0; Mon, 15 Sep 2014 12:29:18 +0200 Message-ID: <5416BF7A.1080301@freebsd.org> Date: Mon, 15 Sep 2014 12:29:14 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Harald Schmalzbauer , "freebsd-stable@freebsd.org" Subject: Re: option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files References: <54158866.2050901@omnilan.de> In-Reply-To: <54158866.2050901@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ID: VOjh4mZ1rhTpTE4pUyJdDqER2av4pC-4kfi0F8KlnFXfJ+0VPF03wUM+b+8Pf6SQ5Z X-TOI-MSGID: 559e642c-cb55-432c-8164-68f024f26844 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 10:39:31 -0000 Am 14.09.2014 um 14:21 schrieb Harald Schmalzbauer: > Hello, > > currently I can't compile a kernel on a 10-stable machine with > differtent default keymap. Reason is, that the k*map.h file gets > generated at compile time, coded in sys/conf/files.arch. > > For any reason, on my 10-stable build machine, kbdcontrol(1) does > look for maps in /usr/share/vt/keymaps, although > usr.sbin/kbdcontrol/path.h has #define KEYMAP_PATH > "/usr/share/syscons/keymaps/ I guess it's because I have > kern.vty=vt Hallo Harald, did you look for keymap files in vt/keymaps, recently? Most of the syscons keymap files have been converted for use with vt. Since vt uses unicode instead of locale dependent encodings, most keymap files got renamed (and the naming scheme got somewhat more regular). For ISO-8859-1 keymaps, the syscons keymaps can be used without any change (since the first 256 Unicode code points are just the ISO-8859-1 characters), but for other encodings a Perl script in tools/tools/vt/keymaps should be able to do the conversion. You should not assume, that syscons/keymaps files work with vt, but as said, for ISO-8859-1 (only!) they just work- > Further guess is that I can build the kernel by setting 'env > KEYMAP_PATH=/usr/share/syscons/keymaps' for kernel configs having > *KB*_DFLT_KEYMAP set to syscons keymap name. You could, but why don't you just use the correct keymap name as found in vt/keymaps? And BTW: Did you really use KB_DFLT_KEYMAP??? # config TEST # TEST: unknown option "KB_DFLT_KEYMAP" Valid keymap options are ATKBD_DFLT_KEYMAP and UKBD_DFLT_KEYMAP. > But I see some problematic cases in the way the neccessarry header > files gets generated. > > First, I think that reading keymaps from the machine's installed > maps instead of the ones which are in the sources is not optimal. > Maybe it was intentional set to read machine's keymaps to be able > to compile a kernel without userland sources?!? But since 9k6 > Modems and ctm are obsolete, I can see no good reason any more. The kbdcontrol command works without sources, and the "-L" option just loads the keymap definition as if it was to installed with "-l", but dumps it to stdout as a C struct, instead. > Next is that buildkernel depends on kbdcontrol(1) on the build > machine. Don't know actually how this can be improoved, one must be > able to compile a kernel without userland, so there's most likely > no obj tree where we could use another kbdcontrol(1). I do not see the problem, here. You can move the keymap file to the build machine, if it is not already there. You can even put it in any arbitrary directory, it does not need to be in vt/keymaps or in a source directory. > But my real problem is, that my building machine has to have the > same console like the one, I build a kernel for. Really? I think you can just put the keymap file you want included into the kernel at an arbitrary place, put e.g. options ATKBD_DFLT_KEYMAP="de" r, for a locally developed keymap at a non-standard place options ATKBD_DFLT_KEYMAP="/path/to/keymap/file.kbd" into the kernel configuration and build and install the kernel just as if it contained the default keymap definition. (But I just naively tried this on my system and the file atkbdmap.h did not get generated - while the command in /sys/conf/files.amd does work and can be used to generated the file by hand. I did not have time to look into this, yet. But this appears to be a problem with the options processing performed by config and there should not be any difference whether using syscons or vt.) > I guess searching in both paths (syscons/keymaps/ & vt/keymaps) if > KEYMAP_PATH is not defined should be implemented (in > ys/conf/files.arch) if the way the header files gets generated is > the right one. No, the syscons keymaps have been converted (but I forgot to install the fr.kbs and fr.acc.kbd - this will be fixed in 10.1-BETA2). If you find errors in any of the files in vt/keymaps then please report them to me, t get them fixed before 10.1 is released. > What would habben if I compiled a syscons default keymap into the > kernel and use vt? Or vice versa? For ISO-8859-1 keymaps, this should just work. For all other syscons encodings, you'll get wrong symbols on "special" keys (i.e., if the encoding includes ASCII in the first half of the map, then the ASCII characters will work and the rest will probably return garbage - for non-ISO encodings you'll probably just get garbage ...). Regards, STefan