Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Geert U. <ge...@li...>]

On Fri, 22 Jun 2001, Petr Vandrovec wrote:
> On 22 Jun 01 at 15:06, Michel D=E4nzer wrote:
> > Petr Vandrovec wrote:
> > > On 22 Jun 01 at 13:11, Geert Uytterhoeven wrote:
> > > >     aty_st_dac(regno << 2, palette[regno/2].red, green,
> > > >                palette[regno/2].blue);
> > > >     aty_st_dac(regno << 3, red, palette[(2*regno) & 0xff].green, =
blue);
> > >=20
> > > I do not see rest of code, but does your code correctly set
> > > zero register? Is not green field overwritten by its old value?
> >=20
> > If the order is wrong, it can be changed.
>=20
> Order is not wrong. Idea is wrong... You must do:
>=20
> if (regno) {
>    <your old code>
> } else {
>    aty_st_dac(0, red, green, blue);
> }=20
>=20
> as 'old' code sets either green, or red+blue wrong.

Perhaps I'm in a bad mood, but I still fail to see what's wrong with the =
above
code...

Note that palette[regno] is set before aty_st_dac() is called.

> We have console color <0-15>, pixel color <0-(1<<bpp-1)> and displayed
> color <rgb 0-65535,0-65535,0-65535>. set palette API sets
> pixel color -> displayed color value for pseudocolor and direct color
> (and for directcolor in really strange manner as shown by regno<<3+regn=
o<<2
> troubles), while for truecolor it sets console color -> pixel color

The `regno<<3+regno<<2' stuff is there because of a hardware feature: in =
RGB565
mode, the red and blue entries are spaced apart 8 entries (256/32), while=
 the
green entries are spaced apart 4 entries (256/64). So there's no weird fb=
dev
behavior here.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6=
8k.org

In personal conversations with technical people, I call myself a hacker. =
But
when I'm talking to journalists I just say "programmer" or something like=
 that.
							    -- Linus Torvalds