Keymap Blues in Ubuntu's Text Console

By Anonymous

Today's news is that, after years of cosying up to SUSE/openSUSE, I have decided to move unambiguously to Ubuntu. KDE did it to me. KDE on plasmoids gives me the jinx, and GNOME on openSUSE is an innocent abroad. On to Ubuntu 8.10.

Moving to Ubuntu is work - at least if you like the text console and spend time in it. You have to install lots of packages before Ubuntu's text-mode environment becomes kind of comfortable for administrative tasks and leisure programming. The 8.10 repositories don't even offer Midnight Commander, right now. Also, when you think you are done, there are still surprises waiting around the corner. Take, for instance, the keymap. (Warning: We are talking about the text-mode keymap, no X11 involved. I do not intend to repeat this every second sentence.)

1. Where are the keymaps?

Where are Ubuntu's text-mode keymaps for languages and special keyboard layouts like Dvorak? Out there in the wilderness of distros, you will find a collection of keymaps below /usr/share/keymaps/ or /usr/share/kbd/. A past version of Fedora I was playing with, two years ago, had them in /etc/keymaps. Where are they in Ubuntu?

Good question. Go ahead and look for them. Poor reader, I see you coming back with tail nicely folded between hind legs. How come? They are not there! They are nowhere! They are behind Locked Door Number X!

A few reminiscences. In the late 90s, the maintainer of the kbd package, which was the basis for keymaps and keymap handling in symbiosis with the Linux kernel, appeared to be feebly motivated. A competing project, called console-tools, sprang up and was promptly embraced by Debian, while Red Hat and SUSE stuck to kbd. However, kbd gathered momentum and released several new versions in the early 2000s, while console-tools stagnated and became moribund. It is fair to say that the project is abandoned, while kbd has just been blessed with the energy of a new maintainer. Debian and Ubuntu are now moving back to kbd, and facing annoyances galore with compatibility issues.

For Ubuntu, the approach is simple: they do not care about the text console, so they ignore, as far as possible, the trouble surrounding keymaps. There is one and only one keymap in Ubuntu 8.10: it is called boottime.kmap.gz, and is found in /etc/console-setup.

Needless to say, those keymaps must exist, since they are console configuration options -- but they are in the archives in binary form, not accessible for tinkering and individual customisation. Not accessible for fun.

2. Why would you want to change the keymap?

Surely: Because you are entitled to your idiosyncrasies (I mean preferences), and that's a strong enough reason. But there are also a couple of things that, soberly considered, call for intervention.

2.1 Some definitions

Sorry, terminology pain ahead: 'Keymap' normally indicates a file where the key assignments get defined. The assignments can refer to plain keys, but can also refer to modified keys, e.g., <ctrl> or <left>. In the keymap file, a set of assignments for given modifiers is also called a keymap, so we get a keymap for <ctrl>, a keymap for <alt> and so on. Now, hold yourself tight - because Ubuntu defines 64 keymaps. All possible modifier combinations are there. Do not ask me why odd combinations with 3 or 4 or 5 modifiers are there, since they cannot possibly be typed as long as humans have only two hands. But they are there, and that's the end of it. Compare with openSUSE or Fedora, where you will find only single and double modifiers from the <shift>-<ctrl>-<alt>-<altgr> set - and not even all of them. That makes sense.

Perhaps this is a marginal issue, but let me point out that Ubuntu's keymap is 20 times larger than openSUSE's and Fedora's, and therefore must have some impact in memory. I never noticed any difference while using openSUSE and Ubuntu, but the effect must be there.

2.2 Read this thread...

https://bugs.launchpad.net/Ubuntu/+source/console-data/+bug/279973

...and you will realize that pressing <printscreen> in the Ubuntu console produces a Control_backslash, AKA char 28. The bug report above refers to 8.04, but the "feature" is still there in 8.10: character 28 has vandalizing tendencies in some applications, and so work may be lost -- and it was, indeed, as the thread points out. Control_backslash can still be produced with <ctrl><printscreen>, no objection to that, since it would be intentional. But pressing just plain <printscreen> inadvertently is just too likely to happen.

2.3 The US default keymap and the default keymap for a couple of languages I have checked (German, French, Spanish, Italian, Russian) define strings for variables F1 - F20. They also have variables past F20 (F21 and up), but without any strings defined for them. This last oddity is a problem everywhere, but here we are concerned with differences between Ubuntu and mainstream, i.e., between the legacy approach of console-tools versus kbd. Distros based on kbd are the overwhelming majority. Contrast them with Ubuntu, with regard to definitions for <shift><f1> and up:

                    kbd             console-tools
                    (openSUSE)      (Ubuntu)

    <shift><f1>     F13             F11
    <shift><f2>     F14             F12
    <shift><f3>     F15             F13
    <shift><f4>     F16             F14
    <shift><f5>     F17             F15
    <shift><f6>     F18             F16
    <shift><f7>     F19             F17
    <shift><f8>     F20             F18
    <shift><f9>     F21 (void)      F19
    <shift><f10>    F22 (void)      F20
    <shift><f11>    F23 (void)      F21 (void)
    <shift><f12>    F24 (void)      F22 (void)

