2.5 atyfb on Sparc question

2.5 atyfb on Sparc question

[Holzrichter, Bruce]

Quick question..  I was wondering if there is still a bk tree for fbdev
work, or are you pushing direct to Linus?

I am getting the following errors when compiling on a sparc64 machine from
the latest BK 2.5 tree, and was wondering if a fix may already be around.  I
am not subscribed to this list, but a quick search didn't turn up anything.
Thanks in advance..

Thanks,
Bruce H. 

atyfb_base.c: In function `atyfb_set_dispsw':
atyfb_base.c:1098: warning: assignment discards `const' from pointer target
type
atyfb_base.c:1101: warning: assignment discards `const' from pointer target
type
atyfb_base.c:1105: warning: assignment discards `const' from pointer target
type
atyfb_base.c:1109: warning: assignment discards `const' from pointer target
type
atyfb_base.c: In function `atyfb_set_var':
atyfb_base.c:1191: warning: implicit declaration of function
`do_install_cmap'
atyfb_base.c: In function `atyfb_ioctl':
atyfb_base.c:1258: `info2' undeclared (first use in this function)
atyfb_base.c:1258: (Each undeclared identifier is reported only once
atyfb_base.c:1258: for each function it appears in.)
atyfb_base.c:1253: warning: `disp' might be used uninitialized in this
function
atyfb_base.c: In function `atyfb_save_palette':
atyfb_base.c:1447: warning: passing arg 2 of `aty_ld_8' from incompatible
pointer type
atyfb_base.c:1448: `par' undeclared (first use in this function)
atyfb_base.c:1450: warning: passing arg 3 of `aty_st_8' from incompatible
pointer type
atyfb_base.c:1451: warning: passing arg 3 of `aty_st_8' from incompatible
pointer type
atyfb_base.c: In function `atyfb_init':
atyfb_base.c:2204: parse error before `struct'
atyfb_base.c:2231: `default_par' undeclared (first use in this function)
atyfb_base.c:2261: `par' undeclared (first use in this function)
atyfb_base.c:2268: warning: assignment makes pointer from integer without a
cast
atyfb_base.c:2364: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2366: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2388: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2392: warning: passing arg 3 of `aty_st_le32' from incompatible
pointer type
atyfb_base.c:2434: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2437: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2439: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2442: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2444: warning: passing arg 2 of `aty_ld_le32' from incompatible
pointer type
atyfb_base.c:2455: warning: passing arg 2 of `aty_ld_8' from incompatible
pointer type
atyfb_base.c:2458: warning: passing arg 2 of `aty_ld_pll' from incompatible
pointer type
atyfb_base.c:2560: invalid operands to binary &
atyfb_base.c: At top level:
atyfb_base.c:136: warning: `atyfb_fix' defined but not used
make[3]: *** [atyfb_base.o] Error 1
make[3]: Leaving directory `/home/bruce/sparctest/drivers/video/aty'
make[2]: *** [aty] Error 2
make[2]: Leaving directory `/home/bruce/sparctest/drivers/video'
make[1]: *** [video] Error 2
make[1]: Leaving directory `/home/bruce/sparctest/drivers'
make: *** [drivers] Error 2


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

Re: 2.5 atyfb on Sparc question

[James Simmons]

> Quick question..  I was wondering if there is still
> a bk tree for fbdev
> work, or are you pushing direct to Linus?
> 
> I am getting the following errors when compiling on
> a sparc64 machine from
> the latest BK 2.5 tree, and was wondering if a fix
> may already be around.  I
> am not subscribed to this list, but a quick search
> didn't turn up anything.
> Thanks in advance..

Yes. I received a fix. I added to my BK repository but
I need to work on the driver a little bit more before
I push stuff. The next set of patches will break alot
of drivers but I need to do this to get people to port
there stuff over to the new api.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


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

Re: 2.5 atyfb on Sparc question

[Petr Vandrovec]

On  7 Aug 02 at 10:43, Jani Monoses wrote:
> On Tue, 6 Aug 2002 09:06:48 -0700 (PDT)
> James Simmons <captain_delete@yahoo.com> wrote:
> > I push stuff. The next set of patches will break alot
> > of drivers but I need to do this to get people to port
> > there stuff over to the new api.
> 
> Could you outline what the next set of patches will change?
> Thanks

I also hope that performance problems will be solved before we are
forced to not use putcs.
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz


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

Re: 2.5 atyfb on Sparc question

[Jani Monoses]

On Tue, 6 Aug 2002 09:06:48 -0700 (PDT)
James Simmons <captain_delete@yahoo.com> wrote:
> I push stuff. The next set of patches will break alot
> of drivers but I need to do this to get people to port
> there stuff over to the new api.

Could you outline what the next set of patches will change?
Thanks
Jani.


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

Re: 2.5 atyfb on Sparc question

[James Simmons]

> I also hope that performance problems will be solved
> before we are
> forced to not use putcs.

It will be :-) I need to one align the data. Second I
plan to implement the patch recently posted here. 

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


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

Re: 2.5 atyfb on Sparc question

[James Simmons]

> > > I push stuff. The next set of patches will break
> > alot
> > > of drivers but I need to do this to get people to
> > port
> > > there stuff over to the new api.
> >
> > Could you outline what the next set of patches will
> > change?

Oops. The next patch will remove get_fix and get_var. Also the internal
fbdev code will begin using the var and fix feilds in struct fb_info.




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

Re: 2.5 atyfb on Sparc question

[James Simmons]

--- Jani Monoses <jani@iv.ro> wrote:
> On Tue, 6 Aug 2002 09:06:48 -0700 (PDT)
> James Simmons <captain_delete@yahoo.com> wrote:
> > I push stuff. The next set of patches will break
> alot
> > of drivers but I need to do this to get people to
> port
> > there stuff over to the new api.
> 
> Could you outline what the next set of patches will
> change?
> Thanks
> Jani.

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


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

Re: 2.5 atyfb on Sparc question

[Petr Vandrovec]

On  8 Aug 02 at 11:16, James Simmons wrote:
> > I also hope that performance problems will be solved
> > before we are
> > forced to not use putcs.
> 
> It will be :-) I need to one align the data. Second I
> plan to implement the patch recently posted here. 

Patch still showed about 100% slowdown against 2.4.x, if I interpreted
yesterday's table correctly. It is better than 1000% slowdown, but still...
                                                Petr
                                                


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

Re: 2.5 atyfb on Sparc question

[James Simmons]

> On  8 Aug 02 at 11:16, James Simmons wrote:
> > > I also hope that performance problems will be solved
> > > before we are
> > > forced to not use putcs.
> >
> > It will be :-) I need to one align the data. Second I
> > plan to implement the patch recently posted here.
>
> Patch still showed about 100% slowdown against 2.4.x, if I interpreted
> yesterday's table correctly. It is better than 1000% slowdown, but still...

I could believe a slow down of 2x but 1000 I don't think so.




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

Re: 2.5 atyfb on Sparc question

[Petr Vandrovec]

On  8 Aug 02 at 11:32, James Simmons wrote:
> > On  8 Aug 02 at 11:16, James Simmons wrote:
> > > > I also hope that performance problems will be solved
> > > > before we are
> > > > forced to not use putcs.
> > >
> > > It will be :-) I need to one align the data. Second I
> > > plan to implement the patch recently posted here.
> >
> > Patch still showed about 100% slowdown against 2.4.x, if I interpreted
> > yesterday's table correctly. It is better than 1000% slowdown, but still...
> 
> I could believe a slow down of 2x but 1000 I don't think so.

Message from Antonio Daplas
(http://www.geocrawler.com/lists/3/SourceForge/9276/0/9249087/)
says:
2.5 old (with offscreen buffers) 10.708
2.5 new                           4.378
2.4                               2.098

His first message 
(http://www.geocrawler.com/lists/3/SourceForge/9276/25/9237029/)
listed 13.586 for old 2.5 code.

So you are right, old code was not 1000% slowdown, only 500%. But main
problem is not speed of old code, but speed of new code. And if numbers
are right, new code is still 100% slower than 2.4.x code was.
                                                Petr Vandrovec
                                                


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

Re: 2.5 atyfb on Sparc question

[Antonino Daplas]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

On Fri, 2002-08-09 at 02:51, Petr Vandrovec wrote:

> 
> Message from Antonio Daplas
> (http://www.geocrawler.com/lists/3/SourceForge/9276/0/9249087/)
> says:
> 2.5 old (with offscreen buffers) 10.708
> 2.5 new                           4.378
> 2.4                               2.098
> 
> His first message 
> (http://www.geocrawler.com/lists/3/SourceForge/9276/25/9237029/)
> listed 13.586 for old 2.5 code.
> 
> So you are right, old code was not 1000% slowdown, only 500%. But main
> problem is not speed of old code, but speed of new code. And if numbers
> are right, new code is still 100% slower than 2.4.x code was.
>                                                 Petr Vandrovec

The numbers are correct. However I'm only talking about software drawing
here.  With a few more optimizations with the code, the scroll time was
further cut down to 3.780s.  Also, 16bpp and 32bpp is now faster in 2.5
than in 2.4, although 24bpp is still a bit slower because of problems of
its weird alignmment.

However, ALL hardware accelerated code is much faster than the old one,
and will be much, much faster if hardware sync on demand is implemented.
(I really want this James :)

The extra processing of the font bitmap in putcs() outweighs the benefit
of "bulk" writing the data in 8bpp, but becomes insignificant as we go
to higher color depths, or as we take advantage of hardware
acceleration.

I'm attaching diffs for cfbimgblt.c, cfbfillrect.c, cfbcopyarea.c and
fbcon-accel.c.  This is against vanilla 2.5.27.

fbcon-accel.c:  
	process 4 characters at a time, if possible, to squeeze a few more CPU
cycles

cfbimgblt.c
	divided into fast_imageblit (for 8, 16, 32 bpp), slow_imageblit (24
bpp) and bitwise_imageblit (default).  

slow_imageblit involves packaging 4 pixels (or 8 if we have color depths
> 32) which are written as double words (1 - 8bpp, 2 - 16bpp, 3 -
24bpp).

cfbcopyarea.c
	uses fast_memmove and fb_memmove for 24 bpp.  Anthing wrong with this
fb string functions?  I seem not to see any performance degradation by
using them.

cfbfillarea.c
	Similar concept as slow_imageblit, packages 4-pixels in 24 bpp that are
written as 3 double words to the framebuffer.


	Also is the double word access alignment a strict or optional
requirement? 

Any comments?

Tony 



[-- Attachment #2: fb-opt.diff --]
[-- Type: text/x-patch, Size: 18389 bytes --]

diff -Naur linux-2.5.27/drivers/video/cfbcopyarea.c linux/drivers/video/cfbcopyarea.c
--- linux-2.5.27/drivers/video/cfbcopyarea.c	Thu Aug  8 21:42:21 2002
+++ linux/drivers/video/cfbcopyarea.c	Thu Aug  8 21:42:54 2002
@@ -83,7 +83,7 @@
 		lineincr = -linesize;
 	}
 
-	if ((BITS_PER_LONG % p->var.bits_per_pixel) == 0) {
+	if ((BITS_PER_LONG % p->var.bits_per_pixel) == 0) {   
 		int ppw = BITS_PER_LONG / p->var.bits_per_pixel;
 		int n = ((area->width * p->var.bits_per_pixel) >> 3);
 
@@ -103,7 +103,6 @@
 			n -= end_index;
 		}
 		n /= bpl;
-
 		if (n <= 0) {
 			if (start_mask) {
 				if (end_mask)
@@ -219,4 +218,32 @@
 			}
 		}
 	}
+	else {
+		int n = ((area->width * p->var.bits_per_pixel) >> 3);
+		int n16 = (n >> 4) << 4;
+		int n_fract = n - n16;
+		int rows;
+
+		if (area->dy < area->sy
+		    || (area->dy == area->sy && area->dx < area->sx)) {
+			for (rows = height; rows--; ) {
+				if (n16)
+					fast_memmove(dst1, src1, n16);
+				if (n_fract)
+					fb_memmove(dst1+n16, src1+n16, n_fract);
+				dst1 += linesize;
+				src1 += linesize;
+			}
+		}
+		else {
+			for (rows = height; rows--; ) {
+				if (n16)
+					fast_memmove(dst1, src1, n16);
+				if (n_fract)
+					fb_memmove(dst1+n16, src1+n16, n_fract);
+				dst1 -= linesize;
+				src1 -= linesize;
+			}
+		}
+	}			
 }
diff -Naur linux-2.5.27/drivers/video/cfbfillrect.c linux/drivers/video/cfbfillrect.c
--- linux-2.5.27/drivers/video/cfbfillrect.c	Thu Aug  8 21:42:26 2002
+++ linux/drivers/video/cfbfillrect.c	Thu Aug  8 21:42:50 2002
@@ -28,7 +28,7 @@
 	unsigned long height, ppw, fg, fgcolor;
 	int i, n, x2, y2, linesize = p->fix.line_length;
 	int bpl = sizeof(unsigned long);
-	unsigned long *dst;
+	unsigned long *dst = NULL;
 	char *dst1;
 
 	if (!rect->width || !rect->height)
@@ -57,7 +57,7 @@
 	else
 		fg = fgcolor = rect->color;
 
-	for (i = 0; i < ppw - 1; i++) {
+	for (i = 0; i < ppw-1; i++) {
 		fg <<= p->var.bits_per_pixel;
 		fg |= fgcolor;
 	}
@@ -85,7 +85,7 @@
 		n = 0;
 	}
 
-	if ((BITS_PER_LONG % p->var.bits_per_pixel) == 0) {
+	if ((BITS_PER_LONG % p->var.bits_per_pixel) == 0) { 
 		switch (rect->rop) {
 		case ROP_COPY:
 			do {
@@ -161,49 +161,76 @@
 			break;
 		}
 	} else {
-		/* Odd modes like 24 or 80 bits per pixel */
-		start_mask = fg >> (start_index * p->var.bits_per_pixel);
-		end_mask = fg << (end_index * p->var.bits_per_pixel);
-		/* start_mask =& PFILL24(x1,fg);
-		   end_mask_or = end_mask & PFILL24(x1+width-1,fg); */
-
-		n = (rect->width - start_index - end_index) / ppw;
+		/* 
+		 * Slow Method:  The aim is to find the number of pixels to
+		 * pack in order to write doubleword multiple data.
+		 * For 24 bpp, 4 pixels are packed which are written as 
+		 * 3 dwords.
+		 */
+		char *dst2, *dst3;
+		int bytes = (p->var.bits_per_pixel + 7) >> 3;
+		int read, write, total, pack_size;
+		u32 pixarray[BITS_PER_LONG >> 3], m;
+		
+		fg = fgcolor;
+		read = (bytes + (bpl - 1)) & ~(bpl - 1); 
+		write = bytes;
+		total = (rect->width * bytes);
+			
+		pack_size = bpl * write;
+
+		dst3 = (char *) pixarray;
+
+		for (n = read; n--; ) {
+			*(u32 *) dst3 = fg;
+			dst3 += bytes;
+		}
 
 		switch (rect->rop) {
 		case ROP_COPY:
 			do {
-				dst = (unsigned long *) dst1;
-				if (start_mask)
-					*dst |= start_mask;
-				if ((start_index + rect->width) > ppw)
-					dst++;
+				dst2 = dst1;
+				n = total;
 
-				/* XXX: slow */
-				for (i = 0; i < n; i++) {
-					*dst++ = fg;
+				while (n >= pack_size) {
+					for (m = 0; m < write; m++) {
+						fb_writel(pixarray[m], (u32 *) dst2);
+						dst2 += 4;
+					}
+					n -= pack_size;
+				}
+				if (n) {
+					m = 0;
+					while (n--) 
+						fb_writeb(((u8 *)pixarray)[m++], dst2++);
 				}
-				if (end_mask)
-					*dst |= end_mask;
 				dst1 += linesize;
 			} while (--height);
 			break;
 		case ROP_XOR:
 			do {
-				dst = (unsigned long *) dst1;
-				if (start_mask)
-					*dst ^= start_mask;
-				if ((start_mask + rect->width) > ppw)
-					dst++;
+				dst2 = dst1;
+				n = total;
 
-				for (i = 0; i < n; i++) {
-					*dst++ ^= fg;	/* PFILL24(fg,x1+i); */
+				while (n >= pack_size) {
+					for (m = 0; m < write; m++) {
+						fb_writel(fb_readl((u32 *) dst2) ^ pixarray[m], (u32 *) dst2);
+						dst2 += 4;
+					}
+					n -= pack_size;
+				}
+				if (n) {
+					m = 0;
+					while (n--) {
+						fb_writeb(fb_readb(dst2) ^ ((u8 *)pixarray)[m++], dst2);
+						dst2++;
+					}
 				}
-				if (end_mask)
-					*dst ^= end_mask;
 				dst1 += linesize;
 			} while (--height);
 			break;
 		}
+			
 	}
 	return;
 }
diff -Naur linux-2.5.27/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.27/drivers/video/cfbimgblt.c	Thu Aug  8 21:42:17 2002
+++ linux/drivers/video/cfbimgblt.c	Thu Aug  8 21:42:42 2002
@@ -22,6 +22,13 @@
  *  FIXME
  *  The code for 24 bit is horrible. It copies byte by byte size instead of
  *  longs like the other sizes. Needs to be optimized.
+ *  
+ *  Tony: 
+ *  Incorporate mask tables similar to fbcon-cfb*.c in 2.4 API.  This speeds 
+ *  up the code significantly.
+ *  
+ *  Code for depths not multiples of BITS_PER_LONG is still kludgy, which is
+ *  still processed a bit at a time.   
  *
  *  Also need to add code to deal with cards endians that are different than
  *  the native cpu endians. I also need to deal with MSB position in the word.
@@ -41,16 +48,222 @@
 #define DPRINTK(fmt, args...)
 #endif
 
-void cfb_imageblit(struct fb_info *p, struct fb_image *image)
+static u32 cfb_tab8[] = {
+#if defined(__BIG_ENDIAN)
+    0x00000000,0x000000ff,0x0000ff00,0x0000ffff,
+    0x00ff0000,0x00ff00ff,0x00ffff00,0x00ffffff,
+    0xff000000,0xff0000ff,0xff00ff00,0xff00ffff,
+    0xffff0000,0xffff00ff,0xffffff00,0xffffffff
+#elif defined(__LITTLE_ENDIAN)
+    0x00000000,0xff000000,0x00ff0000,0xffff0000,
+    0x0000ff00,0xff00ff00,0x00ffff00,0xffffff00,
+    0x000000ff,0xff0000ff,0x00ff00ff,0xffff00ff,
+    0x0000ffff,0xff00ffff,0x00ffffff,0xffffffff
+#else
+#error FIXME: No endianness??
+#endif
+};
+
+static u32 cfb_tab16[] = {
+#if defined(__BIG_ENDIAN)
+    0x00000000, 0x0000ffff, 0xffff0000, 0xffffffff
+#elif defined(__LITTLE_ENDIAN)
+    0x00000000, 0xffff0000, 0x0000ffff, 0xffffffff
+#else
+#error FIXME: No endianness??
+#endif
+};
+
+static u32 cfb_tab32[] = {
+	0x00000000, 0xffffffff
+};
+
+static u32 cfb_pixarray[4];
+static u32 cfb_tabdef[2];
+
+
+static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, char *dst1, 
+				  int fgcolor, int bgcolor) 
 {
-	int pad, ppw;
-	int x2, y2, n, i, j, k, l = 7;
+	int i, j, k, l = 8, n;
+	int bit_mask, end_mask, eorx; 
+	unsigned long fgx = fgcolor, bgx = bgcolor, pad;
 	unsigned long tmp = ~0 << (BITS_PER_LONG - p->var.bits_per_pixel);
-	unsigned long fgx, bgx, fgcolor, bgcolor, eorx;	
+	unsigned long ppw = BITS_PER_LONG/p->var.bits_per_pixel;
+	unsigned long *dst;
+	u32 *tab = NULL;
+	char *src = image->data;
+		
+	switch (ppw) {
+	case 4:
+		tab = cfb_tab8;
+		break;
+	case 2:
+		tab = cfb_tab16;
+		break;
+	case 1:
+		tab = cfb_tab32;
+		break;
+	}
+
+	for (i = ppw-1; i--; ) {
+		fgx <<= p->var.bits_per_pixel;
+		bgx <<= p->var.bits_per_pixel;
+		fgx |= fgcolor;
+		bgx |= bgcolor;
+	}
+	
+	n = ((image->width + 7) >> 3);
+	pad = (n << 3) - image->width;
+	n = image->width % ppw;
+	
+	bit_mask = (1 << ppw) - 1;
+	eorx = fgx ^ bgx;
+
+	k = image->width/ppw;
+
+	for (i = image->height; i--; ) {
+		dst = (unsigned long *) dst1;
+		
+		for (j = k; j--; ) {
+			l -= ppw;
+			end_mask = tab[(*src >> l) & bit_mask]; 
+			fb_writel((end_mask & eorx)^bgx, dst++);
+			if (!l) { l = 8; src++; }
+		}
+		if (n) {
+			end_mask = 0;	
+			for (j = n; j > 0; j--) {
+				l--;
+				if (test_bit(l, (unsigned long *) src))
+					end_mask |= (tmp >> (p->var.bits_per_pixel*(j-1)));
+				if (!l) { l = 8; src++; }
+			}
+			fb_writel((end_mask & eorx)^bgx, dst++);
+		}
+		l -= pad;		
+		dst1 += p->fix.line_length;	
+	}
+}	
+	
+
+/*
+ * Slow method:  The idea is to find the number of pixels necessary to form
+ * dword-sized multiples that will be written to the framebuffer.  For BPP24, 
+ * 4 pixels has to be read which are then packed into 3 double words that 
+ * are then written to the framebuffer.
+ * 
+ * With this method, processing is done 1 pixel at a time.
+ */
+static inline void slow_imageblit(struct fb_image *image, struct fb_info *p, char * dst1,
+				  int fgcolor, int bgcolor)
+{
+	int bytes = (p->var.bits_per_pixel + 7) >> 3;
+	int tmp = ~0UL >> (BITS_PER_LONG - p->var.bits_per_pixel);
+	int i, j, k, l = 8, m, end_mask, eorx;
+	int read, write, total, pack_size, bpl = sizeof(unsigned long);
+	unsigned long *dst;
+	char *dst2 = (char *) cfb_pixarray, *src = image->data;
+
+	cfb_tabdef[0] = 0;
+	cfb_tabdef[1] = tmp;
+	
+	eorx = fgcolor ^ bgcolor;
+	read = (bytes + (bpl - 1)) & ~(bpl - 1);
+	write = bytes;
+	total = image->width * bytes;
+	pack_size = bpl * write;
+	
+	for (i = image->height; i--; ) {
+		dst = (unsigned long *) dst1;
+		j = total;
+		m = read;
+		
+		while (j >= pack_size) {
+			l--; m--;
+			end_mask = cfb_tabdef[(*src >> l) & 1]; 
+			*(unsigned long *) dst2 = (end_mask & eorx)^bgcolor;
+			dst2 += bytes;
+			if (!m) {
+				for (k = 0; k < write; k++ ) 
+					fb_writel(cfb_pixarray[k], dst++);
+				dst2 = (char *) cfb_pixarray;
+				j -= pack_size;
+				m = read;
+			}
+			if (!l) { l = 8; src++; }
+		}
+		/* write residual pixels */
+		if (j) {
+			k = 0;
+			while (j--)
+				fb_writeb(((u8 *) cfb_pixarray)[k++], dst++);
+		}
+		dst1 += p->fix.line_length;	
+	}
+}
+
+static inline void bitwise_blit(struct fb_image *image, struct fb_info *p, char *dst1,
+				int fgcolor, int bgcolor)
+{
+	int i, j, k, l = 8, n, pad, ppw;
+	unsigned long tmp = ~0 << (BITS_PER_LONG - p->var.bits_per_pixel);
+	unsigned long fgx = fgcolor, bgx = bgcolor, eorx;
 	unsigned long end_mask;
 	unsigned long *dst = NULL;
+	char *src = image->data;
+
+	ppw = BITS_PER_LONG/p->var.bits_per_pixel;
+
+	for (i = 0; i < ppw-1; i++) {
+		fgx <<= p->var.bits_per_pixel;
+		bgx <<= p->var.bits_per_pixel;
+		fgx |= fgcolor;
+		bgx |= bgcolor;
+	}
+	eorx = fgx ^ bgx;
+	n = ((image->width + 7) >> 3);
+	pad = (n << 3) - image->width;
+	n = image->width % ppw;
+
+	for (i = 0; i < image->height; i++) {
+		dst = (unsigned long *) dst1;
+		
+		for (j = image->width/ppw; j > 0; j--) {
+			end_mask = 0;
+			
+			for (k = ppw; k > 0; k--) {
+				l--;
+				if (test_bit(l, (unsigned long *) src))
+					end_mask |= (tmp >> (p->var.bits_per_pixel*(k-1)));
+				if (!l) { l = 8; src++; }
+			}
+			fb_writel((end_mask & eorx)^bgx, dst);
+			dst++;
+		}
+		
+		if (n) {
+			end_mask = 0;	
+			for (j = n; j > 0; j--) {
+				l--;
+				if (test_bit(l, (unsigned long *) src))
+					end_mask |= (tmp >> (p->var.bits_per_pixel*(j-1)));
+				if (!l) { l = 8; src++; }
+			}
+			fb_writel((end_mask & eorx)^bgx, dst);
+			dst++;
+		}
+		l -= pad;		
+		dst1 += p->fix.line_length;	
+	}	
+}
+
+void cfb_imageblit(struct fb_info *p, struct fb_image *image)
+{
+	int x2, y2, n;
+	unsigned long fgcolor, bgcolor;	
+	unsigned long end_mask;
 	u8 *dst1;
-	u8 *src;
 
 	/* 
 	 * We could use hardware clipping but on many cards you get around hardware
@@ -64,66 +277,32 @@
 	y2 = y2 < p->var.yres_virtual ? y2 : p->var.yres_virtual;
 	image->width  = x2 - image->dx;
 	image->height = y2 - image->dy;
-  
+
 	dst1 = p->screen_base + image->dy * p->fix.line_length + 
 		((image->dx * p->var.bits_per_pixel) >> 3);
   
-	ppw = BITS_PER_LONG/p->var.bits_per_pixel;
-
-	src = image->data;	
-
 	if (image->depth == 1) {
-
 		if (p->fix.visual == FB_VISUAL_TRUECOLOR) {
-			fgx = fgcolor = ((u32 *)(p->pseudo_palette))[image->fg_color];
-			bgx = bgcolor = ((u32 *)(p->pseudo_palette))[image->bg_color];
+			fgcolor = ((u32 *)(p->pseudo_palette))[image->fg_color];
+			bgcolor = ((u32 *)(p->pseudo_palette))[image->bg_color];
 		} else {
-			fgx = fgcolor = image->fg_color;
-			bgx = bgcolor = image->bg_color;
+			fgcolor = image->fg_color;
+			bgcolor = image->bg_color;
 		}	
  
-		for (i = 0; i < ppw-1; i++) {
-			fgx <<= p->var.bits_per_pixel;
-			bgx <<= p->var.bits_per_pixel;
-			fgx |= fgcolor;
-			bgx |= bgcolor;
-		}
-		eorx = fgx ^ bgx;
-		n = ((image->width + 7) >> 3);
-		pad = (n << 3) - image->width;
-		n = image->width % ppw;
-
-		for (i = 0; i < image->height; i++) {
-			dst = (unsigned long *) dst1;
-		
-			for (j = image->width/ppw; j > 0; j--) {
-				end_mask = 0;
-		
-				for (k = ppw; k > 0; k--) {
-					if (test_bit(l, (unsigned long *) src))
-						end_mask |= (tmp >> (p->var.bits_per_pixel*(k-1)));
-					l--;
-					if (l < 0) { l = 7; src++; }
-				}
-				fb_writel((end_mask & eorx)^bgx, dst);
-				dst++;
-			}
+		if (p->var.bits_per_pixel >= 8)  {
+			if (BITS_PER_LONG % p->var.bits_per_pixel == 0) 
+				fast_imageblit(image, p, dst1, fgcolor, bgcolor);
+			else 
+				slow_imageblit(image, p, dst1, fgcolor, bgcolor);
+		}
+		else 
+			/* Is there such a thing as 3 or 5 bits per pixel? */
+			slow_imageblit(image, p, dst1, fgcolor, bgcolor);
 		
-			if (n) {
-				end_mask = 0;	
-				for (j = n; j > 0; j--) {
-					if (test_bit(l, (unsigned long *) src))
-						end_mask |= (tmp >> (p->var.bits_per_pixel*(j-1)));
-					l--;
-					if (l < 0) { l = 7; src++; }
-				}
-				fb_writel((end_mask & eorx)^bgx, dst);
-				dst++;
-			}
-			l -= pad;		
-			dst1 += p->fix.line_length;	
-		}	
-	} else {
+	}
+	
+	else {
 		/* Draw the penguin */
 		n = ((image->width * p->var.bits_per_pixel) >> 3);
 		end_mask = 0;
diff -Naur linux-2.5.27/drivers/video/fbcon-accel.c linux/drivers/video/fbcon-accel.c
--- linux-2.5.27/drivers/video/fbcon-accel.c	Thu Aug  8 21:42:11 2002
+++ linux/drivers/video/fbcon-accel.c	Thu Aug  8 21:43:00 2002
@@ -70,9 +70,44 @@
 	image.width = fontwidth(p);
 	image.height = fontheight(p);
 	image.depth = 1;
-	image.data = p->fontdata + (c & charmask)*fontheight(p)*width;
+	if (!info->pixmap.addr) {
+		image.data = p->fontdata + (c & charmask)*fontheight(p) * width;
+		info->fbops->fb_imageblit(info, &image);
+	}
+	else {
+		unsigned int d_size, d_pitch, i, j; 
+		unsigned int scan_align = (info->pixmap.scan_align) ? info->pixmap.scan_align - 1 : 0;
+		unsigned int buf_align = (info->pixmap.buf_align) ? info->pixmap.buf_align - 1 : 0;
+		char *d_addr, *s_addr;
+
+		d_pitch = (width + scan_align) & ~scan_align;
+		d_size = d_pitch * image.height;
+
+		if (d_size > info->pixmap.size) {
+			BUG();
+			return;
+		}
+		
+		info->pixmap.offset = (info->pixmap.offset + buf_align) & ~buf_align;
+
+		if (info->pixmap.offset + d_size > info->pixmap.size) {
+			if (info->fbops->fb_sync) 
+				info->fbops->fb_sync(info);
+			info->pixmap.offset = 0;
+		}
+		s_addr = p->fontdata + (c & charmask)*fontheight(p)*width;
+		image.data = (char *) (info->pixmap.addr + info->pixmap.offset);
+		d_addr = image.data;
 
-	info->fbops->fb_imageblit(info, &image);
+		for (i = image.height; i--; ) {
+			for (j = 0; j < width; j++) 
+				d_addr[j] = *s_addr++;
+			d_addr += d_pitch;
+		}
+
+		info->fbops->fb_imageblit(info, &image);
+		info->pixmap.offset += d_size;
+	}
 }
 
 void fbcon_accel_putcs(struct vc_data *vc, struct display *p,
@@ -81,21 +116,87 @@
 	struct fb_info *info = p->fb_info;
 	unsigned short charmask = p->charmask;
 	unsigned int width = ((fontwidth(p)+7)>>3);
+	unsigned int cell_size;
 	struct fb_image image;
 
 	image.fg_color = attr_fgcol(p, *s);
 	image.bg_color = attr_bgcol(p, *s);
 	image.dx = xx * fontwidth(p);
 	image.dy = yy * fontheight(p);
-	image.width = fontwidth(p);
 	image.height = fontheight(p);
 	image.depth = 1;
+	cell_size = fontheight(p)*width;
+	if (!info->pixmap.addr) {
+		image.width = fontwidth(p);
+		while (count--) {
+			image.data = p->fontdata + (scr_readw(s++) & charmask) * cell_size;
+			info->fbops->fb_imageblit(info, &image);
+			image.dx += fontwidth(p);
+		}
+	}
+	else {
+		unsigned int d_pitch, d_size, i, j; 
+		unsigned int scan_align = (info->pixmap.scan_align) ? info->pixmap.scan_align - 1 : 0;
+		unsigned int buf_align = (info->pixmap.buf_align) ? info->pixmap.buf_align - 1 : 0;
+		char *s_addr, *d_addr, *d_addr0;
+
+		d_pitch = (width * count) + scan_align;
+		d_pitch &= ~scan_align;
+		d_size = d_pitch * image.height;
+
+		if (d_size > info->pixmap.size) {
+			BUG();
+			return;
+		}
+
+		info->pixmap.offset = (info->pixmap.offset + buf_align) & ~buf_align;
+
+		if (info->pixmap.offset + d_size > info->pixmap.size) { 
+			if (info->fbops->fb_sync)
+				info->fbops->fb_sync(info);
+			info->pixmap.offset = 0;
+		}
+
+		image.width = fontwidth(p) * count;
+		image.data = (char *) (info->pixmap.addr + info->pixmap.offset);
+		d_addr = image.data;
+
+		if (width == 1 && count > 3) {
+			char *s1, *s2, *s3, *s4;
+
+			while (count > 3) {
+				s1 = p->fontdata + (scr_readw(s++) & charmask) * cell_size;
+				s2 = p->fontdata + (scr_readw(s++) & charmask) * cell_size;
+				s3 = p->fontdata + (scr_readw(s++) & charmask) * cell_size;
+				s4 = p->fontdata + (scr_readw(s++) & charmask) * cell_size;
+				d_addr0 = d_addr;
+
+				for (i = image.height; i--; ) {
+					*(unsigned long *) d_addr0 = 
+						(unsigned long) ((*s1++ & 0xff)       |
+								 (*s2++ & 0xff) << 8  |
+								 (*s3++ & 0xff) << 16 |
+								 (*s4++ & 0xff) << 24   );
+					d_addr0 += d_pitch;
+				}
+				count -= 4;
+				d_addr += 4;
+			}
+		}
+
+		while (count--) {
+			s_addr = p->fontdata + (scr_readw(s++) & charmask) * cell_size;
+			d_addr0 = d_addr;
 
-	while (count--) {
-		image.data = p->fontdata +
-			(scr_readw(s++) & charmask) * fontheight(p) * width;
+			for (i = image.height; i--; ) {
+				for (j = 0; j < width; j++)
+					d_addr0[j] = *s_addr++;
+				d_addr0 += d_pitch;
+			}
+			d_addr += width;
+		}
 		info->fbops->fb_imageblit(info, &image);
-		image.dx += fontwidth(p);
+		info->pixmap.offset += d_size;
 	}
 }
 

Re: 2.5 atyfb on Sparc question

[Jani Monoses]

On Thu, 8 Aug 2002 11:19:46 -0700 (PDT)
James Simmons <jsimmons@infradead.org> wrote:

> Oops. The next patch will remove get_fix and get_var. Also the internal
> fbdev code will begin using the var and fix feilds in struct fb_info.
Is there a place (ruby tree ???) where this stuff can be seen before it goes to Linus?
I want to port my driver and would be nice to see how the final fb core looks like...
Jani.


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

Re: 2.5 atyfb on Sparc question

[James Simmons]

> > Oops. The next patch will remove get_fix and get_var. Also the internal
> > fbdev code will begin using the var and fix feilds in struct fb_info.
> Is there a place (ruby tree ???) where this stuff can be seen before it goes to Linus?

http://fbdev.bkbits.net:8080/fbdev-2.5

> I want to port my driver and would be nice to see how the final fb core looks like...
> Jani.





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

RE: 2.5 atyfb on Sparc question

[Holzrichter, Bruce]

> 
> http://fbdev.bkbits.net:8080/fbdev-2.5
> 

Closer, closer....

Here's an FYI.  I haven't looked into it any further yet...

B.

make[3]: Entering directory `/home/bruce/sparctest/drivers/video/aty'
  sparc64-linux-gcc -Wp,-MD,./.atyfb_base.o.d -D__KERNEL__
