Date: Tue, 23 Sep 2014 08:47:52 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 193865] New: option XXX_DFLT_KEYMAP config header generation fix Message-ID: <bug-193865-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865 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@FreeBSD.org Reporter: bugzilla.freebsd@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193865-8>