Quoting Russell King (rmk@arm.linux.org.uk):
> 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 - 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:33 EST