Date:	Tue, 09 Oct 2007 17:36:09 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
CC:	"Antonino A. Daplas" <adaplas@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Verych <olecom@...wer.upol.cz>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 1/2] Colored kernel output (run3)

I tried something useful with this, see below.

Jan Engelhardt wrote:
> 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. ;)

It probably means that the very clear explanations you shortened above 
should go it a file in Documentation. Particularly with the feature to 
have different levels of message different colors this allows monitoring 
of machines even when you can't read the message from a distance. When 
you see the magic color you can go look closer.
> 
>> 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.

I tried something here, I have a monitor page on my window manager with 
lots of xterms opened to machines like DNS, HTTP, mail and NNTP servers. 
I use 100x25 xterms, with font size default. So just for fun I put a one 
line message on one in green on black (instead of black on white) and 
sized them all down to "unreadable" (cntl-right click menu) and I could 
clearly tell which one had the message even on the postage stamps.

Then I tried white on red, white on blue, and white on green. Those 
messages made the tiny xterm stand out as well. So I think it's a true 
statement that using colors to make important stuff stand out is 
something which in practice would be useful. Obviously if you use the 
"unreadable" font you can't read it, but that one xterm can be resized 
to a sane font to actually use it.

This isn't any dumber that Fedora printing the boot status of anything 
which fails in red, that may be "damned by faint praise" of course.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists