Colored kernel message output (1/2)
This patch makes it possible to give kernel messages a selectable
color. It can be chosen at compile time, overridden at boot time,
and changed at run time.
References: http://lkml.org/lkml/2007/4/1/162
http://lkml.org/lkml/2007/10/5/199
Signed-off-by: Jan Engelhardt <[email protected]>
---
drivers/char/Kconfig | 42 ++++++++++++++++++++++++++++++++++++++++++
drivers/char/vt.c | 23 +++++++++++++++++++++++
2 files changed, 65 insertions(+)
Index: linux-2.6.23/drivers/char/Kconfig
===================================================================
--- linux-2.6.23.orig/drivers/char/Kconfig
+++ linux-2.6.23/drivers/char/Kconfig
@@ -58,6 +58,48 @@ config VT_CONSOLE
If unsure, say Y.
+config VT_CKO
+ bool "Colored kernel message output"
+ depends on VT_CONSOLE
+ ---help---
+ This option enables kernel messages to be emitted in
+ colors other than the default.
+
+ If unsure, say N.
+
+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
+ (OR-ed) of a foreground and a background color.
+
+ Foreground:
+ 0x00 = black, 0x08 = dark gray,
+ 0x01 = red, 0x09 = light red,
+ 0x02 = green, 0x0A = light green,
+ 0x03 = brown, 0x0B = yellow,
+ 0x04 = blue, 0x0C = light blue,
+ 0x05 = magenta, 0x0D = light magenta,
+ 0x06 = cyan, 0x0E = light cyan,
+ 0x07 = gray, 0x0F = white,
+
+ (Foreground colors 0x08 to 0x0F do not work when a VGA
+ console font with 512 glyphs is used.)
+
+ 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.
+
config HW_CONSOLE
bool
depends on VT && !S390 && !UML
Index: linux-2.6.23/drivers/char/vt.c
===================================================================
--- linux-2.6.23.orig/drivers/char/vt.c
+++ linux-2.6.23/drivers/char/vt.c
@@ -73,6 +73,7 @@
*/
#include <linux/module.h>
+#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/sched.h>
#include <linux/tty.h>
@@ -2344,6 +2345,23 @@ struct tty_driver *console_driver;
#ifdef CONFIG_VT_CONSOLE
+static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
+#ifdef CONFIG_VT_CKO
+module_param(printk_color, uint, S_IRUGO | S_IWUSR);
+
+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);
+ update_attr(vc);
+}
+#else
+static inline void vc_set_color(const struct vc_data *vc, unsigned char c)
+{
+}
+#endif
+
/*
* Console on virtual terminal
*
@@ -2384,12 +2402,14 @@ static void vt_console_print(struct cons
hide_cursor(vc);
start = (ushort *)vc->vc_pos;
+ vc_set_color(vc, printk_color);
/* Contrived structure to try to emulate original need_wrap behaviour
* Problems caused when we have need_wrap set on '\n' character */
while (count--) {
c = *b++;
if (c == 10 || c == 13 || c == 8 || vc->vc_need_wrap) {
+ vc_set_color(vc, vc->vc_def_color);
if (cnt > 0) {
if (CON_IS_VISIBLE(vc))
vc->vc_sw->con_putcs(vc, start, cnt, vc->vc_y, vc->vc_x);
@@ -2402,6 +2422,7 @@ static void vt_console_print(struct cons
bs(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, printk_color);
continue;
}
if (c != 13)
@@ -2409,6 +2430,7 @@ static void vt_console_print(struct cons
cr(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, printk_color);
if (c == 10 || c == 13)
continue;
}
@@ -2430,6 +2452,7 @@ static void vt_console_print(struct cons
vc->vc_need_wrap = 1;
}
}
+ vc_set_color(vc, vc->vc_def_color);
set_cursor(vc);
quit:
On Sat, 6 Oct 2007 22:09:52 +0200 (CEST)
Jan Engelhardt <[email protected]> wrote:
>
> Colored kernel message output (1/2)
>
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time,
> and changed at run time.
As the nearest thing to a tty maintainer I'd like to NAK this as "Silly"
* Jan Engelhardt <[email protected]> wrote:
> Colored kernel message output (1/2)
>
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time, and
> changed at run time.
minor fix: i had to use the slightly modified patch below instead of the
one you posted, so that the second patch applies fine. Color output is
just fine with this plus your #2 one applied. Adding
vt.printk_color=0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 to the boot line
worked as expected.
Ingo
--------------->
Colored kernel message output (1/2)
This patch makes it possible to give kernel messages a selectable
color. It can be chosen at compile time, overridden at boot time,
and changed at run time.
References: http://lkml.org/lkml/2007/4/1/162
http://lkml.org/lkml/2007/10/5/199
Signed-off-by: Jan Engelhardt <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/char/Kconfig | 42 ++++++++++++++++++++++++++++++++++++++++++
drivers/char/vt.c | 24 ++++++++++++++++++++++++
2 files changed, 66 insertions(+)
Index: linux/drivers/char/Kconfig
===================================================================
--- linux.orig/drivers/char/Kconfig
+++ linux/drivers/char/Kconfig
@@ -58,6 +58,48 @@ config VT_CONSOLE
If unsure, say Y.
+config VT_CKO
+ bool "Colored kernel message output"
+ depends on VT_CONSOLE
+ ---help---
+ This option enables kernel messages to be emitted in
+ colors other than the default.
+
+ If unsure, say N.
+
+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
+ (OR-ed) of a foreground and a background color.
+
+ Foreground:
+ 0x00 = black, 0x08 = dark gray,
+ 0x01 = red, 0x09 = light red,
+ 0x02 = green, 0x0A = light green,
+ 0x03 = brown, 0x0B = yellow,
+ 0x04 = blue, 0x0C = light blue,
+ 0x05 = magenta, 0x0D = light magenta,
+ 0x06 = cyan, 0x0E = light cyan,
+ 0x07 = gray, 0x0F = white,
+
+ (Foreground colors 0x08 to 0x0F do not work when a VGA
+ console font with 512 glyphs is used.)
+
+ 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.
+
config HW_CONSOLE
bool
depends on VT && !S390 && !UML
Index: linux/drivers/char/vt.c
===================================================================
--- linux.orig/drivers/char/vt.c
+++ linux/drivers/char/vt.c
@@ -73,6 +73,7 @@
*/
#include <linux/module.h>
+#include <linux/moduleparam.h>
#include <linux/types.h>
#include <linux/sched.h>
#include <linux/tty.h>
@@ -2344,6 +2345,24 @@ struct tty_driver *console_driver;
#ifdef CONFIG_VT_CONSOLE
+#ifdef CONFIG_VT_CKO
+static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
+module_param(printk_color, uint, S_IRUGO | S_IWUSR);
+
+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);
+ update_attr(vc);
+}
+#else
+static unsigned int printk_color;
+static inline void vc_set_color(const struct vc_data *vc, unsigned char c)
+{
+}
+#endif
+
/*
* Console on virtual terminal
*
@@ -2384,12 +2403,14 @@ static void vt_console_print(struct cons
hide_cursor(vc);
start = (ushort *)vc->vc_pos;
+ vc_set_color(vc, printk_color);
/* Contrived structure to try to emulate original need_wrap behaviour
* Problems caused when we have need_wrap set on '\n' character */
while (count--) {
c = *b++;
if (c == 10 || c == 13 || c == 8 || vc->vc_need_wrap) {
+ vc_set_color(vc, vc->vc_def_color);
if (cnt > 0) {
if (CON_IS_VISIBLE(vc))
vc->vc_sw->con_putcs(vc, start, cnt, vc->vc_y, vc->vc_x);
@@ -2402,6 +2423,7 @@ static void vt_console_print(struct cons
bs(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, printk_color);
continue;
}
if (c != 13)
@@ -2409,6 +2431,7 @@ static void vt_console_print(struct cons
cr(vc);
start = (ushort *)vc->vc_pos;
myx = vc->vc_x;
+ vc_set_color(vc, printk_color);
if (c == 10 || c == 13)
continue;
}
@@ -2430,6 +2453,7 @@ static void vt_console_print(struct cons
vc->vc_need_wrap = 1;
}
}
+ vc_set_color(vc, vc->vc_def_color);
set_cursor(vc);
quit:
On Oct 7 2007 18:38, Ingo Molnar wrote:
>
>minor fix: i had to use the slightly modified patch below instead of the
>one you posted, so that the second patch applies fine.
What is it that you changed? The printk patches are right at the front,
so there should not be any fuzz or offsets (might vary when
not at Linus's git top).
18:42 ichi:/ws/linux/linux-2.6.23 > head -n6 patches/series
checkpatch1.diff
checkpatch2.diff
checkfiles.diff
xt_TCPOPTSTRIP.diff
vt-printk-color.diff
vt-printk-color-per-loglevel.diff
>Color output is
>just fine with this plus your #2 one applied. Adding
>vt.printk_color=0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 to the boot line
>worked as expected.
Use decimal if feasible. (vt.printk_color=1,2,3,4,5,6,7,8)
The maximum command line still seems to be 255 on i386,
as I noticed while trying to replace the VGA color table :-(
Jan,
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time, and
> changed at run time.
here's some (good) text footprint data:
with the feature disabled (which is the default), the text size
difference with patch #1:
vmlinux:
text data bss dec hex filename
7732358 1157269 401408 9291035 8dc51b vmlinux.before
7732358 1157269 401408 9291035 8dc51b vmlinux.after
i.e. no overhead. Text size difference with patch #2:
vmlinux:
text data bss dec hex filename
7732358 1157269 401408 9291035 8dc51b vmlinux.before
7732374 1157269 401408 9291051 8dc52b vmlinux.after
16 bytes, or 0.0002% of the total text size. So there's in essence no
text overhead to talk about. So the text overhead argument is a red
herring.
Ingo
On Oct 7 2007 18:44, Ingo Molnar wrote:
>> This patch makes it possible to give kernel messages a selectable
>> color. It can be chosen at compile time, overridden at boot time, and
>> changed at run time.
>
>here's some (good) text footprint data:
>
>with the feature disabled (which is the default), the text size
>difference with patch #1:
>
> vmlinux:
> text data bss dec hex filename
> 7732358 1157269 401408 9291035 8dc51b vmlinux.before
> 7732358 1157269 401408 9291035 8dc51b vmlinux.after
>
I already posted the numbers. But it seems like the archives
like lkml.org or marc.info did not archive them (but i've cc'ed plenty
so you did not miss it.). See below.
>i.e. no overhead. Text size difference with patch #2:
>
> vmlinux:
> text data bss dec hex filename
> 7732358 1157269 401408 9291035 8dc51b vmlinux.before
> 7732374 1157269 401408 9291051 8dc52b vmlinux.after
>
>16 bytes, or 0.0002% of the total text size. So there's in essence no
>text overhead to talk about. So the text overhead argument is a red
>herring.
16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.
||Date: Sat, 6 Oct 2007 22:09:13 +0200 (CEST)
||Subject: [PATCH 0/2] Colored kernel output (run3)
||
||ok, so to make Oleg happy, here is run3 with a bool config option.
||
||i386>>
|| 48679 vt.o w/o anything
|| 48679 vt.o w/patch1
|| 49117 vt.o w/patch1 + CONFIG_VT_CKO=y
|| 49198 vt.o w/patch1+patch2 + CONFIG_VT_CKO=y
||--------
|| 519 total cost of CKO
||
||x86_64>>
|| 71892 vt.o w/patch1+patch2
|| 72787 vt.o w/patch1+patch2 + CONFIG_VT_CKO=y
||--------
|| 895
* Jan Engelhardt <[email protected]> wrote:
> > vmlinux:
> > text data bss dec hex filename
> > 7732358 1157269 401408 9291035 8dc51b vmlinux.before
> > 7732374 1157269 401408 9291051 8dc52b vmlinux.after
> >
> >16 bytes, or 0.0002% of the total text size. So there's in essence no
> >text overhead to talk about. So the text overhead argument is a red
> >herring.
>
> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.
yes, it's that low, and it's with the feature disabled. (People who
enable a feature will of course see text size increase, but that's
beside the point.)
Ingo
On Oct 7 2007 18:59, Ingo Molnar wrote:
>> > vmlinux:
>> > text data bss dec hex filename
>> > 7732358 1157269 401408 9291035 8dc51b vmlinux.before
>> > 7732374 1157269 401408 9291051 8dc52b vmlinux.after
>> >
>> >16 bytes, or 0.0002% of the total text size. So there's in essence no
>> >text overhead to talk about. So the text overhead argument is a red
>> >herring.
>>
>> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.
>
>yes, it's that low, and it's with the feature disabled.
Ah, with CONFIG_CKO=n, right. But where does that 16 byte increase
come from, when vt.o itself remains constant in size?
* Jan Engelhardt <[email protected]> wrote:
>
> On Oct 7 2007 18:59, Ingo Molnar wrote:
> >> > vmlinux:
> >> > text data bss dec hex filename
> >> > 7732358 1157269 401408 9291035 8dc51b vmlinux.before
> >> > 7732374 1157269 401408 9291051 8dc52b vmlinux.after
> >> >
> >> >16 bytes, or 0.0002% of the total text size. So there's in essence no
> >> >text overhead to talk about. So the text overhead argument is a red
> >> >herring.
> >>
> >> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions.
> >
> >yes, it's that low, and it's with the feature disabled.
>
> Ah, with CONFIG_CKO=n, right. But where does that 16 byte increase
> come from, when vt.o itself remains constant in size?
comes from printk.o:
text data bss dec hex filename
6068 231 17636 23935 5d7f kernel/printk.o
6075 231 17636 23942 5d86 kernel/printk.o
the effect of the extra parameter. But that is not worth #ifdef-ing for.
For all practical purposes there's no overhead.
Ingo
On Sat, 2007-10-06 at 22:09 +0200, Jan Engelhardt wrote:
> Colored kernel message output (1/2)
>
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time,
> and changed at run time.
>
> References: http://lkml.org/lkml/2007/4/1/162
> http://lkml.org/lkml/2007/10/5/199
This is quite a long thread :-)
>
> Signed-off-by: Jan Engelhardt <[email protected]>
>
> ---
> drivers/char/Kconfig | 42 ++++++++++++++++++++++++++++++++++++++++++
> drivers/char/vt.c | 23 +++++++++++++++++++++++
> 2 files changed, 65 insertions(+)
>
> Index: linux-2.6.23/drivers/char/Kconfig
> ===================================================================
> --- linux-2.6.23.orig/drivers/char/Kconfig
> +++ linux-2.6.23/drivers/char/Kconfig
> @@ -58,6 +58,48 @@ config VT_CONSOLE
>
> If unsure, say Y.
>
> +config VT_CKO
> + bool "Colored kernel message output"
> + depends on VT_CONSOLE
> + ---help---
> + This option enables kernel messages to be emitted in
> + colors other than the default.
> +
> + If unsure, say N.
> +
> +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".
> + (OR-ed) of a foreground and a background color.
> +
> + Foreground:
> + 0x00 = black, 0x08 = dark gray,
> + 0x01 = red, 0x09 = light red,
> + 0x02 = green, 0x0A = light green,
> + 0x03 = brown, 0x0B = yellow,
> + 0x04 = blue, 0x0C = light blue,
> + 0x05 = magenta, 0x0D = light magenta,
> + 0x06 = cyan, 0x0E = light cyan,
> + 0x07 = gray, 0x0F = white,
> +
> + (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.
For 2-colors (we still have quite a few of them) only bit 0 is true for
color (0x00 and 0x01). The rest of the bits are interpreted as
attributes:
0x02 - italic
0x04 - underline
0x08 - bold
0x80 - blink
The italic, underline and bold attributes will show up in a 2-color
framebuffer console. The blink attribute is ignored.
With a 4-color fb console (4-level grayscale), those values are again
interpreted differently.
0x00 - 0x00 : black
0x01 - 0x06 : white
0x07 - 0x08 : gray
the rest : intense white
(If by mistake 0x0106 is used, it will produce a white on white display)
With an 8-color console, only the first 8 values are considered.
With a 16-color console, that is also not consistent:
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 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.
> config HW_CONSOLE
> bool
> depends on VT && !S390 && !UML
> Index: linux-2.6.23/drivers/char/vt.c
> ===================================================================
> --- linux-2.6.23.orig/drivers/char/vt.c
> +++ linux-2.6.23/drivers/char/vt.c
> @@ -73,6 +73,7 @@
> */
>
> #include <linux/module.h>
> +#include <linux/moduleparam.h>
> #include <linux/types.h>
> #include <linux/sched.h>
> #include <linux/tty.h>
> @@ -2344,6 +2345,23 @@ struct tty_driver *console_driver;
>
> #ifdef CONFIG_VT_CONSOLE
>
> +static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
> +#ifdef CONFIG_VT_CKO
> +module_param(printk_color, uint, S_IRUGO | S_IWUSR);
> +
> +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.
Tony
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.
On Tue, 2007-10-09 at 01:31 +0200, 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?
All drivers under drivers/video/console. That would be:
vgacon
dummycon
fbcon
newport_con
sticon
promcon
mdacon
There are perhaps a few more drivers outside this directory, such as
sisusbcon or something.
<snip>
> >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.
That's right. But setting the blink attribute is done with an XOR (^).
So 'setterm -blink' on will unset the blink attribute (0x80 ^ 0x80).
> I'll have to try this, because usually, setterm operates on TTYs
> rather than VCs.
Yes, but if the tty driver type is a virtual console, then vt.c is still
affected.
Well the blink attribute is ignored by most drivers, if I'm not
mistaken. So you generally won't see the effect :-). But with fbcon, the
blink attribute is interpreted as "change background color from black to
light gray".
Tony
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