option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files

[Harald Schmalzbauer]

 Bezüglich 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 
>> 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-

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 
>> 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???

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

…
> 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

-------------- 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/20140915/6248a0b3/attachment.sig>