From: Antonino A. D. <ad...@ho...> - 2004-07-31 23:38:08
|
On Sunday 01 August 2004 06:19, Alexander Kern wrote: > Am Samstag, 31. Juli 2004 23:19 schrieb Antonino A. Daplas: > > On Saturday 31 July 2004 21:31, Ville Syrj=E4l=E4 wrote: > > > > red_reg[index * 8] =3D red > > > > green_reg[index * 8] =3D green > > > > blue_reg[index * 8] =3D blue > > > > > > > > Some hardware require that all 8 entries needs to be filled up. > > > > > > I noticed you do this in i810fb. What happens if you don't do this? > > > > =A0 > > Wrong colors. > > > > > AFAIK mach64 doesn't need this. > > > > Yes, it's hardware dependent. When I decided to add directcolor support, > > I initially copied the mach64's setcolreg function but I got wrong > > colors at bpp16. Found out by experimentation that I need to set all > > 256 entries of the CLUT. > > > > Tony > > Very scurry, even mach64 give wrong colors for me ;-)) > > Here are the pics, that demonstrate my errors. Actually, this is one of the nuances that affect DirectColor at < 24 bpp. Since RGB565 has only at the most 64 entries (based on the depth of the green channel), a 224-color logo will be drawn incorrectly. 16-bit Directcolor actually needs a 16-color logo. Unfortuanately, the logo drawing code will choose a 224-color logo for Directcolor 16-bit. This is problem that I pointed out to James a long time ago when he rewrote the=20 logo drawing code.=20 It's a little bit surprising that 8-bit pseudocolor can actually draw a 224-color logo correctly, while 16-bit directcolor cannot :-) Workaround: Force fbdev to use 16-color linux logo in the "Boot Logo" option of your kernel config. I'll see if I can find a way for a more definitive fix. Tony P.S. This problem might be unique to the logo drawing code. |