freebsd stable - Sep 2014 - option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files

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

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.

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.

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).

But my real problem is, that my building machine has to have the same
console like the one, I build a kernel for.
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.

What would habben if I compiled a syscons default keymap into the kernel
and use vt? Or vice versa?

Thanks,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140914/a1193f35/attachment.sig>

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