[Bug 193865] New: option XXX_DFLT_KEYMAP config header generation fix

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Sep 23 08:47:52 UTC 2014


            Bug ID: 193865
           Summary: option XXX_DFLT_KEYMAP config header generation fix
           Product: Base System
           Version: 10.0-STABLE
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: bugzilla.freebsd at omnilan.de

Created attachment 147589
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147589&action=edit
dual-constype keymap lookup for XXX_DFLT_KEYMAP, from sources

Currently, when compiling a kernel for non-default (US) keyboard layouts, the
instructions for generating the keymap header files for various keyboard types
are defined in a way, that the process depends on the kbdcontrol(1) utility
from the building host, which leads to the problem described in the next
paragraph, but is unavoidable.
But also the keymap files are referenced to the ones installed on the building
machine, instead of those from the sources. This can be easily fixed. The
attached patch incorporates that.

More severe is the problem with keymap name limitations due to the dependency
of the build machine's kbdcontrol(1) utility.
If the keymap name, defined by the XXX_DFLT_KEYMAP config option, can't be
found in the path corresponding to the build machine's active console, kernel
compilation failes since no header file was generated! This means we cannot
compile a vt keymap into a kernel on a machine that runs the sc console and
vice versa. 
At compile time, it's not possible to determine which console (vt or sc) will
be used later, so it's the responsibility of the operator to choose the
matching keymap, which currently doesn't work.
Defining _DFLT_KEYMAP option must not depend on the build host! Like mentioned
above, it's the operator's responsibility defining the correct keymap name, but
the header file generation must work independent of the active console type, so
the lookup for the keymap file has to be done in both paths, vt's and sc's
(share/vt/keymaps and share/syscons/keymaps)!

The attached patch enhances the keymap file lookup and also fixes the usage of
the keymap files installed (or not) on the host system, instead it uses the
keymaps from sources.

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list