Quoting Russell King (rmk@arm.linux.org.uk):
> On Thu, Jun 13, 2002 at 10:32:43AM +0200, Denis Oliver Kropp wrote:
> > - * Integraphics CyberPro 2000, 2010 and 5000 frame buffer device
> > + * Intergraphics CyberPro 2000, 2010 and 5000 frame buffer device
>
> This isn't actually a spelling mistake. The chips I have are quite
> clearly marked "Integraphics" not "Intergraphics".
Ok, I'm sorry for that, seemed obvious.
> > @@ -355,7 +367,9 @@
> >
> > if (regno < 16)
> > ((u16 *)cfb->fb.pseudo_palette)[regno] =
> > - regno | regno << 5 | regno << 11;
> > + ((red << 8) & 0xf800) |
> > + ((green << 3) & 0x07e0) |
> > + ((blue >> 3));
> > break;
> > }
> > #endif
>
> This seems wrong. We're setting up the DAC palette to map pixel color
> component 'regno' to 'read', 'green' and 'blue' respectively.
>
> This means that the pseudopalette should be a 1:1 mapping of desired
> colour value (ie, the 16 VGA colors) to the DAC palette entries -
> the pseudopalette contains the pixel values to insert into the frame
> buffer for each of the 16 VGA colors.
The palette is being bypassed anyway by setting bit 4 in palette_ctrl.
Besides that I tested the rgb modes on a CyberPro 5000 with and without
this fix. The text was dark gray (as expected) in 16bit and hardly
visible in 24bit.
Why is the pseudo palette used anyway? There's no speed benefit and
applications running in true/direct color would look wrong.
-- Best regards, Denis Oliver Kropp.------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------"
Convergence GmbH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:28 EST