-I/home/bruce/sparctest/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2
-fomit-frame-pointer -fno-strict-aliasing -fno-common -m64 -pipe -mno-fpu
-mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7
-Wno-sign-compare -Wa,--undeclared-regs -nostdinc -iwithprefix include
-DKBUILD_BASENAME=atyfb_base   -c -o atyfb_base.o atyfb_base.c
atyfb_base.c: In function `atyfb_ioctl':
atyfb_base.c:1075: `info2' undeclared (first use in this function)
atyfb_base.c:1075: (Each undeclared identifier is reported only once
atyfb_base.c:1075: for each function it appears in.)
atyfb_base.c:1070: warning: `disp' might be used uninitialized in this
function
atyfb_base.c: In function `atyfb_init':
atyfb_base.c:2086: warning: assignment makes pointer from integer without a
cast
atyfb_base.c:2184: `defualt_par' undeclared (first use in this function)
atyfb_base.c:2376: invalid operands to binary &
make[3]: *** [atyfb_base.o] Error 1
make[3]: Leaving directory `/home/bruce/sparctest/drivers/video/aty'
make[2]: *** [aty] Error 2
make[2]: Leaving directory `/home/bruce/sparctest/drivers/video'
make[1]: *** [video] Error 2
make[1]: Leaving directory `/home/bruce/sparctest/drivers'
make: *** [drivers] Error 2


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

