From: Antonino Daplas <adaplas@pol.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: fbdev <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Adding an fb_sync() operation to fb_ops
Date: 01 Jun 2002 21:29:53 +0800 [thread overview]
Message-ID: <1022938092.543.3.camel@daplas> (raw)
In-Reply-To: <Pine.GSO.4.21.0205312213000.13028-100000@vervain.sonytel.be>
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
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
next prev parent reply other threads:[~2002-06-01 13:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-30 19:05 Adding an fb_sync() operation to fb_ops Antonino Daplas
2002-05-31 19:56 ` James Simmons
2002-05-31 20:14 ` Geert Uytterhoeven
2002-06-01 13:29 ` Antonino Daplas [this message]
2002-06-01 12:31 ` Antonino Daplas
-- strict thread matches above, loose matches on Subject: below --
2002-05-30 21:25 Sottek, Matthew J
2002-05-31 20:02 ` James Simmons
2002-06-03 15:49 Sottek, Matthew J
2002-06-03 23:53 Antonino Daplas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1022938092.543.3.camel@daplas \
--to=adaplas@pol.net \
--cc=geert@linux-m68k.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.