Re: [linux-fbdev] New api again

[Geert U. <ge...@li...>]

On Wed, 17 Jan 2001, James Simmons wrote:
>   I never did figure out how Amiga interleaved bitplanes are layed out. How 
> do you fill in one pixel of some color to the display? Once I have that
> figured out I can write a really fast rectfill, copyarea, and imageblit
> for it. 

OK, I'll tell you how the Amiga display hardware works. Amiga always uses
bitplanes (1-8)

  - You have 8 bitplane pointers (bplpt[8]), through which display data is
    fetched (with auto-increment), one for each bitplane.
  - You have 2 bitplane modulo registers (bpl1mod and bpl2mod), which are added
    to the even resp. odd bitplane pointers at the end of each scanline (FYI:
    You have 2 of them to support `dual playfield mode', in which you have 2
    independent playfields formed by the even and odd bitplanes. This is not
    supported by amifb).

This provides quite some flexibility, since you can store individual bitplanes
in memory wherever you want.

For `normal bitplanes' (all bitplanes stored in memory after each other,
handled by `fbcon-afb'), you set:

    bplpt[i] = start+i*(width*height/8);
    bpl1mod = bpl2mod = 0;

For `interleaved bitplanes' (all bitplanes for one scanline are stored after
each other, followed by the bitplanes for the next scanline, and so on), you
set:

    bplpt[i] = start+i*width/8;
    bpl1mod = bpl2mod = width/8*(depth-1);

The advantage of ilbm over afb is that you can copy and clear rectangular areas
using only one blit (= copy of a rectangular area in memory), while for afb you
need as many blits as you have bitplanes, so you need less blitter setup.
Furthermore you see less artefacts during scrolling. The disadvantage is that
XF68_FBDev is quite buggy for ilbm.

It should be possible to merge fbcon-afb and fbcon-ilbm. The only difference is
the value you have to add to go to the next scanline or the next bitplane.

> > > 	fb_pan_display:	xxxfb_pan_display,
> > > 	fb_rectfill:	xxxfb_rectfill,  /* optional */
> > > 	fb_copyarea:	xxxfb_copyarea,  /* optional */
> > > 	fb_imageblit:	xxxfb_imageblit, /* optional */
> > > 	fb_ioctl:       xxxfb_ioctl,     /* optional */
> > > 	fb_mmap:	xxxfb_mmap,      /* optional */	
> > > };
> > 
> > Aren't xxxfb_{rectfill,copyarea,imageblit} mandatory, because fbcon-* will go
> > away?
> 
> Yes but for the standard packed pixel non accelerated graphics cards we
> have cfbrectfill, cfbcopyarea, and cfbimageblit to use. If the driver
> doesn't provide these functions then we use these cfb* functions. I even
> stored each function in a seperate file just in case we run into cards
> that support one or two of the three accelerated functions.

Wouldn't it be better to let the driver always fill in the pointers, even if it
needs the cfb* ops?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds