Re: [PATCH 1/2] Colored kernel output (run3)

[Jan Engelhardt <jengelh@computergmbh.de>]

On Oct 9 2007 07:12, Antonino A. Daplas wrote:
>> 
>> References: http://lkml.org/lkml/2007/4/1/162
>> 	http://lkml.org/lkml/2007/10/5/199
>
>This is quite a long thread :-)

It was a patch series after all. But as Greg puts it, be persistent.

>> +config VT_PRINTK_COLOR
>> +	hex "Colored kernel message output"
>> +	range 0x00 0xFF
>> +	depends on VT_CKO
>> +	default 0x07
>> +	---help---
>> +	This option defines with which color kernel messages will be
>> +	printed to the console.
>> +
>> +	The value you need to enter here is the value is composed
>
>The more correct term for "The value" is probably "The attribute".

"The value for this kconfig entry" it should read in the minds.

>> +	(Foreground colors 0x08 to 0x0F do not work when a VGA
>> +	console font with 512 glyphs is used.)
>
>You might have to include a warning that those values or attributes are 
>interpreted differently depending on the driver used, and the above is
>mostly true for 16-color console drivers only.

Are there any other drivers besides vgacon and fbcon that use vt.c?

>For 2-colors [...] With a 4-color fb console (4-level grayscale) [...]
>With an 8-color console, only the first 8 values are considered.
>With a 16-color console, that is also not consistent:[...]

I see. That probably means the explanation of values moves from Kconfig 
to Documentation/. Somehow I think we could do without doc and let 
interested starts find out for themselves and learn a little about 
vgacon/fbcon. ;)

>With vgacon, it supports 16-color foreground (fg), 8-color
>background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
>
>With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
>512 chars.

And then there is fbiterm, which supports at least 16 fg/16 bg with ... 
the whole Unicode set of chars. :)

>And for drivers that have their own con_build_attr() hook, they will be
>interpreted differently again.

>> +	Background:
>> +	0x00 = black,   0x40 = blue,
>> +	0x10 = red,     0x50 = magenta,
>> +	0x20 = green,   0x60 = cyan,
>> +	0x30 = brown,   0x70 = gray,
>> +
>> +	For example, 0x1F would yield white on red.
>
>You may need to specify that the values here are the console default,
>ie, the default_blue|grn|red boot options are not filled up.

>> +static inline void vc_set_color(struct vc_data *vc, unsigned char color)
>> +{
>> +	vc->vc_color = color_table[color & 0xF] |
>> +	               (color_table[(color >> 4) & 0x7] << 4) |
>> +	               (color & 0x80);
>
>You may want to leave out the blink attribute (0x80) from this part.
>Otherwise setterm -blink on|off will produce the opposite effect. 

But 0x80 might be interpreted in a different fashion for some othercon, 
yielding for example superbold rather than blinking.
I'll have to try this, because usually, setterm operates on TTYs
rather than VCs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/