[PATCH] console ASCII glyph 1:1 mapping

[PATCH] console ASCII glyph 1:1 mapping

[Ingo Brueckl]

For the console, there is a 1:1 mapping of glyphs which cannot be found in the current font. This seems to be meant as a kind of 'emergency fallback' for fonts without unicode mapping which otherwise would display nothing readable on the screen.

At the moment it affects all chars for which no substitution character is defined. In particular this means that for all chars (>= 128) where there is no iso88591-1/unicode character (e.g. control character area) you'll get the very strange 1:1 mapping of the (cp437) graphics card glyphs.

I'm pretty sure that the 1:1 mapping should only affect strict ASCII code characters, i.e. chars < 128.

The patch limits the mapping as it probably was meant anyway.

Signed-off-by: Ingo Brueckl <ib@wupperonline.de>

--- linux-2.6.27.8.orig/drivers/char/vt.c	2008-12-05 21:03:02.000000000 +0100
+++ linux-2.6.27.8/drivers/char/vt.c	2008-12-10 20:51:30.000000000 +0100
@@ -2287,7 +2287,7 @@ rescan_last_byte:
 				    continue; /* nothing to display */
 				}
 				/* Glyph not found */
-				if ((!(vc->vc_utf && !vc->vc_disp_ctrl) || c < 128) && !(c & ~charmask)) {
+				if ((!(vc->vc_utf && !vc->vc_disp_ctrl) && c < 128) && !(c & ~charmask)) {
 				    /* 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

Re: [PATCH] console ASCII glyph 1:1 mapping

[Linus Torvalds]

Hmm. I bounced both your patches to Peter, since they look valid but I 
want somebody who knows this code better to ack them. 

Peter - is there somebody else who should double-check these things, or 
can you ack them?

		Linus

On Wed, 10 Dec 2008, Ingo Brueckl wrote:
>
> For the console, there is a 1:1 mapping of glyphs which cannot be found 
> in the current font. This seems to be meant as a kind of 'emergency 
> fallback' for fonts without unicode mapping which otherwise would 
> display nothing readable on the screen.
> 
> At the moment it affects all chars for which no substitution character 
> is defined. In particular this means that for all chars (>= 128) where 
> there is no iso88591-1/unicode character (e.g. control character area) 
> you'll get the very strange 1:1 mapping of the (cp437) graphics card 
> glyphs.
> 
> I'm pretty sure that the 1:1 mapping should only affect strict ASCII 
> code characters, i.e. chars < 128.
> 
> The patch limits the mapping as it probably was meant anyway.
> 
> Signed-off-by: Ingo Brueckl <ib@wupperonline.de>
> 
> --- linux-2.6.27.8.orig/drivers/char/vt.c	2008-12-05 21:03:02.000000000 +0100
> +++ linux-2.6.27.8/drivers/char/vt.c	2008-12-10 20:51:30.000000000 +0100
> @@ -2287,7 +2287,7 @@ rescan_last_byte:
>  				    continue; /* nothing to display */
>  				}
>  				/* Glyph not found */
> -				if ((!(vc->vc_utf && !vc->vc_disp_ctrl) || c < 128) && !(c & ~charmask)) {
> +				if ((!(vc->vc_utf && !vc->vc_disp_ctrl) && c < 128) && !(c & ~charmask)) {
>  				    /* 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
> 

Re: [PATCH] console ASCII glyph 1:1 mapping

[H. Peter Anvin]

Linus Torvalds wrote:
> Hmm. I bounced both your patches to Peter, since they look valid but I 
> want somebody who knows this code better to ack them. 
> 
> Peter - is there somebody else who should double-check these things, or 
> can you ack them?

I should be able to.

For both patches:

Acked-by: H. Peter Anvin <hpa@zytor.com>

[Let me know if you prefer me setting up a git tree to pull from.]

This was introduced by commit
1ed8a2b3c501bedd4b35130c8a52662ccf78abad, which among other things have
this:

--------
As Behdad pointed out, some fonts (e.g. sun12x22 from the kbd package)
lack Unicode mapping information, hence all you get is lots of question
marks. Though theoretically it's actually a user-space bug (the font
should be fixed), Behdad and I both believe that it'd be good to work
around in the kernel by re-introducing the fallback solution for ASCII
characters only. This sounds a quite reasonable decision, since all
fonts ship the ASCII characters in the first 128 positions. This way
users won't be surprised by lots of question marks just because s/he
issued a not-so-perfectly parameterized setfont command. As this
fallback is only re-introduced for code points below 128, you still
won't see an accented letter replaced by another, but at least you'll
always get the English letters right.
--------

The implementation was obviously buggy, however.

The statement above is also just plain wrong, since installing a font
with no Unicode table causes a direct-to-font Unicode table to be set up
(0xF0xx for all positions) unless explicitly overridden.

Anyway, I was rather against adding this fallback, because I felt it was
needless complexity to deal with a very explicit user error.
Fortunately, the bug didn't affect any legitimate users.

	-hpa