Fix for my previous commit: color mapping is not 1:1.

Cons25 doesn't seem to use a straight 1:1 mapping to the ANSI colors,
but uses the same color numbers as at least used by syscons on i386. I
suspect if you change the definitions on a different architecture,
things may break? Not sure.

Add a small array to convert syscons-style color codes to ANSI
equivalents, which are used by libteken internally. I didn't notice this
bug, because I only tested my code with black, white and green, all of
them shared the same numbers.
This commit is contained in:
ed 2009-01-17 23:01:40 +00:00
parent 7bd93f5fdb
commit 57e1b2ae2f

View File

@ -33,20 +33,23 @@ teken_subr_cons25_set_cursor_type(teken_t *t, unsigned int type)
teken_funcs_param(t, TP_SHOWCURSOR, type != 1);
}
static teken_color_t cons25_colors[8] = { TC_BLACK, TC_BLUE, TC_GREEN,
TC_CYAN, TC_RED, TC_MAGENTA, TC_BROWN, TC_WHITE };
static void
teken_subr_cons25_set_adapter_background(teken_t *t, unsigned int c)
{
t->t_defattr.ta_bgcolor = c % 8;
t->t_curattr.ta_bgcolor = c % 8;
t->t_defattr.ta_bgcolor = cons25_colors[c % 8];
t->t_curattr.ta_bgcolor = cons25_colors[c % 8];
}
static void
teken_subr_cons25_set_adapter_foreground(teken_t *t, unsigned int c)
{
t->t_defattr.ta_fgcolor = c % 8;
t->t_curattr.ta_fgcolor = c % 8;
t->t_defattr.ta_fgcolor = cons25_colors[c % 8];
t->t_curattr.ta_fgcolor = cons25_colors[c % 8];
if (c >= 8) {
t->t_defattr.ta_format |= TF_BOLD;
t->t_curattr.ta_format |= TF_BOLD;