lkml.org 
[lkml]   [2002]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linux-fbdev-devel] [PATCH] soft accels.
On Tue, 12 Mar 2002, James Simmons wrote:
> > > This code provides software accels to replace all the fbcon-cfb* stuff.
> > > Gradually the fbdev drivers can be ported over to it. It is against
> > > 2.5.5-dj3. Please apply the patch.
> >
> > I'm still wondering whether it's a good idea to assume all color values (e.g.
> > fb_fillrect.color) are palette indices. This means you cannot draw a rectangle
> > with an arbitrary color using cfb_fillrect().
>
> Would we ever want to do that? Also using the color map regno is to a
> advantage for non packed pixel modes.
>
> > Furthermore this means that fillrect() and imageblit() (the color image case)
> > expect different formats: the former expects a palette index, the latter
> > expects the native frame buffer format (cfr. your comments in the code below).
>
> I need to change that. I want to have the image blit function use the
> color palette. The most we will ever use is 256 colors for the penguin.
> Do we need to expand that more?

I don't know. I'm just thinking about one day we want to do more with it in the
kernel.

> > The 17-entry (16 colors + 1 XOR mask) pseudo palette is actually something
> > related to the console, so I would not handle it in the low level drawing
> > routines, but in the frame buffer console layer. Of course the pseudo palette
> > still has to be initialized by the frame buffer device, since that is the part
> > that knows about the mapping from console palette indices to native pixel
> > values. This also means you'll have a pseudo palette for all modes, including
> > pseudocolor[*].
> >
> > What do you think?
>
> Hm. True pseudopalette is more a console thing. One of the reasons I made
> pseudo_palette a void was so anything type of data could be indexed to a
> color map regno. It really should be in a par struct for each driver.
> Personally I don't care for it and like to see it go away. Instead we
> could generate the color value from the fb_bitfields in struct
> fb_var_screeninfo and the red, green, blue etc from struct fb_cmap. The
> only thing preventing me from doing this is that it cost to generate those
> vlaues whereas we have the values already saved in pseudo_palette. The
> penalty tho only shows up when we draw each character.

Or you can precalculate them on each mode change and fill some tables. This is
what I do in fbtest, to make things as generic as possible, without a too high
speed penalty.

> > [*] Or set pseudo_palette to NULL, and use
> >
> > pixval = pseudo_palette ? pseudo_palette[idx] : idx;
> >
> > and
> >
> > xormask = pseudo_palette ? pseudo_palette[16] : 15;
>
> When we change from truecolor mode to pseudo color wouldn't we have to
> NULL the pseudo_palette pointer then?

Yes.

> > Color images are not yet implemented?
>
> Not yet. I wanted to have font support first.

OK.

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:22    [W:0.364 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site