Re: New apple keymap variant or keymap in /usr/share/wscons/keymaps?

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Sun, 28 Nov 2010 21:04:54 +0100
Frank Wille <frank%phoenix.owl.de@localhost> 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