|
From: Antonino D. <ad...@po...> - 2002-06-01 13:30:23
|
On Sat, 2002-06-01 at 04:14, Geert Uytterhoeven wrote:
> On Fri, 31 May 2002, James Simmons wrote:
> > > Secondly (not related to the topic), I was wondering if we can change
> > > the color value passed to fillrect and imageblit. Presently, the
> > > palette index is always passed regardless of the visual. Should the
> > > color value passed be reflective of the framebuffer format instead?
> > > Pass a palette index if pseudocolor, an RGB value for truecolor, etc.
> > >
> > > Doing the latter will simplify the low-level drawing function and at the
> > > same time, it will make the drawing functions more flexible -- ie,
> > > possiblity of exporting to userspace.
> >
> > We had this discussion sometime ago. We discovered it was just impossible
> > to handle all the possible different color formats in the higher levels.
> > We ended up with way to many #ifdefs. So it was decided to let the drivers
> > handle it instead. Actually if you wanted it to be useable to userland
> > then it makes even more sense to use the color map index instead. Think
> > about all the if() statements you would need in userland.
>
> Userland can easily set up function pointers, depending on the used format
> (for commonly used formats). Even for the generic case it can be done without
> too much loss of efficiency using look-up tables, cfr. fbtest.
>
I think that's a nice idea. We can add another fb_op (I know, another
one), something like:
static u32 XXXfb_getcolor(u32 index, struct fb_info *info)
{
u32 color = 0;
switch (info->var.bits_per_pixel) {
case 8:
color = index;
break;
case 16:
case 24:
case 32:
color = ((u32 *)(info->pseudo_palette[index]))
break;
}
return color;
}
Then in fbcon-accel.c, we can have something like:
region.fg_color = info->fb_getcolor(attr_fgcol(p, c));
region.bg_color = info->fb_getcolor(attr_bgcol(p, c));
This will simplify fbcon-accel and the drawing functions.
Tony
|