[PATCH 1/2] Colored kernel output (run3) - Kernel

This is a discussion on [PATCH 1/2] Colored kernel output (run3) - Kernel ; 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 --- ...

+ Reply to Thread
Results 1 to 13 of 13

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

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


    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

    ---
    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
    +#include
    #include
    #include
    #include
    @@ -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:
    -
    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/

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

    On Sat, 6 Oct 2007 22:09:52 +0200 (CEST)
    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.


    As the nearest thing to a tty maintainer I'd like to NAK this as "Silly"
    -
    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/

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


    * 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.


    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
    Signed-off-by: Ingo Molnar
    ---
    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
    +#include
    #include
    #include
    #include
    @@ -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:
    -
    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/

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


    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 :-(

    -
    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/

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


    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
    -
    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/

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


    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
    -
    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/

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


    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?
    -
    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/

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


    * Jan Engelhardt 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
    -
    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/

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


    * Jan Engelhardt 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
    -
    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/

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

    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
    >
    > ---
    > 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
    > +#include
    > #include
    > #include
    > #include
    > @@ -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



    -
    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/

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


    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/

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

    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.



    > >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

    -
    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/

  13. 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
    "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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread