Modify setterm color palette

Modify setterm color palette

[Thomas Fazekas]

Hi,

Sorry for the crosspost, I just wasn't sure which group should I target.

Here is what I try to do : I got to modify the standard colors used by setterm,
the reason being my preference for using text consoles rather than xterms.
I also prefer the fg green bg black setup. I can acheave that just by
simply issuing a "setterm -foreground green -store". Now my problem is
that the green I get is too dark on my screeen (even if I set the display
luminosity to max). If I could modify the color used by setterm I
could get a bit
brighter green, but I'm not sure where/how to do that...

I've been looking in the kernel sources in the "console.c" and I think
spotted the
place where the colours are set but it seems to me that a more appropiate
place to do such things would be the terminfo db.

Any hints ?

I'm using radeonfb under Suse/amd64 if that makes any difference...

Rgds
Thomas

Re: Modify setterm color palette

[Jan Engelhardt]

>I've been looking in the kernel sources in the "console.c" and I think
>spotted the
>place where the colours are set but it seems to me that a more appropiate
>place to do such things would be the terminfo db.
>
>Any hints ?

drivers/char/vt.c: default_red, default_grn, default_blu

You can also change them with `echo -en "\e]PXRRGGBB"`, where X is a hex 
digit (range 0-F), and RGB are the components. Check console_codes(4) and 
go figure. :)

>I'm using radeonfb under Suse/amd64 if that makes any difference...

I am not sure if changing colors works with fb, try your best.



Jan Engelhardt
-- 

Re: Modify setterm color palette

[Willy Tarreau]

Hi Jan,

On Sun, Jan 15, 2006 at 01:15:23PM +0100, Jan Engelhardt wrote:
> 
> >I've been looking in the kernel sources in the "console.c" and I think
> >spotted the
> >place where the colours are set but it seems to me that a more appropiate
> >place to do such things would be the terminfo db.
> >
> >Any hints ?
> 
> drivers/char/vt.c: default_red, default_grn, default_blu
> 
> You can also change them with `echo -en "\e]PXRRGGBB"`, where X is a hex 
> digit (range 0-F), and RGB are the components. Check console_codes(4) and 
> go figure. :)

Thanks for the tip, I was not aware of this !

> >I'm using radeonfb under Suse/amd64 if that makes any difference...
> 
> I am not sure if changing colors works with fb, try your best.

I can confirm that it works on matrox_fb at least !

> Jan Engelhardt

regards,
willy

Re: Modify setterm color palette

[Russell King]

On Sun, Jan 15, 2006 at 01:15:23PM +0100, Jan Engelhardt wrote:
> drivers/char/vt.c: default_red, default_grn, default_blu
> 
> You can also change them with `echo -en "\e]PXRRGGBB"`, where X is a hex 
> digit (range 0-F), and RGB are the components. Check console_codes(4) and 
> go figure. :)

I for one prefer the standard VT100 yellow instead of brown, and I
have an escape sequence to do that similar to the one you show above.

However, there's one major flaw - programs recently (and by that I mean
FC2-like recently) have started to do complete console resets, which
result in the users settings being completely wiped out.

For instance, I have:

if [ "$TERM" = "linux" ]; then
  echo -ne '\e]P3aaaa00'
fi

in the bash login scripts.  Run mutt 1.4 and that gets wiped out.
Previous version of mutt (1.2?) didn't do this.

So, in essence, this is a completely useless solution.  I think we need
a separate escape sequence to modify the system default so that peoples
preferences do not get inadvertently wiped out by programs.

(I have also considered writing a module to locate the default palette
and "correct" it.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Modify setterm color palette

[Willy Tarreau]

On Sun, Jan 15, 2006 at 01:16:20PM +0000, Russell King wrote:
> On Sun, Jan 15, 2006 at 01:15:23PM +0100, Jan Engelhardt wrote:
> > drivers/char/vt.c: default_red, default_grn, default_blu
> > 
> > You can also change them with `echo -en "\e]PXRRGGBB"`, where X is a hex 
> > digit (range 0-F), and RGB are the components. Check console_codes(4) and 
> > go figure. :)
> 
> I for one prefer the standard VT100 yellow instead of brown, and I
> have an escape sequence to do that similar to the one you show above.
> 
> However, there's one major flaw - programs recently (and by that I mean
> FC2-like recently) have started to do complete console resets, which
> result in the users settings being completely wiped out.
> 
> For instance, I have:
> 
> if [ "$TERM" = "linux" ]; then
>   echo -ne '\e]P3aaaa00'
> fi
> 
> in the bash login scripts.  Run mutt 1.4 and that gets wiped out.
> Previous version of mutt (1.2?) didn't do this.
> 
> So, in essence, this is a completely useless solution.  I think we need
> a separate escape sequence to modify the system default so that peoples
> preferences do not get inadvertently wiped out by programs.

Why not add an escape sequence to lock/unlock the palette ? It might be
simpler, and we could even stack the locks to ensure recursive protection.

> (I have also considered writing a module to locate the default palette
> and "correct" it.)
> 
> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 Serial core

Regards,
Willy

Re: Modify setterm color palette

[Jan Engelhardt]

>> > drivers/char/vt.c: default_red, default_grn, default_blu
>> > 
>> > You can also change them with `echo -en "\e]PXRRGGBB"`, where X is a hex 
>> > digit (range 0-F), and RGB are the components. Check console_codes(4) and 
>> > go figure. :)
>> 
>> I for one prefer the standard VT100 yellow instead of brown, and I
>> have an escape sequence to do that similar to the one you show above.

Cool. I prefer "purified" colors, i.e. {0x00,0x00,0xFF} instead of
{0x55,0x55,0xFF} for brightblue. :D

>> However, there's one major flaw - programs recently (and by that I mean
>> FC2-like recently) have started to do complete console resets, which
>> result in the users settings being completely wiped out.
>> So, in essence, this is a completely useless solution.  I think we need
>> a separate escape sequence to modify the system default so that peoples
>> preferences do not get inadvertently wiped out by programs.
>
>Why not add an escape sequence to lock/unlock the palette ? It might be
>simpler, and we could even stack the locks to ensure recursive protection.

How about putting it into /sys...

Signed-off-by: Jan Engelhardt <jengelh@linux01.gwdg.de>
Applies with fuzz 2 because my values for default_blu are already modified 
and not the same as 2.6.15.

diff --fast -Ndpru linux-2.6.15~/drivers/char/vt.c linux-2.6.15/drivers/char/vt.c
--- linux-2.6.15~/drivers/char/vt.c	2006-01-15 21:29:12.000000000 +0100
+++ linux-2.6.15/drivers/char/vt.c	2006-01-15 22:07:22.225060000 +0100
@@ -916,6 +916,10 @@ int default_grn[] =
 int default_blu[] =
 {0x00,0x00,0x00,0x00,0x80,0xaa,0xaa,0xaa,0x55,0x00,0x00,0x00,0xff,0xff,0xff,0xff};
 
+module_param_array(default_red, int, NULL, S_IRUGO | S_IWUSR);
+module_param_array(default_grn, int, NULL, S_IRUGO | S_IWUSR);
+module_param_array(default_blu, int, NULL, S_IRUGO | S_IWUSR);
+
 /*
  * gotoxy() must verify all boundaries, because the arguments
  * might also be negative. If the given position is out of
#<<eof>>



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: Modify setterm color palette

[Pavel Machek]

On Ne 15-01-06 13:16:20, Russell King wrote:
> On Sun, Jan 15, 2006 at 01:15:23PM +0100, Jan Engelhardt wrote:
> > drivers/char/vt.c: default_red, default_grn, default_blu
> > 
> > You can also change them with `echo -en "\e]PXRRGGBB"`, where X is a hex 
> > digit (range 0-F), and RGB are the components. Check console_codes(4) and 
> > go figure. :)
> 
> I for one prefer the standard VT100 yellow instead of brown, and I
> have an escape sequence to do that similar to the one you show above.
> 
> However, there's one major flaw - programs recently (and by that I mean
> FC2-like recently) have started to do complete console resets, which
> result in the users settings being completely wiped out.

Yep, I've seen those problems too. OTOH probably its userland programs
that should be fixed not to reset terminals?
								Pavel
-- 
Thanks, Sharp!