lkml.org 
[lkml]   [2002]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Radeon frame buffer driver
On Wed, 10 Apr 2002, Peter Horton wrote:
> On Wed, Apr 10, 2002 at 01:06:09PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 10 Apr 2002, Peter Horton wrote:
> > >
> > > The colour map is only used by the kernel and the kernel only uses 16
> > > entries so there isn't any reason to waste memory by making it any
> > > larger. I checked a few other drivers and they do the same (aty128fb for
> > > one).
> >
> > However, this change will make the driver not save/restore all color map
> > entries on VC switch in graphics mode.
>
> Well I thought this didn't matter because if we only use 16 entries they
> will all be saved / restored. But there is a problem because the copy of
> the entire palette that we keep is per card and will be lost on VC
> switch, though the kernel will restore the first 16 entries. Really we
> need to keep a copy of the relevant part of the palette for each display
> (256 for 8bpp, 32 for 15 bit mode, 64 for 16bpp and 256 for 32bpp).
> Looking at a handful of drivers this seems to be a common error, so it
> can't be causing users much grief. I don't think changing the size of
> the colour map fixes this though (I need to look at the code when I get
> home).

Or: few fbdev applications expect a correct behavior.
IIRC XF68_FBDev also saves/restores the palette itself.

> On a side note would you take a patch that changed the cursor xor value
> in fbcon-cfb16/24/32 to the correct value if the display is DIRECTCOLOR
> rather than TRUECOLOR? We could then avoid having to set spurious
>
> I think the correct xor values are
>
> depth 15 0x3DEF
> depth 16 0x79EF
> depth 24/32 0x000F0F0F
>
> P.

In general, this is not correct, since no one guarantees that in e.g. depth 32
the alpha bits are in the 8 most significant bits of the pixel value.
But in directcolor mode XORing with the 16th entry of the pseudo palette should
be OK. So yes, I guess we (cfr. the CC to linux-fbdev-devel) would take a
patch for that...

That's why for 2.5.x we plan to add a 17th entry to the pseudo palette, so the
fbdev can specify the correct XOR value.

> palette indices to make the soft cursor work. I note that fbcon-cfb8
> does the right thing.

Yes, but fbcon-cfb8 does the right thing for pseudocolor modes only :-( There
does exist non-pseudocolor depth 8 hardware (e.g. RGB332).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.043 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site