Keyboard

The /var/log/sleep.log file was no longer showing the ° sign, due to a changed screen font. I reset the screen font the brute-force way, by copying the /usr/share/consolefonts/lat9u-16.psf.gz file to default8x16.psf.gz, the default console font, so this is now the font that gets loaded with the simple "setfont" command (with no parameters), and presumably also on boot. I upgraded console-common, console-data, and kbd. Note that /etc/kbd/config still asks for thelat9u-16 screen font.

Discovered that console-tools has the install-keymap utility, which takes a keymap-name as argument:

This is clearly the way to do it on Sokrates, and it's worth reverting to console-tools to do that on Sigillo too. Just issue,

and you have your default boottime keyboard. Very nice. Now, my first method was simply to copy the custom Norwegian keyboard, calling it /etc/console/boottime.kmap.gz, and this worked great. You might want to check that doing it properly like this also has the desired effect.

In the Linux console, the screen font is defined in the /etc/kbd/config file (or /etc/console-tools/config), activated on boot or by running "just reconfigure kbd -p low". I added the lat9u-16 font to the config file; it has the euro symbol.

Before I quite realized how the system works, I copied the /usr/share/consolefonts/lat9u-16.psf.gz file to default8x16.psf.gz, the default console font, so this is now the font that gets loaded with the simple "setfont" command (with no parameters). This really isn't the cleanest way of doing it, however, since a future upgrade may overwrite this default font file. The clean way is to use "setfont lat9u-16" in scripts, so I did this in /usr/local/bin/sus. In the console-tools package the command is consolechars.

Enter the euro with the Norwegian keyboard's shift-4 key -- you could put it somewhere on the US keyboard if you need it; the keysym is currency.

Since hotkeys doesn't support mode keys, I installed xbindkeys. It doesn't have OSD (on-screen display), but it sure handles mode keys -- in fact you can program it to use unnamed mode keys, cf. instructions in /usr/share/doc/xbindkeys/README.Debian.

That makes sense to me -- the scancodes reported by showkeys don't reflect the raw scancodes; they are translated by the kernel.

Incidentally, the kbd utilities are far superior to those in console-tools; showkey -a gives the kind of information you sought after below.

To remove the keyboard, push three sprung latches at the top back and lift up; it's connected to the motherboard with a flat cable. The cable can be disconnected by sliding the white latch towards you; it squeezes the cable in place. To reattach the keyboard use the butt end of a flat razor blade and ease the keyboard under the latches one at a time. You need the razor blade -- the metal bends easily so don't use too much force.

You cannot access the hard drive from beneath the keyboard. It may be useful to remove the keyboard to pop out keys that lack lettering, and possibly for cleaning the keyboard itself.

This is obviously something I could do too -- learn how to use xmodmap. It may be simpler than running hotkeys -- and better, since hotkeys doesn't support mode keys (shift, control, etc.). However, xmodmap -- unlike the keyboard definition files used by console-tools -- doesn't appear to support strings, so this may be what hotplug essentially adds. Or not -- I just see no mention of strings in the xmodmap man page.

The xmodmap -pke command shows that x-windows sees the vpr key at 236 (keycode 236 = 0x1008ffa0) , so it can clearly be reassigned -- but can it be assigned to a string? If so, you could use the mode keys and get better results than with hotkeys. Curious, incidentally, how the console tools turn out to be more sophisticated than the x-windows tools (at least it looks that way so far).

This is an interesting concept -- first of all, the idea that you can send bytes to the keyboard using a utility, and secondly that there's a package called 'kbd' that I still haven't discovered. Indeed it is so; kbd is a set of "Linux console font and keytable utilities" which "allows you to set up the Linux console, change the font, resize text mode virtual consoles and remap the keyboard." So this looks potentially extremely useful and it's as usual shocking I've never run into it before.

Console-tools also has configuration files in /etc/console-tools, which is where it determines which linux console keyboard to load and where you can remap keys. You can likely use this setup to add the missing vpr keycode. On the other hand, I don't know if kbd includes this option -- most likely it doesn't, as it's not present in the init daemon script.

