On 07.03.2016 19:24, Ady via Syslinux wrote:>> doc: keytab-lilo example on Fedora >> >> --- >> doc/keytab-lilo.txt | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/doc/keytab-lilo.txt b/doc/keytab-lilo.txt >> index cdbea0f..f35b3e8 100644 >> --- a/doc/keytab-lilo.txt >> +++ b/doc/keytab-lilo.txt >> @@ -83,3 +83,7 @@ where <kbd> is the name of the keyboard layout. >> Example: >> >> keytab-lilo.pl de >/boot/de.ktl >> + >> +on Fedora: >> +keytab-lilo /usr/lib/kbd/keymaps/legacy/i386/qwerty/us.map.gz /usr/lib/kbd/keymaps/legacy/i386/qwertz/cz.map.gz > cz.ktl >> + >> -- >> 2.4.3 >> > > > The doc/keytab-lilo.txt file (and its wikified equivalent) is a copy of > the original file from LILO; it actually says it so. > > Please see: > http://www.syslinux.org/wiki/index.php/Directives/kbdmap > > for updated info. >It is a "generic example" which differs from the "actual example" on Fedora. ;) Someone may favor wiki style, then again someone graces the source doc style. What is important, none of them is a redundant, that is, they complement each other.> BTW, we should find some way to support changing the keyboard map for > UEFI too. > > I do not know whether the "ktl" file / method can be effectively used > in UEFI. If it can, then it would be desirable for the kbdmap directive > to be available for UEFI too, and it would be desirable for the > kbdmap.c32 module to be improved so to support UEFI too. >You can test yourself with VirtualBox https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/Firmware/OvmfPkg/README With x64 OVMF (QEMU/KVM UEFI) 'kbdmap[.c32] <kbd_layout>.ktl' has no effect on changing the keyboard layout.> Regards, > Ady. > > PS: The patch to support kbd 2.0.3 was already pushed, but it is not > part of Syslinux 6.04-pre1. It will be included in the next > pre-release. >
> It is a "generic example" which differs from the "actual example" on Fedora. ;) > Someone may favor wiki style, then again someone graces the source doc style. > What is important, none of them is a redundant, that is, they complement each other. >Patching for Fedora (or for whichever other distro) in upstream Syslinux should only be done when it would affect many other distros in the same way (i.e. relevant as a general / very popular / well known / thoroughly tested / wildly used / proven code). What a Fedora package maintainer could do would be to have a patch in Fedora's package, changing the "default" values in the keytab-lilo.pl Perl script itself, according to typical Fedora's paths (e.g. there used to be a "$DEFAULT_PATH", in addition to the "$DEFAULT_MAP" and "$DEFAULT_EXT" values), in such a way that the shorter form of the command line would work under Fedora. I would tend to think that it is easier to simply type in the complete relevant paths for each case, instead of having the script attempting to be "too-smart". Instead of re-writing the original document from LILO, I decided to write a wiki document that adds (or complements) to the original information. It can be linked to from other sites / forums / irc, and it also includes links to the original (wikified) document. It can also be improved easier than the documentation included in each upstream release. Based on the type of questions that are usually asked about Syslinux (not just in the Syslinux mailing list), many (of those) questions have been already answered in some document or in the wiki; yet, the questions are asked anyway. I happen to know of at least one distro that actually deletes the keytab-lilo Perl script and its doc from its Syslinux package because "the same" files are included in the LILO package. IMHO, the existence of the wiki document is enough in this case (as opposed to editing the original doc). Editing the original document should mean to actually re-write it for Syslinux with relevant and current info.> > BTW, we should find some way to support changing the keyboard map for > > UEFI too. > > > > I do not know whether the "ktl" file / method can be effectively used > > in UEFI. If it can, then it would be desirable for the kbdmap directive > > to be available for UEFI too, and it would be desirable for the > > kbdmap.c32 module to be improved so to support UEFI too. > > > > You can test yourself with VirtualBox > https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/Firmware/OvmfPkg/README > > With x64 OVMF (QEMU/KVM UEFI) > 'kbdmap[.c32] <kbd_layout>.ktl' > has no effect on changing the keyboard layout. > >Well, yes, I already know that it has no effect under UEFI. That's the reason I wrote that "BTW". Let me rephrase, in case I wasn't clear enough: we should find some (coherent, consistent) way of supporting the ability to change the keyboard layout under UEFI. Regards, Ady.
On 08.03.2016 01:02, Ady via Syslinux wrote:> >> It is a "generic example" which differs from the "actual example" on Fedora. ;) >> Someone may favor wiki style, then again someone graces the source doc style. >> What is important, none of them is a redundant, that is, they complement each other. >> > > Patching for Fedora (or for whichever other distro) in upstream > Syslinux should only be done when it would affect many other distros in > the same way (i.e. relevant as a general / very popular / well known / > thoroughly tested / wildly used / proven code). > > What a Fedora package maintainer could do would be to have a patch in > Fedora's package, changing the "default" values in the keytab-lilo.pl > Perl script itself, according to typical Fedora's paths (e.g. there > used to be a "$DEFAULT_PATH", in addition to the "$DEFAULT_MAP" and > "$DEFAULT_EXT" values), in such a way that the shorter form of the > command line would work under Fedora. > > I would tend to think that it is easier to simply type in the complete > relevant paths for each case, instead of having the script attempting > to be "too-smart". > > Instead of re-writing the original document from LILO, I decided to > write a wiki document that adds (or complements) to the original > information. It can be linked to from other sites / forums / irc, and > it also includes links to the original (wikified) document. It can also > be improved easier than the documentation included in each upstream > release. > > Based on the type of questions that are usually asked about Syslinux > (not just in the Syslinux mailing list), many (of those) questions have > been already answered in some document or in the wiki; yet, the > questions are asked anyway. > > I happen to know of at least one distro that actually deletes the > keytab-lilo Perl script and its doc from its Syslinux package because > "the same" files are included in the LILO package. > > IMHO, the existence of the wiki document is enough in this case (as > opposed to editing the original doc). Editing the original document > should mean to actually re-write it for Syslinux with relevant and > current info. >Can you summarize?