From: Antonino Daplas <adaplas@pol.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: James Simmons <jsimmons@infradead.org>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Re: [PATCH]: image.depth fix to accomodate monochrome cards
Date: 11 Jan 2003 13:10:18 +0800 [thread overview]
Message-ID: <1042254692.932.31.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.GSO.4.21.0301102041130.18440-100000@vervain.sonytel.be>
On Sat, 2003-01-11 at 03:43, Geert Uytterhoeven wrote:
> On Fri, 10 Jan 2003, James Simmons wrote:
> > > I think we still have several corner cases, such as TRUECOLOR with bpp
> > > <= 8, I'm not sure if that works.
> >
> > The matorx millenium has such a mode. So such things do exist.
> >
> > > - if (image->depth == 1) {
> > > + if (image->depth == 0) {
> >
> > P.S
> >
> > I'm just not to crazy about the depth equal zero thing. I just pitcure
> > developers having a hard time with it.
>
> Monochrome color expansion just works differently: it expands the zeroes and
> ones in a bitmap based on fg_color and bg_color, while image drawing draws an
> image containing colormap indices to the frame buffer.
>
> Do you have a better suggestion?
>
If James is a bit skeptical about this, how about doing it this way:
If image.fg_color and image.bg_color == 0, then each byte of image.data
is an index to the pseudo_palette, or the actual pixel, whatever the
case may be. Otherwise, image.data is a monochrome bitmap that should
be expanded using fg_color and bg_color.
No other changes will be needed except that mono cards have to test for
fg_color and bg_color, and we need to memset the fb_image structure to 0
in fb_set_logo(). Non-mono cards will continue testing for image.depth.
Do you think this will work? The only problem I can think of is a color
expansion request where both bg and fg is 0.
Or to totally eliminate the above possibility, add an extra field in
struct fb_image to denote color expansion vs logo drawing. Again, only
mono cards will need to do this test.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
next prev parent reply other threads:[~2003-01-11 5:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-07 16:16 [PATCH]: image.depth fix to accomodate monochrome cards Antonino Daplas
2003-01-07 21:06 ` Geert Uytterhoeven
2003-01-08 2:41 ` Antonino Daplas
2003-01-08 9:52 ` Geert Uytterhoeven
2003-01-08 16:25 ` Antonino Daplas
2003-01-08 16:51 ` Geert Uytterhoeven
2003-01-10 19:27 ` James Simmons
2003-01-10 19:43 ` Geert Uytterhoeven
2003-01-11 5:10 ` Antonino Daplas [this message]
2003-01-11 13:24 ` Geert Uytterhoeven
2003-01-11 13:47 ` Antonino Daplas
2003-02-05 15:03 ` Geert Uytterhoeven
2003-02-05 7:14 ` Antonino Daplas
2003-02-12 20:50 ` James Simmons
2003-02-12 23:37 ` Antonino Daplas
2003-02-13 9:27 ` Geert Uytterhoeven
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=1042254692.932.31.camel@localhost.localdomain \
--to=adaplas@pol.net \
--cc=geert@linux-m68k.org \
--cc=jsimmons@infradead.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.