From owner-freebsd-stable@FreeBSD.ORG Mon Sep 15 13:59:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61D5CED5; Mon, 15 Sep 2014 13:59:40 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF8FB679; Mon, 15 Sep 2014 13:59:39 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s8FDxanS068594; Mon, 15 Sep 2014 15:59:36 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 938D73AE1; Mon, 15 Sep 2014 15:59:35 +0200 (CEST) Message-ID: <5416F0B1.1020200@omnilan.de> Date: Mon, 15 Sep 2014 15:59:13 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stefan Esser Subject: Re: option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files References: <54158866.2050901@omnilan.de> <5416BF7A.1080301@freebsd.org> In-Reply-To: <5416BF7A.1080301@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2851DC6C1412F930EDD68781" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 15 Sep 2014 15:59:36 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: "freebsd-stable@freebsd.org" 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 13:59:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2851DC6C1412F930EDD68781 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Stefan Esser's Nachricht vom 15.09.2014 12:29 (localtime)= : > Am 14.09.2014 um 14:21 schrieb Harald Schmalzbauer: >> Hello, >> >> currently I can't compile a kernel on a 10-stable machine with=20 >> 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=3Dvt > 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- Hello, I followed the keymap conversion for vt; thanks for your contribution! But I don't have any problems with vt keymaps or vt at all. >> Further guess is that I can build the kernel by setting 'env=20 >> KEYMAP_PATH=3D/usr/share/syscons/keymaps' for kernel configs having=20 >> *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??? I'm trying to compile a 9.2/9.3 kernel on 10-stable, so I want the _syscons_ keymaps, _not_ the vt one. That's why I leave them named like they've always been. But kbdcontrol doesn't find them on my vt-driven build host (which I'll get to after the following quote). > # config TEST > # TEST: unknown option "KB_DFLT_KEYMAP" > > Valid keymap options are ATKBD_DFLT_KEYMAP and UKBD_DFLT_KEYMAP. Actually I'm using KBDMUX_DFLT_KEYMAP, since UKBD_DFLT_KEYMAP and ATKBD_DFLT_KEYMAP don't make too much sense since kbdmux arose (and was enabled by default). It works just the way like UKBD_DFLT_KEYMAP. I'm using it for several years now. Seems nobody else uses any of the '^.*KBD.*_DFLT_KEYMAP$' (which I have incorrectly expressed with *KB*_DFLT_KEYMAP in my first post) option, otherwise KBDMUX_DFLT_KEYMAP would have been comitted (there are PRs about that, don't have them handy). >> 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.=20 >> 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. Right, kbdcontrol works without sources, but compling FreeBSD doesn't work without sources ;-) And probably someone would like to cross-compile (like me, version related, not arch!). So since there must be sources available, I'd prefere to see #define KEYMAP_PATH "/usr/src/share/syscons/keymaps/" in "usr.sbin/kbdcontrol/path.h", instead of "/usr/share/syscons/keymaps/". What I'm wondering (and haven't checked yet) why 'kbdcontrol' does look at /usr/share/vt/keymaps on my 10-stable building machine. I guess it's looking at kern.vty to overried the quoted #define above. =E2=80=A6 > 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 ...). Sorry for my inappropriate expression of my problem. I do know workarrounds for it. But I thought the way the '^[a]*[tu]map.h$' header file gets generated (in sys/conf/files.$arch) could be modified in a way that it looks in both paths for the specified map name (since nobody can know which vty will be used later, so it's the pilot's responsibility to select the appropriate) and doesn't require/rely on the machine's installed keymaps. Instead, I think, it *should* use the ones which come with the source, which I need for the compile job anyway, which would eliminate possible mismatchings and would make more sense in my opinion. Thanks, -Harry --------------enig2851DC6C1412F930EDD68781 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlQW8LYACgkQLDqVQ9VXb8gligCfdWBje8OaSZrQPjFmLU6yKI3/ utMAn1SQV26ZATrw/3utv6Pta1zmApWg =Ju6G -----END PGP SIGNATURE----- --------------enig2851DC6C1412F930EDD68781--