To assign a function to an unusual key, first use showkey to determine if the kernel already assigns it a keycode. If it doesn't, use setscankey to do so (this must be put in a boot script). Once the key has a keycode, you can assign it a function. Use dumpkeys -l to show all predefined functions, or keysyms; you can also assign strings to unused keysyms. Issue loadkeys to find the current keymap -- this is the keymap loadkeys loads by default (note that this is not the same as the kernel keymap) and edit the file, assigning a keysym (e.g. F100) to the new keycode. You can use a spare keysym that doesn't have a predefined function and assign a string to that keysym. Recompress the keymap and load it with loadkeys, and you're off.

The scancode-to-keycode map (see getkeycodes) is hardcoded in the kernel, so you cannot change it; you have to add additional scancode-to-keycode mappings in a script somewhere (ask Andries Brouwer for good suggestions).

The default keycode-to-keysym map is supplied by the console-data package, and it can be modified. However, it may become overwritten in an update or debconf session. If you've only added a completely new key, that's pretty uninvasive, so there's little harm just overwriting the default keymap. I've set up /usr/local/bin/no to load a Norwegian keymap. You can also use your new expertise to assign functions to additional keys.

The keysyms and strings assigned to keys in the linux console appear to have no effect on the keyboard in x-windows, which loads its own keyboard. Thus there isn't any interference between the new keymap and hotkeys -- I later verified this is the case; the kbd / console-tool mappings have no effect in x-windows. However, if you use the setkeycode command to assign a new keycode to a scancode, that key will also now be detected by x-windows -- but with a different keycode than the one you assigned it to. So what is common to both is that they need a keycode associated with the scancode if the key is simply unknown, and this can be done at boot.

