linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux Frame Buffer Device Development
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: fb_imageblit()
Date: 06 Jan 2003 02:06:52 +0800	[thread overview]
Message-ID: <1041790045.1037.23.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.GSO.4.21.0301051723310.10559-100000@vervain.sonytel.be>

On Mon, 2003-01-06 at 00:38, Geert Uytterhoeven wrote:
> 
> I have a few questions and comments related to fb_imageblit().
> 
>  1. Why is the logo data in fb_image.data stored in an `unpacked' way? I.e.
>     each byte of the logo data corresponds to one pixel of the image,
>     irrespective of the depth of the image.
> 
I asked before what would be the content of the logo data and it was
agreed that the logo data would either contain indices to the
pseudo_palette for truecolor and directcolor or the pixel itself for the
rest so it's consistent with the rest of the soft accel functions. 
Fixing the minimum unit to one byte seems a reasonable compromise
between maximum number of colors available and size of logo data.  Plus,
it would be simpler to code.

>     However, I do see one good reason: it makes life easier for planar
>     displays, since a fast c2p (chunky-to-planar) convertor doesn't have to
>     care about the image depth, the source data is always 1 byte per pixel.
> 
>  2. If fb_image.depth == 1, how can fb_imageblit() distinguish between drawing
>     a monochrome image (e.g. penguin logo) and color expanding a monochrome
>     image (e.g. drawing text)? It's not possible to handle them the same, since
>     image data for color expansion is packed, while image data for monochrome
>     image drawing is not.
I noticed this before but completely forgot about it because I have no
monochrome graphics card to test :-)

>     
>     If monochrome image data would be packed as well, it could be handled by
>     setting fb_image.fg_color = 1 and fb_image.bg_color = 0 (or vice versa for
>     mono10), and fb_set_logo() becomes simpler as well.
> 
>     If we retain the unpacked data for images, we need some other flag to
>     indicate color expansion. Perhaps setting fb_image.depth to 0?
> 
If we change the contents of the logo data, then it makes sense to pack
the logo data also.  However, if we stick to indices, we might as well
retain the "unpacked" 8-bit format.  I think setting fb_image.depth to 0
to mean color expansion is more appropriate. Drivers that will need
trivial changing would be tgafb, i810fb, rivafb, tdfxfb, atyfb, vga16fb
and of course cfb_imgblt.c, softcursor.c and fbcon.c.

I'll submit a patch if everyone agrees.  

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  reply	other threads:[~2003-01-05 18:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-05 16:38 fb_imageblit() Geert Uytterhoeven
2003-01-05 18:06 ` Antonino Daplas [this message]
2003-01-05 18:59   ` fb_imageblit() Geert Uytterhoeven
2003-01-07 22:23   ` fb_imageblit() James Simmons
2003-01-08  2:41     ` fb_imageblit() Antonino Daplas
2003-01-08 15:15       ` fb_imageblit() Geert Uytterhoeven
2003-01-08 16:25         ` fb_imageblit() Antonino Daplas
2003-01-08 16:49           ` fb_imageblit() Geert Uytterhoeven
2003-01-10 18:37             ` fb_imageblit() James Simmons
2003-01-09  9:50           ` fb_imageblit() Geert Uytterhoeven
2003-01-09 11:44             ` fb_imageblit() Antonino Daplas
2003-01-10 18:47               ` fb_imageblit() James Simmons
2003-01-10 19:23       ` fb_imageblit() James Simmons
2003-01-10 19:41         ` fb_imageblit() Geert Uytterhoeven
2003-01-11  5:11         ` fb_imageblit() 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=1041790045.1037.23.camel@localhost.localdomain \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).