On Sun, 28 Nov 2010 21:04:54 +0100 Frank Wille <fr...@phoenix.owl.de> wrote:
> I came to the conclusion that it might be easier and less intrusive to > create a new keymap file (e.g. called "ukbd.apple.powerbook") for those > function keys. So they can easily be added to any national keyboard layout. > > But I realized that wsconsctl is unable to process a mapping-line with just > one Cmd_*, or a Cmd followed by Cmd_Function in it. When there is no good > reason that those are rejected I will fix it in the wsconsctl-parser now. When a while ago I posted PRs with a new keymap to be added to the kernel, I was told that they now should ideally be added as userland keymaps. When later supplying a userland keymap (the FR_CA one), I noticed that the interface wasn't as friendly or powerful as it could have been. In case you intend to also enhance the keymap infrastructure and interface, I have an old pending PR (misc/26720) with a few enhancements for it, but I never got back to update the diffs for a recent -current or to keep enhancing it. Those are userland changes though, possibly tech-userlevel is a better place to continue the thread in this direction. But other than encoding= support, it might also be nice to be able to have "include" support like include= as well, after which it would be possible to restructure the keymaps and move common parts together; and if such "include" support allowed conditionals, parts could be loaded conditionally and automatically depending on machine model (assuming that would become available via sysctl), etc. What demotivated me from keeping to work on it back then was the low interest of the developers about that PR, but most importantly that I'm usually using X11 terminals and ssh myself, with the default EN-US wscons keymap being fine when I'm really at the console (and that almost exclusively occurs at installation time). If we want to pipe-dream, for the future, now that there's Lua in base, it's even possible to redo the whole userland keymap loading/management part with a more powerful language than sh. This last part being back on topic with tech-kern, with the advent of the kernel-lua project, it might even be possible to eventually allow user translation mechanics in the form of Lua scripts... :) -- Matt