RE: 2.5 atyfb on Sparc question

[James Simmons]

> > http://fbdev.bkbits.net:8080/fbdev-2.5
> >
>
> Closer, closer....
>
> Here's an FYI.  I haven't looked into it any further yet...

Try it again. I pushed some fixes.



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

RE: 2.5 atyfb on Sparc question

[Holzrichter, Bruce]

> 
> Try it again. I pushed some fixes.
> 

Here's a simple one liner fix, pretty self explanatory, if you haven't
caught it yet.  ;o)

--- atyfb_base.c.old    Mon Aug 12 11:34:44 2002
+++ atyfb_base.c        Mon Aug 12 10:57:11 2002
@@ -2241,7 +2241,7 @@
                                    aty_ld_le32(CRTC_H_TOTAL_DISP,
default_par);
                                crtc.h_sync_strt_wid =
                                    aty_ld_le32(CRTC_H_SYNC_STRT_WID,
-                                               defualt_par);
+                                               default_par);
                                crtc.v_tot_disp =
                                    aty_ld_le32(CRTC_V_TOTAL_DISP,
default_par);
                                crtc.v_sync_strt_wid =

Now looking to track this one down.  Haven't found it yet....

  ld -m elf64_sparc -T arch/sparc64/vmlinux.lds arch/sparc64/kernel/head.o
