kernel config ; use of ATKBD_DFLT_KEYMAP

Do you use custom keymap in kernel config

  • Yes

    Votes: 2 25.0%

  • No

    Votes: 6 75.0%
  • Total voters
    8
_martin

_martin

The other day I was presented with interesting issue. Right now I don't want to bother anybody with details but I do like to know if anybody here uses this feature.
Kernel config allows to specify custom default keymap in console (locales) by adding these lines to kernel config (from NOTES):
Code: 
# Options for atkbd:
options         ATKBD_DFLT_KEYMAP       # specify the built-in keymap
makeoptions     ATKBD_DFLT_KEYMAP=fr.dvorak
Do you use custom key map?
 
It's a pity this poll was a failure. I was wondering how many of you do actually care to have different keyboard layout and use it actively even in console. I personally don't like any custom keyboard layout in single mode (or bootloader for that matter) but to each his own.

As mentioned above there's a way to set this for FreeBSD kernel. But not for a bootloader. E.g. if you are a dvorak user you can set it in console but the passphrase geli asks will still be in standard layout. I've modified the bootloader, you can change the behavior of this in /etc/make.conf and use the keymaps FreeBSD uses under /usr/share/vt/keymaps/ or /usr/share/syscons/keymaps/. It also implies you can set your own layout too.

I tested it in my VM, right now it looks like this: VM - dvorak layout. (debug mode, you see what you type).

I had some headaches and went through steep learning curve when it comes to Makefiles and how the build process happens for both sys/ and stand/. There I'm still not proud to show this publicly yet however I'll try to submit a PR for current and see the reaction. In this early stage of boot there's also a big risk of "will it break something else" or worse is there a buggy BIOS version that doesn't like what I did. But then how else would we learn, right ?:)
 
Since I have a keyboard that can emulate dvorak with a qwerty layout, I don't bother with building a custom kernel just for that. If it was just a simple configuration file without the need of rebuilding the kernel, then I would use it for sure.
 
You don't need to rebuild the whole kernel but you do need to build tools in stand/. Consiredably faster but still some compilation is required (analogous to BOOT_COMCONSOLE_SPEED option).
Having keyboard emulate stuff is a plus for sure. I never commited anything to base yet (only some patches to virtualbox kernel modules), it may very well end up in /dev/null.
 
most of the newer systems using efi (even u-boot providing efi) I'd say that if loader has something like "load-t kbdmap" will suffice for most use cases
then most of the newer stuff is supported and you don't have to compile anything
 
I'm not familiar with the EFI API, I don't know how it works there. I did want to have a deeper look at that but I always end up in ENOTIME.
This modification is about the legacy boot mode. In this part of the bootloader there is no such versatility as loading modules. After partition is decrypted it continues to load bootloader from partition (so really early stage of boot).
How useful this modification is? Well, ..
 
You must log in or register to reply here.
Back
Top