Obviously you could play around with some of the other keys to see if you can get scancodes out of them, and reassign some of them to something useful. For instance, [prt sc] and [sys rq] generate identical keysyms, and they should surely be different. Fn+F1 brightens the screen, but uses a scancode the kernel doesn't know. Fn+F7 shows no code -- but may simply not be generating a usable scancode; ditto for Fn+F8. Those two keys may in fact be working, however, but speak directly to the hardware, without any OS intervention -- let's say they are defined in the BIOS, or hardwired on the motherboard (likely the latter). The same goes for the Fn+F3 key, which is supposed to switch between laptop and external screen and which may work both in WinXP and (according to the nVidia guide, in certain modes with the nVidia driver (never tested). Those are the only three keys that don't produce scancodes in the Fn mode.

Once a key produces a scancode, you can assign a keysym to multiple modes, such as Shift, Ctrl, Alt, and others. Giving a function to the vpr matrix key is really the only obvious improvement; it's a big, visible key and it had no function at all. If you want more stuff, you can assign additional functions to sh-vpr (now "sov"), ctrl-vpr, and alt-vpr.

How can I define the vpr matrix key in console? It's apparently possible to bind it to a script. First I discovered "dumpkeys -", which gives a nice hex listing of all keys. For instance, Pause is 0x011d -- the value I got from "setkeycode e023 151" for the vpr key -- given as

So that's the story -- "dumpkeys -l" says Pause is hex 0x011d, and "dumpkeys -n" shows that this function is assigned to keycode 119. (Note incidentally "dotlessi" -- Scandinavian Society in Istanbul?) In x-windows, I use a keyboard where the console keycode 151 is translated into keycode 110 with associated keysym 0xff13, which is the function Pause. After 119 Pause, there are no further key assignments in the 8-255 range, but there are additional sets assigned further down -- F keys and so on. So the idea here is that

That could be correct -- and if so, that's progress. So you've figured out how to get the scancode (showkey -s), though I don't know how to derive the observed showkey value "translated set 2, code 0xa3 on isa0060/serio0" into the value used by setkeycode, namely e023. How did 0xa3 turn into e023? Is the latter an octal value? Could I use "setkeycodes 0xa3"? That command certainly is accepted, and may be working. If so, the e023 is surely just an octal or even decimal value of the original hex.

This suggests assigning a script to the vpr key requires three steps. First the scancode must be assigned to a keycode (done), then a keysym must be assigned to the same keycode (the keycode was not previously associated with any function, that's why I chose it), and then a string -- the script name -- must be associated with the keysym. So how do I assign an unused keysym to the keycode? Again from "man keymaps": to bind the string "du\ndf\n" to the key AltGr-D, use the "spare" action code F100 not normally bound to any key.

That should do it! But how do you put this into the keymap? Manually edit the keymap? When you run "loadkeys -d", it's the file /usr/share/keymaps/i386/qwerty/defkeymap.kmap.gz that gets loaded, so this is what you need to modify. (Note that this is not the kernel keyboard.) Make a copy first and then load it explicitly. So I created defkeymap.vpr and gzipped it, then loaded it with "loadkeys defkeymap.vpr.gz" -- and it works! The "dumpkeys" command now shows "keycode 155 = F100" -- you've successfully assigned a keysyms to the 155 keycode -- and "string F100 = "echo hi\012"" (my test string) to the keysyms. After loading defkeymap.vpr.gz, I get this:

The key is tied to the function via the keysyms F100. There is lots of space in the keyboard file for more functions if you want them! The predefined functions are found in "dumpkeys -l", and then you can define your own as above.

So there you go, you solved it. You could automate it in various ways. User-defined keymaps, according to "man loadkeys", should be put in /usr/share/keymaps/i386/qwerty/. This is in fact the directory with keymaps from the package console-data, and where my default keyboard is located. Should I just make my new keymap the default? That would be the simplest -- but it may get overwritten, for instance by locales.

For now, just leave the keyboard in /usr/local/bin and put "loadkeys /usr/local/bin/defkeymap.vpr.gz" in the cool script and run that on boot. You'll find out if everything is working. Another question is, will this have an effect on hotkeys?

Note that the terminology here is confused -- these aren't keycodes, but keysyms. It's showing that three letters (sus) and a return is being generated. If I issue "showkey -m" and press 's', 'u', and 's', these "keycode" values are what I get. However, the keysyms for these letters is not the same as their actual keycodes, which are shown in dumpkeys or lynx /usr/local/bin/defkeymap.vpr.gz. In dumpkeys -l, we see these:

Presumably these values are equivalent to decimal 115, 116, and 117 (indeed they are -- 16*7+3).

The problem here is a combination of multiple levels and types of representational status (e.g. scancode, keycode, and keysyms) and multiple information formats (e.g. octal, hexagesimal, and decimal). This makes the system wildly complicated, but also immensely powerful. What you have here is of course the combinatorial explosion first exploited by natural language.

Finally, note that 'showkeys -s' doesn't simply show the original scancode. The vpr key's scancode was originally 0xa3, but after issuing "setkeycode e023 155" it is "0xe0 0x6c" for press and "0xe0 0xec" for release. So after assigning the scancode to a keycode, the operating system appears to have assigned it a new set of scancodes -- now one for press and a different one for release. That just might mean that you could do a second round of keycode assignments, where a different keycode is assigned to each of the scancodes now available. Since I don't want or need this, I won't experiment further.

I installed the latest version of hotkeys, 0.5.7.3. I then edited /usr/share/hotkeys/vprmatrix200a5.def, based on ibook.def and inspiron8100.def, and saved it in ~/.hotplug for both steen and root. The /etc/hotplug.conf file lists the functions that hotkeys assigns to the keys -- modify this to suit your own needs.

In syslog I can now see the keycodes that have been assigned to these keys -- the ones I found in the configuration files.

None of them have any effect on the headphone, but they work on speaker volume. The vpr matrix key is not detected.

A keycode! I assigned 144 in the console and get 111 in x-windows! I try 145 and get 112. I try 155 and get nothing. A table:

So mapping it to 153 or 161 makes it the menu key in KDE -- which incidentally ought to be assigned to the real menu key, but currently is assigned to the Windows key. Clearly I could just bump into a workable solution here.

And maybe you just did: xev senses nothing for setkeycode 157, but hotkeys says it's 235! It even makes sense in terms of xev, since surrounding numbers are in the 230s. And 155 yields 236.

It looks like I may have a solution: assign the vprmatrix key to 155, and pick that up in hotkeys as 236, which is then assigned to the sus script? Test it out with a script that does something visible, such as starting Xmms. And it fscking works -- it's sad how messy this stuff is, how blindly going where no man has gone before just works.

I also put it in /etc/init.d/bootmisc.sh, which is messy but works. The real problem is that switching keyboards in x-windows overwrites the hotkeys mappings, so hotkeys has to be restarted every time.

In ~/.hotkeys/vprmatrix200a5.def, I assigned the key to the sus script, and in /etc/hotplug.conf I set this keyboard as default.

Finally, how do I make hotkeys start with x-windows? For instrucitons, see lynx /usr/share/doc/xfree86-common/examples/xsession.gz. Edit ~/.xsession and add "hotkeys &" before "startx" -- the & makes sure the program backgrounds. It works -- loads the default keyboard and shows the splash screen. (There just might be a problem with icewm hanging if you exit immediately, before hotkeys is fully started.)

Now that I have a working software suspend setup and script, I'd like to map the main script onto the vprmatrix key.

So this is handled by atkbd.c and setkeycodes can assign it some value -- but what are valid keycodes? The function of setkeycodes (according to the man page) is to "load kernel scancode-to-keycode mapping table entries". Scancodes are shown by showkey -s (use outside of x-windows) -- in the case of the vprmatrix key, it shows the same as just pressing it in a console, with no other command. More from man setkeycodes:

dumpkeys | more shows that keycodes 120 to 255 are available -- more than man setkeycodes says. You could try reassigning vprmatrix to keycode 122:

After issuing this, pressing the vprmatrix key no longer spontaneously generates the "Unknown key pressed" message. If I now use showkey -s (scan code dump mode, hex values), I get

But with showkey -k (keycode dump mode) I don't get the nice decimal keycode promised but:

Andries Brouwer points out this is what I asked for (7*16+9 = 121). So 0x79 is hexigesimal, which means you multiply 7 by 16 and add 9.

That may in fact be preferable, so I leave that setting. With showkey -k I still don't get a decimal keycode:

So obviously setkeycodes is working, and assigning a new key code of sorts -- but it doesn't show up as a decimal keycode.

I see that in fact keys above keycode 120 are taken -- for instance, pressing z produces this:

These results take you into new ranges of keycodes, and I still don't get clean decimal codes, so there's something I'm not getting.

There are lots of keymaps in /usr/share/keymaps/i386/qwerty -- they aren't from the recent kernel, but from the console-data package, version 2002.12.04dbs-49. This is what is loaded by loadkeys -d or loadkeys defkeymap:

Note that the loaded keymap is different from the kernel keymap -- at least, the format of the file produced by "loadkeys -mktable defkeymap.map > defkeymap.c" cannot in fact be loaded by loadkeys -- presumably, it's in a format that can be loaded by the kernel (?). If so, the kernel starts with one keyboard and then loads another at some point. Before even that, you already have a keyboard in lilo -- where does that come from? Or in the BIOS, before anything has been read from the OS?

So again it's not clear what's going on. It ought to be simple to reassign a single key, but apparently there's something I don't understand.

Once I've mapped the scancode to a keycode (which isn't working so far), I can use loadkeys to assign the keymapped key a function, namely to run /usr/local/bin/sus, following these instructions from man loadkeys:

Clearly, I can use this to assign a script to the key, but first I have to successfully assign the key a keycode. From

it's clear that it's possible to create a file with a few new keycodes and these will be added to the current keymap definition -- in theory.

The file /usr/src/linux/drivers/char/defkeymap.c says it was created with this command:

That works -- and the file gets created in the current directory, not in /usr/src/linux/drivers/char. You can then test if this keymap file has been modified by your setkeycodes command:

A diff shows the files are identical -- setkeycodes doesn't modify defkeymap.map, so I don't know how this all works.

Besides, there is this problem: I'm not at all sure that I'm actually using this keyboard map -- I may well have loaded another already, through some other means, already in the console. In x-windows, I've definitely loaded a new keyboard.

Now in x-windows there's the utility xmodmap that seems to do the same kind of thing, and I might have more luck with it:

This is informative -- it shows for instance that 118 to 123 is available for new keys. It looks like you can keep a list of extra keys in ~/.xmodmaprc, which would be a nice solution. But no -- the examples are all about swapping keys, not adding a key with no keycode or known name.

The simplest is obviously to use the hotkeys package, which was written to solve your problem and can handle scancodes directly. However, I need access to the source, or I need to to tell the author (Anthony Y P Wong <ypwong@ypwong.org>) my scancode. When it became clear he was no longer maintaining the package, I wrote Andries Brouwer instead.

I edited /usr/share/hotkeys/vprmatrix2005a.def but it's not clear this is the way to go. Looking at that file and the sample.xml file, I see that hotkeys is using keycodes above 127 -- in fact more or less all the codes are above that number. On the other hand, the keycodes I get from the multimedia keys are all below 127. Anyway, this indicates you can use keycodes above 127, and they're generally available. However, I haven't succeeded in assigning the vpr scancode to a keycode in a way that works yet.

In fact, the file /usr/X11R6/lib/X11/xkb/keycodes/xfree86 defines the valid range of keycodes as 8-255. However, the file doesn't use the type of scancodes that I get from showkey. Clearly x-windows loads its own keyboard(s) -- as defined in kcontrol. The bummer about hotkeys is that it runs a daemon -- that should hardly be needed?

Once it's been assigned a keycode, perhaps KDE will see it and you can assign it to a shortcut key in kmenuedit?

This works really well. I got these command strings from kcontrol's keyboard switching menu. You can see some of the syntax here:

These three parameters define the keyboard. However, I can't make any sense of how these three categories are mapped onto the contents of /usr/X11R6/lib/X11/xkb -- this directory contains the categories compat, geometry, keycodes, keymap, rules, semantics, symbols, and types. Where, for instance, is the Inspiron hardware defined?

It's in rules and symbols; who would have known. It's extremely difficult to see how one can modify the behavior of a keyboard in a predictable manner.

I wanted to map Ctrl+Alt+Down to poff, but that key is already mapped to "Previous window" -- in ~/.icewm/preferences, this is listed as

However, "Alt+Shift+F6" doesn't give you previous window, it gives you the other window in the same workspace, whether you had focus on that last or not. So the current Ctrl+Alt+Down functionality is actually extremely useful, even though it's not according to the book. I checked a few other of the shortcuts listed in preferences and they don't work as advertized. For instance,

brings up the Alt-Tab switching bar, which lists only current workspace windows;

switches between the windows in the same workspace (same behavior as "Alt+Shift+F6") -- should be doing the next window on any desktop?

So it's not clear exactly what they should be doing, but pretty clear they're not doing it. I copied in the latest preferences file from icewm-common, but when I read it into my preferences editor, the editor makes some changes to it that are likely no longer entirely correct.

These problems are not severe enough to really bother me -- in fact the "switch to previous window" feature is incredibly handy, and I've never had it before.

I don't know what the reason for the confusion is -- it could be my keyboard is incorrectly defined, but it's hard to see how keys like Esc, Shift, and Alt can be wrongly defined. Keyboards remain a bit of a mystery.

Keyboard definition: use xkeycaps !!! It looks like the IBM ThinkPad 770 and the Texas Instruments TravelMate 4000M are both close to what I have. There is also a Microsoft Natural 105 keyboard that may match my other one.

The program is designed to allow you to work with your local keyboard on a remote system. It's possible it would be useful for defining a local keyboard, but this is unclear. It's also useful for simply telling you what the keycodes are for all your keys! I think it could remap your keyboard.

You have a whole set of sound controls on the keyboard, activated by the Fn switch. These don't need x-windows to work, as I thought xkeymaps was suggesting. Numbers -- 1 (confident), 2 (likely), 3 (possibly), 4 (unlikely), 5 (impossible) -- indicate my assessment of what I think hotkeys can in principle handle (though volume controls on spello aren't in fact working).

Use xkeymaps or one of the other programs to determine the keycode to the vpr matrix key. xmodmap may be even more useful -- I've not really pursued this.

Under Linux 2.5.69, both Fn+F1 and Fn+F2 work fine (bright up and down). Since the onboard volume control is working, it out to be possible to map volume to Fn+F5 and F6 -- which could be handy.

The fact that the remaining keys don't give scancodes means either that they're working (but don't necessarily show a visible effect), or that they're not working -- this final category may include a two or three keys. The volume keys should be simple to remap, and so should vpr matrix -- you could have it start x, or suspend, as there's no suspend key, or anything you like, such as check mail or open a browser.

So I figured out the numlock -- it is indeed working, and turns a set of keys on the keypad into a number pad. So that feature works. Note that if you use Fn+ the keypad keys that are mapped onto numlock keys -- namely 7890uiopjkl;m./ -- but with numlock *off*, then these keys act as cursor keys, as they would on a turned-off number pad. So this is full number pad functionality.

That actually handles all the keys on the keyboard with the exception of the Windows key and the Menu key. I think the Menu key is in fact already working (test it more), and the Windows key can be remapped.

Hotkeys is designed to handle several of the Fn functions, such as volume up and down and mute. Can it handle bright up and down? Three keys may be more difficult -- toggle monitors (this might be handy, but is hardly a major feature, as I can just run mirror monitors, which I already know how to do -- and 96/192 (a feature missing in Linux), and then the S/PDIF, which actually probably could be mapped, as this is configurable (but I don't understand it yet). Possibly useful for high-quality sound out?

In brief, you're better off when it comes to the keyboard than you thought. Hotkeys will be useful, and could use some customizing.

It works now, and is wonderful!  Bellow is the synopsis for anyone else interested.

>> My "keymap" mod looks like:
>>
>> *VT100*translations:    #override  <Key>F13: keymap(dbx) \n\
>>         <Key>F1                   :     string("Hello You Stupid World") \n\
>>         <Key>F2                   :     string(0x1b) string("OQ") \n\
>>         <Key>F3                   :     string(0x1b) string("OR") \n\
>>         <Key>F4                   :     string(0x1b) string("OS") \n\
>>         <Key>F5                   :     string(0x1b) string("OT") \n\

>> VT100.dbxKeymap.translations: \
>>                 <Key>F14: keymap(None) \n\
>>                 <Key>F17: string("next") string(0x0d) \n\
>>                 <Key>F18: string("step") string(0x0d) \n\
>>                 <Key>F19: string("continue") string(0x0d) \n\
>>                 <Key>F20: string("print ")

>You might need a "\n" after the ("print ") -- NOT "\n\"


Yes, it look that way.

>Dumb question, but how are you getting F13 thru F20?


In my /etc/X11/xdm/Xsetup I have the following commands:

/usr/X11R6/bin/xmodmap -e "keysym KP_Divide = slash"
/usr/X11R6/bin/xmodmap -e "keysym KP_Decimal = period"
/usr/X11R6/bin/xmodmap -e "keysym KP_Add = plus"
/usr/X11R6/bin/xmodmap -e "keysym KP_Subtract = minus"
/usr/X11R6/bin/xmodmap -e "keysym KP_Multiply = asterisk"
/usr/X11R6/bin/xmodmap -e "keysym KP_Enter = Return"
/usr/X11R6/bin/xmodmap -e "keysym KP_0 = 0x30"
/usr/X11R6/bin/xmodmap -e "keysym KP_1 = 1 F13"
/usr/X11R6/bin/xmodmap -e "keysym KP_2 = 2 F14"
/usr/X11R6/bin/xmodmap -e "keysym KP_3 = 3 F15"
/usr/X11R6/bin/xmodmap -e "keysym KP_4 = 4 F16"
/usr/X11R6/bin/xmodmap -e "keysym KP_5 = 5 F17"
/usr/X11R6/bin/xmodmap -e "keysym KP_6 = 6 F18"
/usr/X11R6/bin/xmodmap -e "keysym KP_7 = 7 F19"
/usr/X11R6/bin/xmodmap -e "keysym KP_8 = 8 F20"
/usr/X11R6/bin/xmodmap -e "keysym KP_9 = 9 F21"

Which both puts my keypad in permament Num_Lock mode, and maps Shift KP_1 - KP_9 to F13 through F21.  Very clever on my part.

>Here's part of my XTerm file:
>!------------------------------------------------
>*VT100.dbxKeymap.translations: \
>     <Key>F9: keymap(None) \n\
>     <Key>F8: string("ls") string(0x0d) \n\
>     <Key>F7: string("KKKKKKKKKK") \n\
>     <Key>F6: string("tttttttttt") \n\
>     <Key>F2: string("Kkljztqj") \n\
>     <Key>F1: string("y\n") \n
>XTerm.vt100.translations: #override\n\
> <Key>F10: keymap(dbx)\n
>!------------------------------------------------
>F10 activates my keys, F9 turns them off.


I've put the following lines in /usr/lib/X11/app-defaults/XTerm:

XTerm.vt100.translations:       #override \n\
        Ctrl<Key>Home             :     string(0x1b) string("Os") \n\
        Ctrl<Key>End              :     string(0x1d) \n\
        Ctrl<Key>Prior            :     string(0x1b) string("Oq") \n\
        Ctrl<Key>Next             :     string(0x1b) string("Or") \n\
        Ctrl<Key>BackSpace        :     string(0x1b) string("On") \n\
        Ctrl<Key>F1               :     string(0x1b) string("OP") \n\
        Ctrl<Key>F2               :     string(0x1b) string("OQ") \n\
  . . .
        Shift<Key>F5              :     keymap(user1) \n\    <<<<<
        Shift<Key>F6              :     keymap(user2) \n\    <<<<< Added
        Shift<Key>F7              :     keymap(user3) \n\    <<<<<  these
        Shift<Key>F8              :     keymap(user4) \n\    <<<<<    lines
  . . .
        ! @Num_Lock Ctrl        <Btn5Down>:     scroll-forw(1,halfpage) \n\
                                <Btn5Down>:     scroll-forw(5,line)

<<<<<<End of usr/lib/X11/app-defaults/XTerm>

And by putting the following in my ~/.Xdefaults file I have four selectable private key maps (with a total of 48 keys):

*VT100.user1Keymap.translations: \
	Shift<Key>F5:	keymap(None) \n\
	Meta<Key>F1:	string("Hot Key f1-1") \n\
        Meta<Key>F2:	string("Hot Key f2-1") \n\
        Meta<Key>F3:	string("Hot Key f3-1") \n\
        Meta<Key>F4:	string("Hot Key f4-1") \n\
        Meta<Key>F5:	string("Hot Key f5-1") \n\
        Meta<Key>F6:	string("Hot Key f6-1") \n\
        Meta<Key>F7:	string("Hot Key f7-1") \n\
        Meta<Key>F8:	string("Hot Key f8-1") \n\
        Meta<Key>F9:	string("Hot Key f9-1") \n\
        Meta<Key>F10:	string("Hot Key f10-1") \n\
        Meta<Key>F11:	string("Hot Key f11-1") \n\
        Meta<Key>F12:	string("Hot Key f12-1") \n

*VT100.user2Keymap.translations: \
        Shift<Key>F6:   keymap(None) \n\
        Meta<Key>F1:    string("Hot Key f1-2") \n\
        Meta<Key>F2:    string("Hot Key f2-2") \n\
        Meta<Key>F3:    string("Hot Key f3-2") \n\
        Meta<Key>F4:    string("Hot Key f4-2") \n\
        Meta<Key>F5:    string("Hot Key f5-2") \n\
        Meta<Key>F6:    string("Hot Key f6-2") \n\
        Meta<Key>F7:    string("Hot Key f7-2") \n\
        Meta<Key>F8:    string("Hot Key f8-2") \n\
        Meta<Key>F9:    string("Hot Key f9-2") \n\
        Meta<Key>F10:   string("Hot Key f10-2") \n\
        Meta<Key>F11:   string("Hot Key f11-2") \n\
        Meta<Key>F12:   string("Hot Key f12-2") \n

*VT100.user3Keymap.translations: \
        Shift<Key>F7:   keymap(None) \n\
        Meta<Key>F1:    string("Hot Key f1-3") \n\
        Meta<Key>F2:    string("Hot Key f2-3") \n\
        Meta<Key>F3:    string("Hot Key f3-3") \n\
        Meta<Key>F4:    string("Hot Key f4-3") \n\
        Meta<Key>F5:    string("Hot Key f5-3") \n\
        Meta<Key>F6:    string("Hot Key f6-3") \n\
        Meta<Key>F7:    string("Hot Key f7-3") \n\
        Meta<Key>F8:    string("Hot Key f8-3") \n\
        Meta<Key>F9:    string("Hot Key f9-3") \n\
        Meta<Key>F10:   string("Hot Key f10-3") \n\
        Meta<Key>F11:   string("Hot Key f11-3") \n\
        Meta<Key>F12:   string("Hot Key f12-3") \n

*VT100.user4Keymap.translations: \
        Shift<Key>F8:   keymap(None) \n\
        Meta<Key>F1:    string("Hot Key f1-4") \n\
        Meta<Key>F2:    string("Hot Key f2-4") \n\
        Meta<Key>F3:    string("Hot Key f3-4") \n\
        Meta<Key>F4:    string("Hot Key f4-4") \n\
        Meta<Key>F5:    string("Hot Key f5-4") \n\
        Meta<Key>F6:    string("Hot Key f6-4") \n\
        Meta<Key>F7:    string("Hot Key f7-4") \n\
        Meta<Key>F8:    string("Hot Key f8-4") \n\
        Meta<Key>F9:    string("Hot Key f9-4") \n\
        Meta<Key>F10:   string("Hot Key f10-4") \n\
        Meta<Key>F11:   string("Hot Key f11-4") \n\
        Meta<Key>F12:   string("Hot Key f12-4") \n

Which are turned on with Shift F5 thorugh Shift F8 or completely toggled off by pressing the same key again, or switched to another map.

Now all I have to do it whip up a Tcl/TK script so my users can easy enter in what they want in their private keys maps.