Re: Problem with current fb_get_color_depth function

[joshk@triplehelix.org (Joshua Kwan)]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

[ long overdue follow-up ]

On Mon, Oct 11, 2004 at 08:33:10AM +0800, Antonino A. Daplas wrote:
> So, linux_logo_224 cannot be drawn when visual is directcolor at RGB555 or
> RGB565 because the logo clut requirements exceeds the hardware clut
> capability. You need to use a logo image with a lower depth such as the
> 16-color logo, linux_logo_16.

This is weird, because removing that conditional from fb_get_color_depth
allows a 224-color logo to show correctly on my Radeon framebuffer, in
full color.

Otherwise, it is dithered to kingdom come and mostly appears all orange
and black.

You may be right conceptually, but the fact of the matter is that this
is a regression because 224-color logos work perfectly with the old
fb_get_color_depth. So what is the real problem?

> In short, fb_get_color_depth() and radeonfb both do the correct thing, but
> you need a logo with a lower color depth. Or choose RGB888 or higher, or
> set the visual to truecolor.

What does that last sentence mean? -- I have no idea...

> PS: Note that this behavior is the same as 2.4 behavior (224-color logo is
> only chosen if directcolor and bpp >= 24).  It might have worked before, and
> this is probably due to the directcolor clut being ramped to truecolor
> values. However, the correct solution is to use a 16-color logo.

Oh, I see, I didn't read this before.

Well, 16-color logos being used when 224-color ones work perfectly
enough 99% of the time is pretty bad aesthetically, if you ask me.

-- 
Joshua Kwan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]