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 <[email protected]>
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
