Hi,
this patch adds 32 bit support to cyber2000fb which is useful
if you have a video layer in the background (CyberPro 5xxx) with
per pixel alpha blending enabled.
This patch also includes a fix for the text palette for modes
with more than 8 bit.
Applies against Linux 2.5.21.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
Convergence GmbH
On Sat, 15 Jun 2002, Denis Oliver Kropp wrote:
> Quoting James Simmons ([email protected]):
> >
> > > Why is the pseudo palette used anyway?
> >
> > Its a fast way for the console to grab the proper console index color to
> > draw to the framebuffer. Otherwise we have to regenerate the color all the
> > time. Plus it is always endian code for us :-)
>
> I didn't mean the array of colors for the console, but the usage of
> the hardware palette for modes != 8 bit.
>
> > > There's no speed benefit and
> > > applications running in true/direct color would look wrong.
> >
> > For userland no but for the kernel we do have a benifiet.
>
> There's no speed benefit if you write "index|index|index" into the
> framebuffer instead of "red|green|blue".
But it does allow to change the console palette without the need to redraw the
screen, just like for VGA text mode.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
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".
> @@ -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.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoting Russell King ([email protected]):
> 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
> Why is the pseudo palette used anyway?
Its a fast way for the console to grab the proper console index color to
draw to the framebuffer. Otherwise we have to regenerate the color all the
time. Plus it is always endian code for us :-)
> There's no speed benefit and
> applications running in true/direct color would look wrong.
For userland no but for the kernel we do have a benifiet.
Quoting James Simmons ([email protected]):
>
> > Why is the pseudo palette used anyway?
>
> Its a fast way for the console to grab the proper console index color to
> draw to the framebuffer. Otherwise we have to regenerate the color all the
> time. Plus it is always endian code for us :-)
I didn't mean the array of colors for the console, but the usage of
the hardware palette for modes != 8 bit.
> > There's no speed benefit and
> > applications running in true/direct color would look wrong.
>
> For userland no but for the kernel we do have a benifiet.
There's no speed benefit if you write "index|index|index" into the
framebuffer instead of "red|green|blue".
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
Convergence GmbH
On Sat, Jun 15, 2002 at 12:55:47PM +0200, Denis Oliver Kropp wrote:
> > > There's no speed benefit and
> > > applications running in true/direct color would look wrong.
> >
> > For userland no but for the kernel we do have a benifiet.
>
> There's no speed benefit if you write "index|index|index" into the
> framebuffer instead of "red|green|blue".
You're actually asking the wrong question. "Why is there such a thing as
directcolor" would be a better question. After all, if there's no "speed
benefit" when why do manufacturers bother implementing it?
Could it be because it allows colours to be dynamically allocated? Given
a "good enough" allocator which looks over your complete colour usage, you
could probably make better use of the available colours than truecolor
allows.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoting Russell King ([email protected]):
> On Sat, Jun 15, 2002 at 12:55:47PM +0200, Denis Oliver Kropp wrote:
> > > > There's no speed benefit and
> > > > applications running in true/direct color would look wrong.
> > >
> > > For userland no but for the kernel we do have a benifiet.
> >
> > There's no speed benefit if you write "index|index|index" into the
> > framebuffer instead of "red|green|blue".
>
> You're actually asking the wrong question. "Why is there such a thing as
> directcolor" would be a better question. After all, if there's no "speed
> benefit" when why do manufacturers bother implementing it?
>
> Could it be because it allows colours to be dynamically allocated? Given
> a "good enough" allocator which looks over your complete colour usage, you
> could probably make better use of the available colours than truecolor
> allows.
I don't think that the text console with 16 different colors needs more
precision than 5 bits per color channel (speaking of RGB555).
However, using directcolor to have a gamma ramp in user space applications
seems quite useful.
Drivers should support both direct- and truecolor for all bit depths with
default to truecolor, otherwise applications would always have to setup
the palette.
Anyway, the current version of the cyber2000 driver reports directcolor
while programming the hardware for truecolor. I can do another patch
that keeps the directcolor feature along with the other fixes.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
Convergence GmbH