linux-fbdev-devel

[Linux-fbdev-devel] Question on imageblit

[Antonino D. <ad...@po...>]

Hi,

I have written a framebuffer driver for the i810/i815 chipsets for
linux-2.5.12.  It entirely uses fbgen, and for accelerated drawing
functions, fbcon-accel (copyarea, fillrect and imageblit).  It works
quite well in my system.

My question:  Imageblit is used primarily for putc and putcs, right?  So
basically, a monochrome bitmap located in system memory is copied to the
framebuffer memory which also undergoes color expansion depending on the
pixelformat of the framebuffer. So, is it necessary to support other
color conversions (such as a copy from 8bpp to 32bpp, or even from a
higher bpp to a lower bpp)?  

The patch is at
http://prdownloads.sourceforge.net/i810fb/linux-2.5.12-i810fb.tar.bz2
The patch already includes James Simmons' fbdev_fixs.diff for 2.5.12. 

Tony 

Re: [Linux-fbdev-devel] Question on imageblit

[James S. <jsi...@tr...>]

> I have written a framebuffer driver for the i810/i815 chipsets for
> linux-2.5.12.  It entirely uses fbgen, and for accelerated drawing
> functions, fbcon-accel (copyarea, fillrect and imageblit).  It works
> quite well in my system.

Yeah!!!!!

> My question:  Imageblit is used primarily for putc and putcs, right?  

  That AND for drawing the penguin. The code doesn't exist in fbcon.c yet
to handle drawing the penguin when using only the accel wrapper. I need to
add that.  
  To draw the pengiun using the accel wrapper I need to set the color map
to the what the penguin needs. Then I create fb_image where each piece of 
data in char* field are a value that represents where in the struct
fb_cmap that data is. I think this is the best approach to that. Any
suggestions other wise?

> basically, a monochrome bitmap located in system memory is copied to
> the framebuffer memory which also undergoes color expansion depending
> on the pixelformat of the framebuffer.

Yeap!

> So, is it necessary to support other color conversions (such as a copy
> from 8bpp to 32bpp, or even from a higher bpp to a lower bpp)?

Hm.
  
> The patch is at
> http://prdownloads.sourceforge.net/i810fb/linux-2.5.12-i810fb.tar.bz2
> The patch already includes James Simmons' fbdev_fixs.diff for 2.5.12.

Will try.

Re: [Linux-fbdev-devel] Question on imageblit

[Antonino D. <ad...@po...>]

On Fri, 2002-05-03 at 04:06, James Simmons wrote:

>   To draw the pengiun using the accel wrapper I need to set the color map
> to the what the penguin needs. Then I create fb_image where each piece of 
> data in char* field are a value that represents where in the struct
> fb_cmap that data is. I think this is the best approach to that. Any
> suggestions other wise?
> 

I think that will be a good idea.  I have heard of graphics cards that
will lock-up if a read/write to graphics memory and a hardware operation
such as a blit occured simultaneously.  Using either pure accel or pure
software rendering to draw to the framebuffer will make it easier for
the driver to watch out for those.

Which refers again to my previous question --  So basically, imageblit
has to support functions other than conversion from monochrome ->
framebuffer pixelformat.  But I don't think not all cards will support
other forms of color conversions.  In that case, imageblit will be
better supported by hardware by restricting it to:

	1. copy from monochrome->higher pixel formats (for drawing 	   text);
and
	2. copy where the src and destination have the same pixelformat 	  
(much like copyarea -- for drawing images).
    
Tony

Re: [Linux-fbdev-devel] Question on imageblit

[James S. <jsi...@tr...>]

> >   To draw the pengiun using the accel wrapper I need to set the color map
> > to the what the penguin needs. Then I create fb_image where each piece of 
> > data in char* field are a value that represents where in the struct
> > fb_cmap that data is. I think this is the best approach to that. Any
> > suggestions other wise?
> > 
> 
> I think that will be a good idea.  I have heard of graphics cards that
> will lock-up if a read/write to graphics memory and a hardware operation
> such as a blit occured simultaneously.  Using either pure accel or pure
> software rendering to draw to the framebuffer will make it easier for
> the driver to watch out for those.

Yes. That was the idea.
 
> Which refers again to my previous question --  So basically, imageblit
> has to support functions other than conversion from monochrome ->
> framebuffer pixelformat.  But I don't think not all cards will support
> other forms of color conversions.  In that case, imageblit will be
> better supported by hardware by restricting it to:
> 
> 	1. copy from monochrome->higher pixel formats (for drawing 	   text);
> and
> 	2. copy where the src and destination have the same pixelformat 	  
> (much like copyarea -- for drawing images).

Yes. You have to limit imageblit because of this. Also we don't want to
color expansion for the software version of imageblit. Yuck!!! So yes the
src image MUST be the depth as the framebuffer.