arch/sparc64/kernel/init_task.o init/init.o --start-group
arch/sparc64/kernel/kernel.o arch/sparc64/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o security/built-in.o arch/sparc64/math-emu/math-emu.o
/home/bruce/sparctest/lib/lib.a lib/lib.a
/home/bruce/sparctest/arch/sparc64/prom/promlib.a
/home/bruce/sparctest/arch/sparc64/lib/lib.a drivers/built-in.o
sound/sound.o net/network.o --end-group -o vmlinux
drivers/built-in.o: In function `console_init':
drivers/built-in.o(.text.init+0xa78): undefined reference to
`uart_console_init'
make: *** [vmlinux] Error 1

B.







-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

RE: 2.5 atyfb on Sparc question

[James Simmons]

> Here's a simple one liner fix, pretty self explanatory, if you haven't
> caught it yet.  ;o)

Oops. Fixed now.

> Now looking to track this one down.  Haven't found it yet....
>
>   ld -m elf64_sparc -T arch/sparc64/vmlinux.lds arch/sparc64/kernel/head.o
> arch/sparc64/kernel/init_task.o init/init.o --start-group
> arch/sparc64/kernel/kernel.o arch/sparc64/mm/mm.o kernel/kernel.o mm/mm.o
> fs/fs.o ipc/ipc.o security/built-in.o arch/sparc64/math-emu/math-emu.o
> /home/bruce/sparctest/lib/lib.a lib/lib.a
> /home/bruce/sparctest/arch/sparc64/prom/promlib.a
> /home/bruce/sparctest/arch/sparc64/lib/lib.a drivers/built-in.o
> sound/sound.o net/network.o --end-group -o vmlinux
> drivers/built-in.o: In function `console_init':
> drivers/built-in.o(.text.init+0xa78): undefined reference to
> `uart_console_init'

