[Pkg-kbd-devel] Bug#528357: /usr/bin/showconsolefont: produces garbage

[Norm Pierce]

As already noted by others, this problem is a result of a change in the
kernel.  That change was reversed in the 2.6.30 kernel.  No change should
be needed to showconsolefont when running with the corrected kernel.
(However, I am not currently a Debian user, so have not tested this.  This
theory still needs to be tested.)

Here is what was going on:

showconsolefont uses a somewhat imaginative method to allow it to work
whether or not the console is in UTF-8 mode.  It creates its own unimap.
Actually, it creates a series of 64-character unimaps as it works (four
for 256-character fonts and eight for 512-character fonts).  Each of these
unimaps uses codes 0x21 through 0x60.  (By recycling this same set of
codes, it avoids using codes greater than 0x7f and so doesn't need to
translate any codes to UTF-8.)  It will first map these codes to one set
of glyphs, then send the codes 0x21 through 0x60 to the console.  Then it
remaps those codes to another set of glyphs, and sends them out again.  It
continues doing this until all glyphs have been displayed.

Notice that 0x20 (an ASCII space) is never among the codes mapped.

With a good kernel, if if no entry is found in the unimap for a non-ASCII
character, the console displays the Unicode replacement character, U+FFFD,
and if no entry for that is found either, the console displays a question
mark in reverse video.  However, if a font doesn't have a unimap, it makes
little sense to display all ASCII characters as question marks, so ASCII
characters with no entry in the map are passed straight through.  So, for
instance, character code 0x20 (if not mapped) will display glyph 0x20.

Or, in words from the source:

/* In legacy mode use the glyph we get by a 1:1 mapping.
   This would make absolutely no sense with Unicode in mind,
   but do this for ASCII characters since a font may lack
   Unicode mapping info and we don't want to end up with
   having question marks only. */

So, with a good kernel, when showconsolefont sends spaces to separate the
columns, all is well: character code 0x20 displays glyph 0x20.

However, the change in the kernel (drivers/char/vt.c) mistakenly
eliminated this direct mapping.  So, the console displays a replacement
character.  Since the Unicode replacement character, U+FFFD, is not
mapped, it falls back on the question mark.

What?  You see garbage, not question marks?  Yes.  Each of the unimaps
created by showconsolefont maps 0x3f (the ASCII question mark) to a
different glyph, none of which happen to be a question mark.

Michael, you wondered which kernel introduced this behavior.  This problem
first appeared with kernel 2.6.28-rc9, 2008-Dec-19 and was released in
kernel 2.6.28, 2008-Dec-24.  The correction first appeared in kernel
2.6.30-rc3, 2009-Apr-22 and was released in kernel 2.6.30, 2009-Jun-10.

Here are the related commits:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commit;h=1c55f18717304100a5f624c923f7cb6511b4116d

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commit;h=c0b7988200a82290287c6f4cd49585007f73175a

Norm Pierce