My first remark, here, would be that the shifted <f9>, <f10>, <f11>, <f12> are not usable in openSUSE and others, because F21 and up is not defined; it is just the empty string to which no application can associate a function. For the same reason, shifted <f11> and <f12> are not available in Ubuntu.

However, owing to that fatal Debian decision to switch to console-tools ten years ago, what we have now is evil: a text-mode application that binds a function to, say, <shift><f4> will have the function executed either under openSUSE, Fedora and co., or under Debian and Ubuntu. It is not possible to have both.

Therefore, here is a gentle request to Ubuntu, Canonical, and Mark Shuttleworth: it is time to correct those assignments, and accept the kbd package's defaults for the modified function keys.

On top of that, please give yourself a push and introduce strings for F21, F22 and up. What's the point of assigning these variables to modified function keys, if the variables deliver only the empty string?

With these two mildly reformist measures, 2-3 dozen modified function keys would instantly become available to text-mode applications. As an example, Ubuntu installs the "nano" editor by default. Why is it that "nano" uses only the plain function keys, and resorts to abstruse measures like using <alt><underscore> to extend the set of keybindings? It is because the modified function keys are not coherently defined across distros. It's long past time to overcome that, all the more so since the modified function keys would be international by nature. Just look for <alt><underscore> on non-US keyboards.

2.4. The Tao of SAK

The Secure Attention Key (SAK) is not a physical key; it is a feature that may or may not have an assignment compiled into the kernel. If it is compiled into the kernel, it is triggered by <alt><printscreen><k>. However, whatever the kernel compile options, SAK can also be assigned to any other key of your choice. It kills all processes in the current console, and logs you out. That's practical when you are playing around with some application and manage to get a totally unresponsive keyboard: as long as the kernel is alive, SAK will always respond.

The 8.10 kernel has built-in SAK -- but a buggy SAK:

https://ubuntuforums.org/showthread.php?p=6169912

Pressing SAK gives you a kernel panic, and only switching the power off will help. Kind of odd, isn't it? The built-in SAK cannot be disabled, and so users can just crash the system to their heart's content. Didn't Ubuntu specialize in security?

The remedy here is not editing the keymap; it is leaving out the compile option for SAK (SysReq). Users will still be able to set up SAK in the keymap, if they so wish - of course, after the SAK bug has been squashed.

(The SAK bug, by the way, has been proven to be hardware-specific, see https://article.gmane.org/gmane.linux.ubuntu.user/165993/match=sak+producing+kernel+panic.)

3. How do you modify the Ubuntu's keymap?

First, prepare a text file with the keymap of your liking; you could do that by extracting boottime.kmap from boottime.kmap.gz and modifying it at your leisure. However, if your editing includes reducing those 64 keymaps to sensible size (say, 10), you will be busy for one full hour, at least. It is easier to copy and edit the keymap from any Fedora, openSUSE, or Mandriva to which you have access. Avoid typos; any little error will cause the keymap to be refused. (A CRLF end-of-line is an error; only LF is accepted.) Not required but useful would be a distinctive name, e.g., myown.kmap.

When you are through:

    loadkeys -s myown.kmap

The catch is that you would need to issue this command every time you boot. To have that done automatically, you compress myown.kmap and move it as boottime.kmap.gz to /etc/console-setup. Surprise, it does not work; Ubuntu wants a MD5 hash for the file, and it wants it precisely in /etc/default/console-setup. So, you think you are clever, run md5sum on the new boottime.kmap.gz, and insert the hash as appropriate. Surprise - it still does not work. With or without the correct MD5 hash at the correct place, Ubuntu is determined to not let you muck around with the boot-time keymap.

At that moment, it's like a late Western, post-modern: You do not confront your enemy face-to-face so that the quicker and better and nobler of the two wins. No, you shoot your enemy from behind. Safe and effective.

Among Ubuntu's (run-level independent) boot-time scripts, the last one in execution order is called /etc/init.d/console-screen.kbd.sh. Here, you replace the very first lines of code:

if type setupcon >/dev/null 2>&1; then
    exit 0
fi

with

if type setupcon >/dev/null 2>&1; then
    loadkeys -s /etc/console-setup/myown.kmap
    exit 0
fi

...after placing myown.kmap at the indicated location. It works like a charm. Ubuntu even obliges with a message that it is loading that keymap of yours.

4. Where do we go from here?

Who knows? However, surely the legacy of console-tools has to be overcome, and more consistency has to be achieved for text-mode keymaps across distros.

Technically, the issue is trivial: assign strings to the keys with a functional slant. These are keys that normally do not insert anything; usually, they trigger functions. We are talking about <f1> to <f12>, <insert> to <pagedown>, the arrow keys, <printscreen>, <scrolllock>, <break>. They - plain or in combination with modifiers - don't have to be different across distros or across languages. However, to make them consistent, you need consensus.

And that seems to be a problem.

Talkback: Discuss this article with The Answer Gang

---

A. N. Onymous has been writing for LG since the early days - generally by sneaking in at night and leaving a variety of articles on the Editor's desk. A man (woman?) of mystery, claiming no credit and hiding in darkness... probably something to do with large amounts of treasure in an ancient Mayan temple and a beautiful dark-eyed woman with a snake tattoo winding down from her left hip. Or maybe he just treasures his privacy. In any case, we're grateful for his contributions.
-- Editor, Linux Gazette