New serial tty code. Have no idea for the fix.



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

RE: 2.5 atyfb on Sparc question

[Holzrichter, Bruce]

> 
> Oops. Fixed now.
> 
Whoa, that was neat!  ;o)

Just an fyi from my last attempt.  Upon booting with FB enabled with the
changes, The screen was completely filled with blocks displayed on the
screen.  I could see in the background the display change as it tried to
print out the kern messages, but they just mangled the blocks on the screen.
It looked like a screen full of extended ascii character 222 and 223's..
:o)

However, due to other problems I am having with it, most likely still IDE
related, I can't give much more of a report than this....

B.


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

RE: 2.5 atyfb on Sparc question

[James Simmons]

> > Oops. Fixed now.
> >
> Whoa, that was neat!  ;o)

Can you try the latest changes in my BK tree.



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

RE: 2.5 atyfb on Sparc question

[Holzrichter, Bruce]

James,

In a blast from the past, not sure if your still interested, but I have not
had a whole lot of time to look at these, due to my job/life, etc,etc...

If I apply the latest bk to it, I get the following compile error.  As I
said, I haven't even had time to grep through the thing to even begin to
look, but wanted to report them anyways...

fbmem.c: In function `fbmem_read_proc':
fbmem.c:380: structure has no member named `modename'
make[2]: *** [fbmem.o] Error 1
make[2]: Leaving directory `/home/bruce/sparctest/drivers/video'
make[1]: *** [video] Error 2
make[1]: Leaving directory `/home/bruce/sparctest/drivers'
make: *** [drivers] Error 2

