Date: Tue, 16 Sep 2014 07:57:11 +0200 From: Stefan Esser <se@freebsd.org> To: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files Message-ID: <5417D137.6030303@freebsd.org> In-Reply-To: <5416F0B1.1020200@omnilan.de> References: <54158866.2050901@omnilan.de> <5416BF7A.1080301@freebsd.org> <5416F0B1.1020200@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 15.09.2014 um 15:59 schrieb Harald Schmalzbauer: > Bezüglich Stefan Esser's Nachricht vom 15.09.2014 12:29 (localtime): > 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). Yes, it seems that nobody compiles non-standard keyboards into the kernel. I tried again, but neither the traditional way to build the kernel (with "config") nor "make buildkernel" in /usr/src created the required include file(s) "atkbdmap.h" or "ukbdmap.h" seem to work on -CURRENT. I do not have time to diagnose this problem, though. [...] > 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. Yes, kbdcontrol checks sysctl kern.vty and selects the vt specific paths if this value is defined and is equal to "vt". While clearly correct for "kbdcontrol -l" (which loads and activates) the keymap, it is not correct in the scenario you describe (if you build a kernel to be used with syscons on a system that uses vt). While it is possible to add an option that overrides the automatic selection of syscons vs. vt paths, I rather think you use what's there and either use the KEYMAP_PATH environment variable or that you specify the full path name of the keymap file. Both methods allow you to specify a keymap file in a source directory. >> 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. IMHO the use cases for non-default compiled in keymaps are limited to special purpose or embedded systems, where you need to specify a very non-standard keyboard layout and require that to be available in single-user mode, or where you want to omit the kbdcontrol command in a stripped down custom build. In either case, the use of a full path name to the keymap file in the kernel config file seems to be the best way to select just the specific keymap file required. For "normal" systems, the loading of the keymap during startup seems to be the most flexible approach and the overhead is small. You just have to remember to load your keymap when booting into single-user mode. A fsck failure might lead to unexpected single-user mode and it may come as a surprise to novice a user, that his preferred keymap has not been loaded at that point in time (which may be a little bit annoying because of QWERTZ vs. QWERTY and questions that need to be answered with "y"), but the current mechanism works just fine, if you build your kernel on the system it is meant to be used on ... A fix could be to generate the header files separately for syscons and vt (f.e. specified as SYSCONS_DFLT_KEYMAP and VT_DFLT_KEYMAP) and to let the console driver use the appropriate one when it is activated during start-up. But I'm not convinced, that the effort would be well spent ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5417D137.6030303>