|
From: Geert U. <ge...@li...> - 2001-06-22 11:14:40
|
On Fri, 22 Jun 2001, Michel D=E4nzer wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 22 Jun 2001, Michel D=E4nzer wrote:
> > > While this now works perfectly in X for both depth 15 and 16 as wel=
l as in
> > > console for fbset -depth 16 -rgba 5,5,5,0 , some colors are wrong f=
or
> > > fbset -depth 16 -rgba 5,6,5,0 . It's not clear to me whether the pa=
lette
> > > for
> >=20
> > Funny, I have similar problems with atyfb and 565 (didn't manage to g=
et X
> > working yet, since I still use 3.3.6 which seems to pass invalid para=
meters
> > when being `strict' in the color bitfield checking).
>=20
> I know, Michael Schmitz forwarded your patch to me, it helped me a lot,
> thanks.
>=20
> > > 565 should have 32 or 64 entries.
> >=20
> > 64 of course. But red and blue should fill the first 32 entries only.
>=20
> Okay, but why do you allocate a cmap with only 32 entries then? Do you
> extrapolate the missing green entries in this line?
>=20
> green =3D info->palette[(2*regno) & 0xff].green;
> ^^^^^^^^^^^^^^^^
> I don't understand what this is supposed to do. As 0<regno<32, (2*regno=
) can't
For palette index regno, red and blue are stored in a different DAC entry=
than
green. So when I store red and blue, I have to make sure I write the corr=
ect
green value there. That green value is palette[regno*2].green. Follow the
fall-through and merge the code:
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);
> be greater than 255, so what's the 0xff for?
I wanted to be sure, you never know...
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
|