Bruce H..

> -----Original Message-----
> From: James Simmons [mailto:jsimmons@infradead.org]
> Sent: Thursday, August 22, 2002 3:22 PM
> To: Holzrichter, Bruce
> Cc: linux-fbdev-devel@lists.sourceforge.net
> Subject: RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question
> 
> 
> 
> > > Oops. Fixed now.
> > >
> > Whoa, that was neat!  ;o)
> 
> Can you try the latest changes in my BK tree.
> 


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

RE: 2.5 atyfb on Sparc question

[James Simmons]

Sorry I have been going threw alot of chabnges recently. Try my lastest
tree. I just updated it and I'm nearly done change the api.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@users.sf.net] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

On Thu, 3 Oct 2002, Holzrichter, Bruce wrote:

> James,
>
> In a blast from the past, not sure if your still interested, but I have not
> had a whole lot of time to look at these, due to my job/life, etc,etc...
>
> If I apply the latest bk to it, I get the following compile error.  As I
> said, I haven't even had time to grep through the thing to even begin to
> look, but wanted to report them anyways...
>
> fbmem.c: In function `fbmem_read_proc':
> fbmem.c:380: structure has no member named `modename'
> make[2]: *** [fbmem.o] Error 1
> make[2]: Leaving directory `/home/bruce/sparctest/drivers/video'
> make[1]: *** [video] Error 2
> make[1]: Leaving directory `/home/bruce/sparctest/drivers'
> make: *** [drivers] Error 2
>
> Bruce H..
>
> > -----Original Message-----
> > From: James Simmons [mailto:jsimmons@infradead.org]
> > Sent: Thursday, August 22, 2002 3:22 PM
> > To: Holzrichter, Bruce
> > Cc: linux-fbdev-devel@lists.sourceforge.net
> > Subject: RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question
> >
> >
> >
> > > > Oops. Fixed now.
> > > >
> > > Whoa, that was neat!  ;o)
> >
> > Can you try the latest changes in my BK tree.
> >
>



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

Re: 2.5 atyfb on Sparc question

[Sven LUTHER]

On Sun, Oct 13, 2002 at 01:08:08PM -0700, James Simmons wrote:
> 
> Sorry I have been going threw alot of chabnges recently. Try my lastest
> tree. I just updated it and I'm nearly done change the api.

BTW, i tried this WE to look at porting the pm3fb driver to the new API,
doing a complete rewrite (well, basically starting again from tridentff,
tdfxfb and skeletonfb, and getting the code as needed from current
pm3fb, which has a lot of unneeded stuff in it). I have not much time
though, so it will go slowly.

I thought i may as well write a little HOWTO or something such on the
way of doing this. Since i have not much fbdev writing experience, maybe
i am a good candidate for writing such a thing.

I wanted, in the first step, to do just a basic unaccelerated fbdev
driver, without mode changes and anything fancy, and once this works,
add things incrementally. I believe this approach will be good for
future fbdev driver writters.

Anyway, now for my question.

skeletonfb says that check_var, set_par, setcolreg, pan_display and
blank functions are optional or not required. Is that true, and in case
i don't want to provide them, whay do i put in the fb_ops structure ?

Later, in the fb_ops structure, only set_par, blank and pan_display are
labeled as optional.

Friendly,

Sven Luther


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

Re: 2.5 atyfb on Sparc question

[James Simmons]

> I thought i may as well write a little HOWTO or something such on the
> way of doing this. Since i have not much fbdev writing experience, maybe
> i am a good candidate for writing such a thing.

Wow that would be great.

> I wanted, in the first step, to do just a basic unaccelerated fbdev
> driver, without mode changes and anything fancy, and once this works,
> add things incrementally. I believe this approach will be good for
> future fbdev driver writters.

Good approach to doing this.

> Anyway, now for my question.
>
> skeletonfb says that check_var, set_par, setcolreg, pan_display and
> blank functions are optional or not required. Is that true, and in case
> i don't want to provide them, whay do i put in the fb_ops structure ?

All the functions are optional. They are needed when:

fb_open:        We need special things done when we open or close /dev/fb
fb_release:

fb_read: 	When we have a strange framebuffer that doesn't allow
fb_write:	linear writes. A good example is the Epson1385 chipset at
		16 bpp mode.

fb_check_var:   When we can change the resolution of the display.
fb_set_par:

fb_setcolreg:	Have a programable color palette.

fb_blank:	Have hardware support for power management of some kind.

fb_pan_display: Hardware scrolling

fb_cursor:	Hardware cursor.

fb_poll:	Want to use interrupts such as VLB.

fb_sync:	To sync the accel engine and framebuffer memory.

fb_ioctl:	Extra functions you want to support.

fb_mmap:	Have special memory needs when exposing to userland.

fb_rastering:	I don't know if we are going to keep this one?

The only ones require are the accel functions for drawing on the console.

> Later, in the fb_ops structure, only set_par, blank and pan_display are
> labeled as optional.

That is a mistake.



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

Re: 2.5 atyfb on Sparc question

[Geert Uytterhoeven]

On Fri, 18 Oct 2002, James Simmons wrote:
> fb_rastering:	I don't know if we are going to keep this one?

AFAIK these are used by the SPARC people only, to switch the graphics hardware
to frame buffer mode so the logo can be drawn. All other operations are done
using the accel engine on the cards that need fb_rasterimg().

So yes, once the logo is drawn by fb_imageblit(), fb_rasterimg() can be
eliminated by moving its functionality inside the fbdev-specific
fb_imageblit().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote