linux-fbdev-devel — linux-fbdev mailing list for project developers

[Linux-fbdev-devel] Re: [BK fbdev updates]

[Marcelo P. <ma...@ma...>]

James Simmons wrote:

>>I have 2 machines that are running 2.5.56 beatifully, except for fbcon 
>>and ISDN.
>>The laptop runs ATI radeon - when I attempt to boot with radeonfb+fbcon 
>>statically linked it wraps the pixels as if the driver is using 1410 
>>pixels per row while the hardware only has 1400
>>    
>>
>
>Can you try it with the latest code. I think fixes are in the standard 
>tree for this.
>
Ok, I got some very good news. I found a workaround that lets me use 
rivafb+fbcon 99% ok.
I have a 1400x1050 LCD panel. When I boot with fbcon, it garbles the 
screen like it thinks the screen has 1450 or so pixels. I can't read 
individual characters, and the each line starts further and further to 
the right.
I can login and startx on the blind, here's an fbset output at that point:

mode "1400x1050-60"
    # D: 108.003 MHz, H: 63.983 kHz, V: 60.191 Hz
    geometry 1400 1050 1400 1050 8
    timings 9259 136 40 10 0 112 3
    rgba 6/0,6/0,6/0,0/0
endmode

The if I do an fbset -g 1280 1050 1280 1050 8, I can start seeing 
characters on the screen, here's the fbset output at this point:

mode "1280x1050-65"
    # D: 108.003 MHz, H: 68.879 kHz, V: 64.797 Hz
    geometry 1280 1050 1280 1050 8
    timings 9259 136 40 10 0 112 3
    rgba 8/0,8/0,8/0,0/0
endmode

At this point there's 3 problems:

1 - stty is still attempting to use 175 columns which would have been 
correct for 1400x1050 with a 8x16 font, but the screen is not set to 
1280, I do an stty columns 160 and that is now worked around.

2 - The cursor is gone, so I can't edit lines or run vi under fbcon.

3 - If I switch color depths, the code doesn't seem to be clearing the 
screen before rendering the new text, so I end up with 1 or more scaled 
down copies of the old text.

Starting to get useable here.

Now I'll test 2.5.58bk1 with tdfxfb+fbcon, I'll post more soon.

Thanks and I'll subscribe to linux-fbdev-devel so I can get posted on 
the updates,

Marcelo Pacheco

[Linux-fbdev-devel] Re: [BK fbdev updates]

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

> I have 2 machines that are running 2.5.56 beatifully, except for fbcon 
> and ISDN.
> The laptop runs ATI radeon - when I attempt to boot with radeonfb+fbcon 
> statically linked it wraps the pixels as if the driver is using 1410 
> pixels per row while the hardware only has 1400

Can you try it with the latest code. I think fixes are in the standard 
tree for this.

> The desktop has a Vodoo 3500 AGP - when I attempt to boot with 
> 3dfxfb+fbcon statically it freezes early in the boot, probably right 
> when the fb stuff starts.

It will work now. A bug in the imagebliting code for the fonts.

Re: [Linux-fbdev-devel] video dir reorg

[Michel <mi...@da...>]

On Mit, 2003-01-15 at 01:37, James Simmons wrote: 
> > There is a response of linus in the mailing list archive about this, i
> > don't remember nor checked if it was only the first time, or not. I
> > think the objection was about complicate to supervise diffs.
> 
> Yes. The DRI people want to keep there work seperate from us.

While I hope there will be some form of cooperation between framebuffer
devices and the DRM in the future, I do think they basically serve very
different purposes so I don't think merging them makes sense.

> > Also, i think the drm drivers should compile not only on linux, but on
> > other oses too (BSDs at least).
> 
> That will be difficult. The VM layer to BSD is very very different from 
> linux. There is no way they coudl use the same code set for both without 
> making a mess. 

Probably, but keeping all code separate for all supported OSs would be
at least as big a mess, so we share as much code as possible via a
template mechanism. The BSD specific parts aren't in the Linux kernel of
course.

> > Also, i believe some of the XFree86 guys don't like fbdevs.
>  
> :-(

Luckily, those aren't part of the DRI project AFAICT. On the contrary,
several DRI developers have declared interest in supporting framebuffer
devices, and at least one of them is working on 'an embedded radeon 3d
driver that lives on top of fbdev' in Mesa CVS.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] Re: [PATCH]: cfb_imageblit() fix: handle widths not divisible by 8

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

On Wed, 2003-01-15 at 17:28, Geert Uytterhoeven wrote:
> On 15 Jan 2003, Antonino Daplas wrote:
> > On Wed, 2003-01-15 at 08:26, James Simmons wrote:
> > > Applied.
> > > 
> > > > c. Fix for fast_imageblit() so it always refer to mask tables in 32-bits
> > > > which should make it work for 64-bit machines.
> > > 
> > > Ug. I rather try yo take advantge of using the full 64 bits of data to 
> > > pass across the bus. What I was think is treat the 64 bit case as two 32 
> > > bit cases. The 64 bit data comes in and we run the data twice at tabs[].
> > > 
> > Hi James,
> > 
> > Yes, I was trying to find a way to make fast_imageblit() be fast for all
> > machine architectures.  With the patch attached, there's
> > fast_imageblit32() and fast_imageblit64().  fast_imageblit32() is
> > probably slower than fast_imageblit64 on 64-bit machines and, on the
> > other hand, fast_imageblit64() is 20% slower on 32-bit machines, but is
> > probably faster on 64-bit and higher machines.  So, the only way I can
> > think of doing this on all machine architectures is to have them go
> > separate paths.
> 
> Can't you merge fast_imageblit32() and fast_imageblit64() a bit more (with some
> #ifdef's), and just call the result fast_imageblit()? Then the definition of
> FAST_IMAGEBLIT can go away.
> 
> u32 is the same as unsigned long if BITS_PER_LONG == 32.
> 
That's true.  I don't want to do the merge before you people have seen
it.  Anyway, here's an updated one.

Tony

diff -Naur linux-2.5.56-fbdev/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.56-fbdev/drivers/video/cfbimgblt.c	2003-01-15 01:56:47.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2003-01-15 11:43:53.000000000 +0000
@@ -73,14 +73,6 @@
 	0x00000000, 0xffffffff
 };
 
-#if BITS_PER_LONG == 32
-#define FB_WRITEL fb_writel
-#define FB_READL  fb_readl
-#else
-#define FB_WRITEL fb_writeq
-#define FB_READL  fb_readq
-#endif 
-
 #if defined (__BIG_ENDIAN)
 #define LEFT_POS(bpp)          (BITS_PER_LONG - bpp)
 #define LEFT_POS32(bpp)        (32 - bpp)
@@ -95,6 +87,28 @@
 #define SHIFT_LOW(val, bits)   ((val) >> (bits))
 #endif
 
+#if BITS_PER_LONG == 32
+#define FB_WRITEL        fb_writel
+#define FB_READL         fb_readl
+#define DECLARE_FASTPATH {}
+#define INIT_FASTPATH    {}
+#define FASTPATH         fb_writel((end_mask & eorx)^bgx, dst++)
+#else
+#define FB_WRITEL        fb_writeq
+#define FB_READL         fb_readq
+#define DECLARE_FASTPATH unsigned long val, bpl
+#define INIT_FASTPATH    { val = 0; bpl = 0; }
+#define FASTPATH {                                     \
+	val |= SHIFT_HIGH((end_mask & eorx)^bgx, bpl); \
+	bpl += 32;                                     \
+	bpl &= BITS_PER_LONG - 1;                      \
+	if (!bpl) {                                    \
+		FB_WRITEL(val, dst++);                 \
+		val = 0;                               \
+	}                                              \
+}                                                      
+#endif 
+
 static inline void color_imageblit(struct fb_image *image, struct fb_info *p, 
 				   u8 *dst1, unsigned long start_index, 
 				   unsigned long pitch_index)
@@ -242,10 +256,11 @@
 	u32 bit_mask, end_mask, eorx, shift; 
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
-	u32 *dst;
 	u32 *tab = NULL;
+	unsigned long *dst;
 	char *s = image->data, *src;
-		
+	DECLARE_FASTPATH;
+
 	switch (bpp) {
 	case 8:
 		tab = cfb_tab8;
@@ -270,18 +285,19 @@
 	k = image->width/ppw;
 
 	for (i = image->height; i--; ) {
-		dst = (u32 *) dst1; shift = 8; src = s;
+		dst = (unsigned long *) dst1; shift = 8; src = s;
+		INIT_FASTPATH;
 		for (j = k; j--; ) {
 			shift -= ppw;
 			end_mask = tab[(*src >> shift) & bit_mask]; 
-			fb_writel((end_mask & eorx)^bgx, dst++);
+			FASTPATH;
 			if (!shift) { shift = 8; src++; }
 		}
 		dst1 += p->fix.line_length;
 		s += spitch;
 	}
 }	
-	
+
 void cfb_imageblit(struct fb_info *p, struct fb_image *image)
 {
 	int x2, y2, vxres, vyres;
@@ -331,7 +347,7 @@
 		
 		if (BITS_PER_LONG % bpp == 0 && !start_index && 
 		    !pitch_index && bpp >= 8 && bpp <= 32 && 
-		    (image->width & (32/bpp-1)) == 0) 
+		    (image->width & (BITS_PER_LONG/bpp-1)) == 0) 
 			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
 		else 
 			slow_imageblit(image, p, dst1, fgcolor, bgcolor, 

Re: [Linux-fbdev-devel] video dir reorg

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

On Wed, 15 Jan 2003, James Simmons wrote:
> > Also, i think the drm drivers should compile not only on linux, but on
> > other oses too (BSDs at least).
> 
> That will be difficult. The VM layer to BSD is very very different from 
> linux. There is no way they coudl use the same code set for both without 
> making a mess. 

I think Sven meant the userspace part of DRM. Of course the actual kernelspace
implementation differs.

> > Also, i believe some of the XFree86 guys don't like fbdevs.
>  
> :-(

Yes indeed :-(

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

Re: [Linux-fbdev-devel] Re: [PATCH]: cfb_imageblit() fix: handle widths not divisible by 8

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

On 15 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-15 at 08:26, James Simmons wrote:
> > Applied.
> > 
> > > c. Fix for fast_imageblit() so it always refer to mask tables in 32-bits
> > > which should make it work for 64-bit machines.
> > 
> > Ug. I rather try yo take advantge of using the full 64 bits of data to 
> > pass across the bus. What I was think is treat the 64 bit case as two 32 
> > bit cases. The 64 bit data comes in and we run the data twice at tabs[].
> > 
> Hi James,
> 
> Yes, I was trying to find a way to make fast_imageblit() be fast for all
> machine architectures.  With the patch attached, there's
> fast_imageblit32() and fast_imageblit64().  fast_imageblit32() is
> probably slower than fast_imageblit64 on 64-bit machines and, on the
> other hand, fast_imageblit64() is 20% slower on 32-bit machines, but is
> probably faster on 64-bit and higher machines.  So, the only way I can
> think of doing this on all machine architectures is to have them go
> separate paths.

Can't you merge fast_imageblit32() and fast_imageblit64() a bit more (with some
#ifdef's), and just call the result fast_imageblit()? Then the definition of
FAST_IMAGEBLIT can go away.

u32 is the same as unsigned long if BITS_PER_LONG == 32.

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

[Linux-fbdev-devel] Re: [PATCH]: cfb_imageblit() fix: handle widths not divisible by 8

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

On Wed, 2003-01-15 at 08:26, James Simmons wrote:
> 
> Applied.
> 
> > c. Fix for fast_imageblit() so it always refer to mask tables in 32-bits
> > which should make it work for 64-bit machines.
> 
> Ug. I rather try yo take advantge of using the full 64 bits of data to 
> pass across the bus. What I was think is treat the 64 bit case as two 32 
> bit cases. The 64 bit data comes in and we run the data twice at tabs[].
> 
Hi James,

Yes, I was trying to find a way to make fast_imageblit() be fast for all
machine architectures.  With the patch attached, there's
fast_imageblit32() and fast_imageblit64().  fast_imageblit32() is
probably slower than fast_imageblit64 on 64-bit machines and, on the
other hand, fast_imageblit64() is 20% slower on 32-bit machines, but is
probably faster on 64-bit and higher machines.  So, the only way I can
think of doing this on all machine architectures is to have them go
separate paths.

Note:  both fast_imageblit32() and fast_imageblit64(), in theory, should
work will all machine archs.  Your call.

Tony 

PS:  the diff should be applied with the previous patch I submitted.


diff -Naur linux-2.5.56-fbdev/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.56-fbdev/drivers/video/cfbimgblt.c	2003-01-15 01:56:47.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2003-01-15 01:57:01.000000000 +0000
@@ -74,11 +74,13 @@
 };
 
 #if BITS_PER_LONG == 32
-#define FB_WRITEL fb_writel
-#define FB_READL  fb_readl
+#define FB_WRITEL       fb_writel
+#define FB_READL        fb_readl
+#define FAST_IMAGEBLIT  fast_imageblit32
 #else
-#define FB_WRITEL fb_writeq
-#define FB_READL  fb_readq
+#define FB_WRITEL       fb_writeq
+#define FB_READL        fb_readq
+#define FAST_IMAGEBLIT  fast_imageblit64
 #endif 
 
 #if defined (__BIG_ENDIAN)
@@ -235,15 +237,16 @@
  *           fix->next_line is divisible by 4;
  *           beginning and end of a scanline is dword aligned
  */
-static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, 
-				  u8 *dst1, u32 fgcolor, u32 bgcolor) 
+#if BITS_PER_LONG == 32
+static inline void fast_imageblit32(struct fb_image *image, struct fb_info *p, 
+				    u8 *dst1, u32 fgcolor, u32 bgcolor) 
 {
 	int i, j, k; 
 	u32 bit_mask, end_mask, eorx, shift; 
 	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
 	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
-	u32 *dst;
 	u32 *tab = NULL;
+	u32 *dst;
 	char *s = image->data, *src;
 		
 	switch (bpp) {
@@ -281,7 +284,61 @@
 		s += spitch;
 	}
 }	
+#else
+static inline void fast_imageblit64(struct fb_image *image, struct fb_info *p, 
+				    u8 *dst1, u32 fgcolor, u32 bgcolor) 
+{
+	int i, j, k; 
+	u32 bit_mask, end_mask, eorx, shift; 
+	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
+	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
+	u32 *tab = NULL, bpl;
+	unsigned long *dst, val;
+	char *s = image->data, *src;
+		
+	switch (bpp) {
+	case 8:
+		tab = cfb_tab8;
+		break;
+	case 16:
+		tab = cfb_tab16;
+		break;
+	case 32:
+		tab = cfb_tab32;
+		break;
+	}
+
+	for (i = ppw-1; i--; ) {
+		fgx <<= bpp;
+		bgx <<= bpp;
+		fgx |= fgcolor;
+		bgx |= bgcolor;
+	}
 	
+	bit_mask = (1 << ppw) - 1;
+	eorx = fgx ^ bgx;
+	k = image->width/ppw;
+
+	for (i = image->height; i--; ) {
+		dst = (unsigned long *) dst1; shift = 8; src = s;
+		val = 0, bpl = 0;
+		for (j = k; j--; ) {
+			shift -= ppw;
+			end_mask = tab[(*src >> shift) & bit_mask]; 
+			val |= SHIFT_HIGH((end_mask & eorx)^bgx, bpl);
+			bpl += 32;
+			bpl &= BITS_PER_LONG - 1;
+			if (!bpl) {
+				FB_WRITEL(val, dst++);
+				val = 0;
+			}
+			if (!shift) { shift = 8; src++; }
+		}
+		dst1 += p->fix.line_length;
+		s += spitch;
+	}
+}	
+#endif
 void cfb_imageblit(struct fb_info *p, struct fb_image *image)
 {
 	int x2, y2, vxres, vyres;
@@ -331,8 +388,8 @@
 		
 		if (BITS_PER_LONG % bpp == 0 && !start_index && 
 		    !pitch_index && bpp >= 8 && bpp <= 32 && 
-		    (image->width & (32/bpp-1)) == 0) 
-			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
+		    (image->width & (BITS_PER_LONG/bpp-1)) == 0) 
+			FAST_IMAGEBLIT(image, p, dst1, fgcolor, bgcolor);
 		else 
 			slow_imageblit(image, p, dst1, fgcolor, bgcolor, 
 				       start_index, pitch_index);

Re: [Linux-fbdev-devel] Using UML to work on framebuffers

[Jon S. <jon...@ya...>]

Here's what you need to do:

1) Initialize your secondary adapter with vbios.vm86
http://www.arava.co.il/matan/svgalib/hypermail/1660.html

2) bk pull bk://namesys.com/bk/reiser4-linux-2.5 r25

Namsys uses UML to develop Reiser4. Oleg keeps UML and
2.5 very closely integrated and up to date.  

If someone tells me how, I can generate a patch for a
vanilla 2.5. If I diff from torvalds, 1.919.1.104,
would that work?

3) cd r25/fs
bk pull bk://namesys.com/bk/reiser4

this is just needed to build properly

4) Apply the attached patch

5) make mrproper

6) copy attached config file

7) make oldconfig ARCH=um

8) make linux ARCH=um

9) Download a system disk image
http://user-mode-linux.sourceforge.net/dl-sf.html
I am using:
root_fs.rh-7.2-full.pristine.20020312.bz2

if you are running redhat you will already have UML
tools, if not you need to download them too.

10) Set up sudo to run linux as root. It needs to be
root to play with the hardware.

11) start ddd &
do a ps -aux and get the pid for gdb
from ddd open the file linux and set breakpoints

12) run the image, i use:
./run gdb-pid
sudo /home/jonsmirl/aty25/linux
ubd0=cow,/opt/uml/root_fs ubd1=cows,/opt/uml/swap
root=/dev/ubd/0 ubd4=cowr,/opt/uml/reiser4
eth0=tuntap,,,192.168.0.2 debug=parent gdb-pid=${1}
video=aty128fb

You don't need the swap and reiser4 images to start.

Read about networking with UML:
http://user-mode-linux.sourceforge.net/
I run NFS from UML to my host so that I can see my
host's disk. If you aren't running NAT you may need to
modify a few things.

Let me know what doesn't work. You're the lucky first
to try this. This is a lot of work to get set up, but
it is easy to use once you get it going.

Right now I'm trying to get interrupts working.  Some
USB people are after me to help make their debugging easier.

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Linux-fbdev-devel] rivafb "Badness" using fbdev.diff.gz and 2.5.5[45]

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

Can you try the latest pacth at

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Re: [Linux-fbdev-devel] video dir reorg

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

> There is a response of linus in the mailing list archive about this, i
> don't remember nor checked if it was only the first time, or not. I
> think the objection was about complicate to supervise diffs.

Yes. The DRI people want to keep there work seperate from us.

> Also, i think the drm drivers should compile not only on linux, but on
> other oses too (BSDs at least).

That will be difficult. The VM layer to BSD is very very different from 
linux. There is no way they coudl use the same code set for both without 
making a mess. 

> Also, i believe some of the XFree86 guys don't like fbdevs.
 
:-(

Re: [Linux-fbdev-devel] Using UML to work on framebuffers

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

Yes very much so. It woudl make my life easier.

> I have a patch for 2.5 that allows some framebuffers
> drivers (non-dma ones) to run unmodified on UML. I'm
> still working on DMA and IRQ support.
> 
> UML - user mode linux. UML runs the Linux kernel as a
> process. For example my PC is booted on 2.4 and the
> UML runs 2.5.
> 
> The advantage to this is that you can use gdb/ddd to
> debug the fb driver code. It's actually kind of neat.
> I use one gdb inside of UML to control the fbtest app
> and another gdb to step the code inside of the fb
> driver. 
> 
> Is anyone interested in trying this out? 
> 
> You need two video cards in your machine one for X and
> one for the target framebuffer.  I am using AGP for X
> and targeting a PCI Rage128.
> 
> =====
> Jon Smirl
> jon...@ya...
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving 
> your online business a competitive advantage. Test-drive a Thawte SSL 
> certificate - our easy online guide will show you how. Click here to get 
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 

Re: [Linux-fbdev-devel] fonts

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

> > The cfb_imageblit() function exhibited the same behavior.  I think we
> > both made the wrong assumption that all monochrome bitmaps are packed. I
> > think the rule is:
> > 
> >     The first pixel on the next scanline is always at the next byte from
> >     the last pixel of the current scanline.  
> > 
> > So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
> > last 4 are used as padding.  It's worse with a 4x6 fonts where the
> > 4-bits are just duplicated in the other nibble.
> 
> Yes.

All the font data should be packed and byte padded at the end of each 
scanline worth of data. Also most accel engines expect the data to byte 
packed.

> But that was not my problem. Currently accel_putcs() falls back to individual
> character drawing if the fontwidth is not a multiple of 8, and reuses the same
> struct fb_image for each call of fb_imageblit(). And since my fb_imageblit()
> had a loop like `while (image->height--) { ... }' it failed. Not modifying the
> passed struct fb_image fixed the problem. Yes, we need the const there :-)

I guess I need to change that in the next set of changes.

Re: [Linux-fbdev-devel] accel_putcs()

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

> accel_putcs() calls fb_sync() after fb_imageblit(), except if fontwidth is not
> a multiple of 8 and it falls back to individual drawing of the characters. This
> patch adds the missing call to fb_sync().
> 
> It also replaces `vc->vc_font.height * width' by its precalculated value in
> `cellsize'.

Applied.

[Linux-fbdev-devel] Re: [BK fbdev updates]

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

> > Linus, please do a
> 
> James,
> 
> 2.5 still doesn't work on my vaio (I think I told you about this 3-4
> months ago) with the neofb. It just crashes with a black screen. If you
> don't have any clues what the problem is, I can hook the machine up to a
> serial console and see if anything interesting pops up. Using vesafb
> does make it boot, however the screen stays pitch black until X loads...

VESA doesn't work either. Can you check to see if you have framebuffer 
console enabled. Yes I'm curious to see why your neofb doesn't work.

[Linux-fbdev-devel] Using UML to work on framebuffers

[Jon S. <jon...@ya...>]

I have a patch for 2.5 that allows some framebuffers
drivers (non-dma ones) to run unmodified on UML. I'm
still working on DMA and IRQ support.

UML - user mode linux. UML runs the Linux kernel as a
process. For example my PC is booted on 2.4 and the
UML runs 2.5.

The advantage to this is that you can use gdb/ddd to
debug the fb driver code. It's actually kind of neat.
I use one gdb inside of UML to control the fbtest app
and another gdb to step the code inside of the fb
driver. 

Is anyone interested in trying this out? 

You need two video cards in your machine one for X and
one for the target framebuffer.  I am using AGP for X
and targeting a PCI Rage128.

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Linux-fbdev-devel] Re: [PATCH]: cfb_imageblit() fix: handle widths not divisible by 8

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

Applied.

> c. Fix for fast_imageblit() so it always refer to mask tables in 32-bits
> which should make it work for 64-bit machines.

Ug. I rather try yo take advantge of using the full 64 bits of data to 
pass across the bus. What I was think is treat the 64 bit case as two 32 
bit cases. The 64 bit data comes in and we run the data twice at tabs[].

[Linux-fbdev-devel] [FB BK updates]

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

More updates and fixes for the framebuffer layer.

The standard diff is at

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Linus, please do a

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

This will update the following files:

 drivers/video/tridentfb.h        |  169 ----
 include/video/font.h             |   24
 arch/m68k/kernel/m68k_defs.c     |    2
 drivers/video/Kconfig            |    2
 drivers/video/Makefile           |    9
 drivers/video/aty/atyfb.h        |    1
 drivers/video/aty/atyfb_base.c   |   93 --
 drivers/video/aty/mach64_accel.c |   12
 drivers/video/cfbcopyarea.c      |   85 +-
 drivers/video/cfbfillrect.c      |   22
 drivers/video/cfbimgblt.c        |  146 +--
 drivers/video/console/Kconfig    |   14
 drivers/video/console/fbcon.c    |   95 +-
 drivers/video/console/sticon.c   |  101 +-
 drivers/video/console/sticore.c  |  159 ++--
 drivers/video/fbmem.c            |   17
 drivers/video/fbmon.c            |  411 ++++++++++
 drivers/video/i810/i810.h        |    2
 drivers/video/i810/i810_accel.c  |   11
 drivers/video/i810/i810_dvt.c    |    2
 drivers/video/i810/i810_main.c   |   51 -
 drivers/video/i810/i810_main.h   |   79 --
 drivers/video/riva/Makefile      |    2
 drivers/video/riva/fbdev.c       | 1470 ++++++++++++++++++---------------------
 drivers/video/riva/nv_driver.c   |  212 +++++
 drivers/video/riva/riva_hw.c     |  350 +++++++--
 drivers/video/riva/rivafb.h      |   15
 drivers/video/sstfb.c            |  711 +++++++++---------
 drivers/video/sstfb.h            |   31
 drivers/video/sticore.h          |   58 -
 drivers/video/stifb.c            |  103 ++
 drivers/video/tdfxfb.c           |   12
 drivers/video/tridentfb.c        | 1213 +++++++++++++++-----------------
 include/linux/fb.h               |   13
 include/linux/font.h             |   30
 include/video/trident.h          |  175 ++++
 36 files changed, 3352 insertions(+), 2550 deletions(-)

through these ChangeSets:

<jsi...@ma...> (03/01/14 1.898)
   [GENERIC IMAGEBLIT ACCEL]

   a) Fix for cfb_imagblit so it can handle monochrome bitmaps with widths
      not multiples of 8.

   b) Further optiminzation of fast_imageblit by removing unnecessary steps
      from its main loop.

   c) fast_imageblit show now work for bitmaps widths which are least
      divisible by 4. 4x6 and 12x22 shoudl use fast_imageblit now.

   d) Use hadrware syncing method of hardware if present.

   e) trivial: wrap text at 80 columns.

   [RIVA and 3DFX] imageblit functions busted for large images. Use generic
                   functions for now.

   Several syncing issues fixed between the accel engine and access to the
   framebuffer in several files.

<jsi...@ma...> (03/01/11 1.891)
   [TRIDENT FBDEV] Driver ported to the new api.

<jsi...@ma...> (03/01/10 1.887.1.4)
   Final updates to the GTF code. Now the code can gnerate GTF timings
   regardless of the validity of info->monospecs.

   [ATYFB] Updates to the aty driver.

<jsi...@ma...> (03/01/08 1.887.1.1)
   Remove fb_set_var. Some how it was missed in a merge conflict.

<jsimmons@kozmo.(none)> (03/01/08 1.889)
   [ATY] Somehow a merge mistake happened. We removed fb_set_var.

<jsi...@ma...> (03/01/08 1.887)
   [MONITOR support] GTF support for VESA complaint monitors. Here we
   calculate the general timings needed so we don't over step the bounds
   for a monitor.

   [fbmem.c cleanup] Name change to make the code easier to read.

<jsi...@ma...> (03/01/07 1.879.2.95)
   Updates from Helge Deller for the console/fbdev drivers for the PARISC
   platform. Small fix for clearing the screen and a string typo for the
   Voodoo 1/2 driver.

<jsi...@ma...> (03/01/06 1.879.2.93)
   [RIVA FBDEV] Driver now uses its own fb_open and fb_release function again.
   It has no ill effects. The drivers uses strickly hardware acceleration
   so we don't need cfb_fillrect and cfb_copyarea.

   Cleaned up font.h. Geerts orignal patch broke them up into a font.h in
   video and one in  linux. Now I put them back together again in
   include/linux. The m68k platform has been updated for this change.

<jsi...@ma...> (03/01/06 1.879.2.92)
   Added resize support for the framebuffer console. Now you can change the
   console size via stty. Also support for color palette changing on VC
   switch is supported.

<jsi...@ma...> (03/01/06 1.879.2.91)
   I810 fbdev updates. Cursor fix for ati mach 64 cards on big endian
   machines. Buffer over flow fix for fbcon putcs function. C99 initializers
   for the STI console drivers.Voodoo 1/2 and NVIDIA driver updates.

Re: [Linux-fbdev-devel] Rage1128

[Jon S. <jon...@ya...>]

--- Brad Douglas <br...@ne...> wrote:
> ATI does not give out initialization information
> about their chipsets.

I got one email from them offering me the Rage128 SDK.
Since then I haven't heard anything.  I don't know if
the SDK has the needed info.

I see that the cards can vary in type and amount of
VRAM. But this info must be in the ROM or a register
somewhere.  The ROM code needs to read this info from
somewhere at boot time.  I was hoping the the
protected mode code could  get this info out of the
ROM too.

I found this at Rage Underground:
The simple answer is that you should NOT flash your
Rage128 BIOS! The reason is that there are over 50
revisions of the Rage 128 card.

Do you think ATI can provide the info needs for
writing an init routine that can handle the 50
variations? Has ATI written a unified Rage128 BIOS
that will work in all the cards? I have a hard time
imagining that they are keeping 50 separate source
code projects for the BIOS.

Another solution to this would be to modify the kernel
to initialize secondary video cards via Int10 very
early in the boot process; before it gets so hard to
get into vm86 mode. This would still leave DDC without
a solution. Has anyone tried this approach?

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Linux-fbdev-devel] video dir reorg

[Sven L. <lu...@dp...>]

On Tue, Jan 14, 2003 at 09:22:36AM -0800, Jon Smirl wrote:
> --- Sven Luther <lu...@dp...> wrote:
> > I think Linus rejected this last time James
> > submitted it.
> 
> Didn't the last patch just move the DRM directory from
> driver/char into the video directory.?

There is a response of linus in the mailing list archive about this, i
don't remember nor checked if it was only the first time, or not. I
think the objection was about complicate to supervise diffs.

> This could be done in two steps. First split out the
> fb console driver files into their own directory and
> then sort out the hardware drivers more. Then if the
> DRM merge gets ok'd everything will be ready.
> 
> In the config system I don't like how you have to
> enable driver support for the same piece of hardware
> in two different places. I also don't like looking in
> two different places for the source to drivers for the
> same hardware.
> 
> What is Linus' take on merging a card's fb and drm
> drivers into a single module in the long run?

Well, the problem is that the fb drivers are maintained by us, and the
drm drivers are maintained by the DRI.

Also, i think the drm drivers should compile not only on linux, but on
other oses too (BSDs at least).

Also, i believe some of the XFree86 guys don't like fbdevs.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Rage1128

[Brad D. <br...@ne...>]

Sorry for replying so late...

ATI does not give out initialization information about their chipsets.

They expect that we initialize by either BIOS call (x86 - This is how MS
initializes their dual displays) or probing initialization settings from
OpenFirmware on the architectures that have it.

Part of the reason is because ATI claims that each revision of the
chipset can have different initialization parameters, etc (which is
certainly possible, but has not been my experience).

I will approach developer relations again and see if they are willing to
part with more information now that they have moved on to the Radeon.

If I successfully get any information from them, I post a message to the
list...


Brad Douglas
br...@ne...


On Thu, 2003-01-09 at 11:34, Jon Smirl wrote:
> Does anyone on this list have a Rage128 manual? 
> 
> Can anyone point me to source code for directly
> reseting a Rage128? I already have the emulate real
> mode and call C000:3 method.
> 
> =====
> Jon Smirl
> jon...@ya...

Re: [Linux-fbdev-devel] video dir reorg

[Jon S. <jon...@ya...>]

--- Sven Luther <lu...@dp...> wrote:
> I think Linus rejected this last time James
> submitted it.

Didn't the last patch just move the DRM directory from
driver/char into the video directory.?

This could be done in two steps. First split out the
fb console driver files into their own directory and
then sort out the hardware drivers more. Then if the
DRM merge gets ok'd everything will be ready.

In the config system I don't like how you have to
enable driver support for the same piece of hardware
in two different places. I also don't like looking in
two different places for the source to drivers for the
same hardware.

What is Linus' take on merging a card's fb and drm
drivers into a single module in the long run?

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Linux-fbdev-devel] [PATCH]: cfb_imageblit() fix: handle widths not divisible by 8

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

James,

Heres a patch against 2.5.56 and your latest fbdev.diff:

a. fix for cfb_imageblit so it can handle monochrome bitmaps with widths
not a multiple of 8 (12x22, 4x6 fonts should now work)

b. further optimization of fast_imageblit() by removing unnecessary
steps from its main loop. 

c. fast_imageblit() should now work for bitmap widths which are least
divisible by 4 (12x22 and 4x6 fonts should now go to fast_imageblit()
instead of slow_imageblit().

c. Fix for fast_imageblit() so it always refer to mask tables in 32-bits
which should make it work for 64-bit machines.

d.  insert info->fbops->fb_sync() where it is needed: ie, 
cfb_{imageblit,fillrect,copyarea} and before the actual read/write in
fb_write and fb_read.

e.  trivial:  wrap text at 80 columns

Tony


diff -Naur linux-2.5.56-fbdev/drivers/video/cfbcopyarea.c linux/drivers/video/cfbcopyarea.c
--- linux-2.5.56-fbdev/drivers/video/cfbcopyarea.c	2003-01-14 11:34:35.000000000 +0000
+++ linux/drivers/video/cfbcopyarea.c	2003-01-14 01:21:49.000000000 +0000
@@ -65,13 +65,15 @@
 			// Single word
 			if (last)
 				first &= last;
-			FB_WRITEL((*src & first) | (FB_READL(dst) & ~first), dst);
+			FB_WRITEL((*src & first) | (FB_READL(dst) & ~first), 
+				  dst);
 		} else {
 			// Multiple destination words
 			// Leading bits
 			if (first) {
 				
-				FB_WRITEL((*src & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL((*src & first) | (FB_READL(dst) & 
+							    ~first), dst);
 				dst++;
 				src++;
 				n -= BITS_PER_LONG-dst_idx;
@@ -94,7 +96,8 @@
 				FB_WRITEL(*src++, dst++);
 			// Trailing bits
 			if (last)
-				FB_WRITEL((*src & last) | (FB_READL(dst) & ~last), dst);
+				FB_WRITEL((*src & last) | (FB_READL(dst) & 
+							   ~last), dst);
 		}
 	} else {
 		// Different alignment for source and dest
@@ -108,15 +111,18 @@
 				first &= last;
 			if (shift > 0) {
 				// Single source word
-				FB_WRITEL(((*src >> right) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((*src >> right) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 			} else if (src_idx+n <= BITS_PER_LONG) {
 				// Single source word
-				FB_WRITEL(((*src << left) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((*src << left) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 			} else {
 				// 2 source words
 				d0 = *src++;
 				d1 = *src;
-				FB_WRITEL(((d0 << left | d1 >> right) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((d0<<left | d1>>right) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 			}
 		} else {
 			// Multiple destination words
@@ -124,13 +130,15 @@
 			// Leading bits
 			if (shift > 0) {
 				// Single source word
-				FB_WRITEL(((d0 >> right) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((d0 >> right) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 				dst++;
 				n -= BITS_PER_LONG-dst_idx;
 			} else {
 				// 2 source words
 				d1 = *src++;
-				FB_WRITEL(((d0 << left | d1 >> right) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((d0<<left | d1>>right) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 				d0 = d1;
 				dst++;
 				n -= BITS_PER_LONG-dst_idx;
@@ -164,11 +172,15 @@
 			if (last) {
 				if (m <= right) {
 					// Single source word
-					FB_WRITEL(((d0 << left) & last) | (FB_READL(dst) & ~last), dst);
+					FB_WRITEL(((d0 << left) & last) | 
+						  (FB_READL(dst) & ~last), 
+						  dst);
 				} else {
 					// 2 source words
 					d1 = *src;
-					FB_WRITEL(((d0 << left | d1 >> right) & last) | (FB_READL(dst) & ~last), dst);
+					FB_WRITEL(((d0<<left | d1>>right) & 
+						   last) | (FB_READL(dst) & 
+							    ~last), dst);
 				}
 			}
 		}
@@ -208,12 +220,14 @@
 			// Single word
 			if (last)
 				first &= last;
-			FB_WRITEL((*src & first) | (FB_READL(dst) & ~first), dst);
+			FB_WRITEL((*src & first) | (FB_READL(dst) & ~first), 
+				  dst);
 		} else {
 			// Multiple destination words
 			// Leading bits
 			if (first) {
-				FB_WRITEL((*src & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL((*src & first) | (FB_READL(dst) & 
+							    ~first), dst);
 				dst--;
 				src--;
 				n -= dst_idx+1;
@@ -237,7 +251,8 @@
 			
 			// Trailing bits
 			if (last)
-				FB_WRITEL((*src & last) | (FB_READL(dst) & ~last), dst);
+				FB_WRITEL((*src & last) | (FB_READL(dst) & 
+							   ~last), dst);
 		}
 	} else {
 		// Different alignment for source and dest
@@ -251,15 +266,18 @@
 				first &= last;
 			if (shift < 0) {
 				// Single source word
-				FB_WRITEL((*src << left & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL((*src << left & first) | 
+					  (FB_READL(dst) & ~first), dst);
 			} else if (1+(unsigned long)src_idx >= n) {
 				// Single source word
-				FB_WRITEL(((*src >> right) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((*src >> right) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 			} else {
 				// 2 source words
 				d0 = *src--;
 				d1 = *src;
-				FB_WRITEL(((d0 >> right | d1 << left) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((d0>>right | d1<<left) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 			}
 		} else {
 			// Multiple destination words
@@ -267,13 +285,15 @@
 			// Leading bits
 			if (shift < 0) {
 				// Single source word
-				FB_WRITEL(((d0 << left) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((d0 << left) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 				dst--;
 				n -= dst_idx+1;
 			} else {
 				// 2 source words
 				d1 = *src--;
-				FB_WRITEL(((d0 >> right | d1 << left) & first) | (FB_READL(dst) & ~first), dst);
+				FB_WRITEL(((d0>>right | d1<<left) & first) | 
+					  (FB_READL(dst) & ~first), dst);
 				d0 = d1;
 				dst--;
 				n -= dst_idx+1;
@@ -307,12 +327,15 @@
 			if (last) {
 				if (m <= left) {
 					// Single source word
-					FB_WRITEL(((d0 >> right) & last) | (FB_READL(dst) & ~last), dst);
+					FB_WRITEL(((d0 >> right) & last) | 
+						  (FB_READL(dst) & ~last), 
+						  dst);
 				} else {
 					// 2 source words
 					d1 = *src;
-					FB_WRITEL(((d0 >> right | d1 << left) & last) |
-						  (FB_READL(dst) & ~last), dst);
+					FB_WRITEL(((d0>>right | d1<<left) & 
+						   last) | (FB_READL(dst) & 
+							    ~last), dst);
 				}
 			}
 		}
@@ -364,17 +387,21 @@
 	    (area->sy + area->height) > vyres)
 		return;
 	
-	if (area->dy > area->sy || (area->dy == area->sy && area->dx > area->sx)) {
+	if (area->dy > area->sy || (area->dy == area->sy && 
+				    area->dx > area->sx)) {
 		area->dy += area->height;
 		area->sy += area->height;
 		rev_copy = 1;
 	}
 
-	dst = src = (unsigned long *)((unsigned long)p->screen_base & ~(BYTES_PER_LONG-1));
+	dst = src = (unsigned long *)((unsigned long)p->screen_base & 
+				      ~(BYTES_PER_LONG-1));
 	dst_idx = src_idx = (unsigned long)p->screen_base & (BYTES_PER_LONG-1);
 	dst_idx += area->dy*next_line*8 + area->dx*p->var.bits_per_pixel;
 	src_idx += area->sy*next_line*8 + area->sx*p->var.bits_per_pixel;
 	
+	if (p->fbops->fb_sync)
+		p->fbops->fb_sync(p);
 	if (rev_copy) {
 		while (area->height--) {
 			dst_idx -= next_line*8;
@@ -383,8 +410,9 @@
 			dst_idx &= (BYTES_PER_LONG-1);
 			src += src_idx >> SHIFT_PER_LONG;
 			src_idx &= (BYTES_PER_LONG-1);
-			bitcpy_rev((unsigned long*)dst, dst_idx, (unsigned long *)src,
-					src_idx, area->width*p->var.bits_per_pixel);
+			bitcpy_rev((unsigned long*)dst, dst_idx, 
+				   (unsigned long *)src, src_idx, 
+				   area->width*p->var.bits_per_pixel);
 		}	
 	} else {
 		while (area->height--) {
@@ -392,8 +420,9 @@
 			dst_idx &= (BYTES_PER_LONG-1);
 			src += src_idx >> SHIFT_PER_LONG;
 			src_idx &= (BYTES_PER_LONG-1);
-			bitcpy((unsigned long*)dst, dst_idx, (unsigned long *)src,
-				   src_idx, area->width*p->var.bits_per_pixel);
+			bitcpy((unsigned long*)dst, dst_idx, 
+			       (unsigned long *)src, src_idx, 
+			       area->width*p->var.bits_per_pixel);
 			dst_idx += next_line*8;
 			src_idx += next_line*8;
 		}	
diff -Naur linux-2.5.56-fbdev/drivers/video/cfbfillrect.c linux/drivers/video/cfbfillrect.c
--- linux-2.5.56-fbdev/drivers/video/cfbfillrect.c	2003-01-14 11:34:32.000000000 +0000
+++ linux/drivers/video/cfbfillrect.c	2003-01-14 01:21:46.000000000 +0000
@@ -99,7 +99,8 @@
      *  the correct start position
      */
 
-static inline unsigned long pixel_to_pat(const struct fb_info *p, pixel_t pixel, int left)
+static inline unsigned long pixel_to_pat(const struct fb_info *p, 
+					 pixel_t pixel, int left)
 {
     unsigned long pat = pixel;
     u32 bpp = p->var.bits_per_pixel;
@@ -373,7 +374,8 @@
 	vxres = p->var.xres_virtual;
 	vyres = p->var.yres_virtual;
 
-	if (!rect->width || !rect->height || rect->dx > vxres || rect->dy > vyres)
+	if (!rect->width || !rect->height || 
+	    rect->dx > vxres || rect->dy > vyres)
 		return;
 
 	/* We could use hardware clipping but on many cards you get around
@@ -392,14 +394,18 @@
 	else
 		fg = rect->color;
 	
-	dst = (unsigned long *)((unsigned long)p->screen_base & ~(BYTES_PER_LONG-1));
+	dst = (unsigned long *)((unsigned long)p->screen_base & 
+				~(BYTES_PER_LONG-1));
 	dst_idx = ((unsigned long)p->screen_base & (BYTES_PER_LONG-1))*8;
 	dst_idx += rect->dy*p->fix.line_length*8+rect->dx*bpp;
 	/* FIXME For now we support 1-32 bpp only */
 	left = BITS_PER_LONG % bpp;
+	if (p->fbops->fb_sync)
+		p->fbops->fb_sync(p);
 	if (!left) {
 		u32 pat = pixel_to_pat32(p, fg);
-		void (*fill_op32)(unsigned long *dst, int dst_idx, u32 pat, u32 n) = NULL;
+		void (*fill_op32)(unsigned long *dst, int dst_idx, u32 pat, 
+				  u32 n) = NULL;
 		
 		switch (rect->rop) {
 		case ROP_XOR:
@@ -420,8 +426,9 @@
 		unsigned long pat = pixel_to_pat(p, fg, (left-dst_idx) % bpp);
 		int right = bpp-left;
 		int r;
-		void (*fill_op)(unsigned long *dst, int dst_idx, unsigned long pat, 
-				int left, int right, u32 n) = NULL;
+		void (*fill_op)(unsigned long *dst, int dst_idx, 
+				unsigned long pat, int left, int right, 
+				u32 n) = NULL;
 		
 		switch (rect->rop) {
 		case ROP_XOR:
@@ -435,7 +442,8 @@
 		while (height--) {
 			dst += dst_idx >> SHIFT_PER_LONG;
 			dst_idx &= (BITS_PER_LONG-1);
-			fill_op(dst, dst_idx, pat, left, right, rect->width*bpp);
+			fill_op(dst, dst_idx, pat, left, right, 
+				rect->width*bpp);
 			r = (p->fix.line_length*8) % bpp;
 			pat = pat << (bpp-r) | pat >> r;
 			dst_idx += p->fix.line_length*8;
diff -Naur linux-2.5.56-fbdev/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.56-fbdev/drivers/video/cfbimgblt.c	2003-01-14 11:34:27.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2003-01-14 01:21:42.000000000 +0000
@@ -19,10 +19,6 @@
  *  up to the nearest byte. For example a bitmap 12 bits wide must be two 
  *  bytes width. 
  *
- *  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.
@@ -32,7 +28,6 @@
  *
  *  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.
- *
  */
 #include <linux/config.h>
 #include <linux/module.h>
@@ -88,18 +83,21 @@
 
 #if defined (__BIG_ENDIAN)
 #define LEFT_POS(bpp)          (BITS_PER_LONG - bpp)
+#define LEFT_POS32(bpp)        (32 - bpp)
 #define NEXT_POS(pos, bpp)     ((pos) -= (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) >> (bits))
 #define SHIFT_LOW(val, bits)   ((val) << (bits))
 #else
 #define LEFT_POS(bpp)          (0)
+#define LEFT_POS32(bpp)        (0)
 #define NEXT_POS(pos, bpp)     ((pos) += (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) << (bits))
 #define SHIFT_LOW(val, bits)   ((val) >> (bits))
 #endif
 
-static inline void color_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1, 
-				   unsigned long start_index, unsigned long pitch_index)
+static inline void color_imageblit(struct fb_image *image, struct fb_info *p, 
+				   u8 *dst1, unsigned long start_index, 
+				   unsigned long pitch_index)
 {
 	/* Draw the penguin */
 	unsigned long *dst, *dst2, color = 0, val, shift;
@@ -116,7 +114,8 @@
 		val = 0;
 		
 		if (start_index) {
-			unsigned long start_mask = ~(SHIFT_HIGH(~0UL, start_index));
+			unsigned long start_mask = ~(SHIFT_HIGH(~0UL, 
+								start_index));
 
 			val = FB_READL(dst) & start_mask;
 			shift = start_index;
@@ -134,7 +133,8 @@
 				if (shift == null_bits)
 					val = 0;
 				else
-					val = SHIFT_LOW(color, BITS_PER_LONG - shift);
+					val = SHIFT_LOW(color, BITS_PER_LONG -
+							shift);
 			}
 			shift += bpp;
 			shift &= (BITS_PER_LONG - 1);
@@ -157,60 +157,64 @@
 	}
 }
 
-static inline void slow_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
-				  unsigned long fgcolor, unsigned long bgcolor, 
-				  unsigned long start_index, unsigned long pitch_index)
+static inline void slow_imageblit(struct fb_image *image, struct fb_info *p, 
+				  u8 *dst1, unsigned long fgcolor, 
+				  unsigned long bgcolor, 
+				  unsigned long start_index,
+				  unsigned long pitch_index)
 {
-	unsigned long i, j, l = 8;
+	unsigned long i, j, l;
 	unsigned long shift, color, bpp = p->var.bits_per_pixel;
 	unsigned long *dst, *dst2, val, pitch = p->fix.line_length;
 	unsigned long null_bits = BITS_PER_LONG - bpp;
+	unsigned long spitch = (image->width+7)/8;
 	u8 *src = image->data, *s;
 	
 	dst2 = (unsigned long *) dst1;
 
 	for (i = image->height; i--; ) {
-		shift = 0;
-		val = 0;
+		shift = val = 0;
+		l = 8;
 		j = image->width;
 		dst = (unsigned long *) dst1;
+		s = src;
 
 		/* write leading bits */
 		if (start_index) {
-			unsigned long start_mask = ~(SHIFT_HIGH(~0UL, start_index));
+			unsigned long start_mask = ~(SHIFT_HIGH(~0UL, 
+								start_index));
 
 			val = FB_READL(dst) & start_mask;
 			shift = start_index;
 		}
+
 		while (j--) {
 			l--;
-			if (*src & (1 << l)) 
-				color = fgcolor;
-			else 
-				color = bgcolor;
+			color = (*s & (1 << l)) ? fgcolor : bgcolor;
 			color <<= LEFT_POS(bpp);
 			val |= SHIFT_HIGH(color, shift);
 			
 			/* Did the bitshift spill bits to the next long? */
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
-				if (shift == null_bits)
-					val = 0;
-				else
-					val = SHIFT_LOW(color, BITS_PER_LONG - shift);
+				val = (shift == null_bits) ? 
+					0 : SHIFT_LOW(color, BITS_PER_LONG - 
+						      shift);
 			}
 			shift += bpp;
 			shift &= (BITS_PER_LONG - 1);
-			if (!l) { l = 8; src++; };
+			if (!l) { l = 8; s++; };
 		}
+
 		/* write trailing bits */
  		if (shift) {
 			unsigned long end_mask = SHIFT_HIGH(~0UL, shift);
 
 			FB_WRITEL((FB_READL(dst) & end_mask) | val, dst);
 		}
-		dst1 += pitch;	
 
+		dst1 += pitch;	
+		src += spitch;
 		if (pitch_index) {
 			dst2 += pitch;
 			dst1 = (char *) dst2;
@@ -223,26 +227,33 @@
 	}
 }
 
-static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1, 
-				  unsigned long fgcolor, unsigned long bgcolor) 
+/*
+ * fast_imageblit - optimized monochrome color expansion
+ *
+ * Only if:  bits_per_pixel == 8, 16, or 32
+ *           image->width is divisible by pixel/dword (ppw);
+ *           fix->next_line is divisible by 4;
+ *           beginning and end of a scanline is dword aligned
+ */
+static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, 
+				  u8 *dst1, u32 fgcolor, u32 bgcolor) 
 {
-	int i, j, k, l = 8, n;
-	unsigned long bit_mask, end_mask, eorx; 
-	unsigned long fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
-	unsigned long tmp = (1 << bpp) - 1;
-	unsigned long ppw = BITS_PER_LONG/bpp, ppos;
-	unsigned long *dst;
+	int i, j, k; 
+	u32 bit_mask, end_mask, eorx, shift; 
+	u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
+	u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
+	u32 *dst;
 	u32 *tab = NULL;
-	char *src = image->data;
+	char *s = image->data, *src;
 		
-	switch (ppw) {
-	case 4:
+	switch (bpp) {
+	case 8:
 		tab = cfb_tab8;
 		break;
-	case 2:
+	case 16:
 		tab = cfb_tab16;
 		break;
-	case 1:
+	case 32:
 		tab = cfb_tab32;
 		break;
 	}
@@ -254,38 +265,20 @@
 		bgx |= bgcolor;
 	}
 	
-	n = ((image->width + 7) / 8);
-	pad = (n * 8) - 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;
-		
+		dst = (u32 *) dst1; shift = 8; src = s;
 		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++; }
+			shift -= ppw;
+			end_mask = tab[(*src >> shift) & bit_mask]; 
+			fb_writel((end_mask & eorx)^bgx, dst++);
+			if (!shift) { shift = 8; src++; }
 		}
-		if (n) {
-			end_mask = 0;	
-			ppos = LEFT_POS(bpp);
-			for (j = n; j > 0; j--) {
-				l--;
-				if (*src & (1 << l))
-					end_mask |= tmp << ppos;
-				NEXT_POS(ppos, bpp);
-				if (!l) { l = 8; src++; }
-			}
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
-		}
-		l -= pad;		
-		dst1 += p->fix.line_length;	
+		dst1 += p->fix.line_length;
+		s += spitch;
 	}
 }	
 	
@@ -299,8 +292,9 @@
 	vxres = p->var.xres_virtual;
 	vyres = p->var.yres_virtual;
 	/* 
-	 * We could use hardware clipping but on many cards you get around hardware
-	 * clipping by writing to framebuffer directly like we are doing here. 
+	 * We could use hardware clipping but on many cards you get around 
+	 * hardware clipping by writing to framebuffer directly like we are 
+	 * doing here. 
 	 */
 	if (image->dx > vxres ||
 	    image->dy > vyres)
@@ -323,21 +317,25 @@
 	bitstart &= ~(bpl - 1);
 	dst1 = p->screen_base + bitstart;
 
+	if (p->fbops->fb_sync)
+		p->fbops->fb_sync(p);
 	if (image->depth == 1) {
 		if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
 		    p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
-			fgcolor = ((u32 *)(p->pseudo_palette))[image->fg_color];
-			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 {
 			fgcolor = image->fg_color;
 			bgcolor = image->bg_color;
 		}	
 		
-		if (BITS_PER_LONG % bpp == 0 && !start_index && !pitch_index && 
-		    bpp >= 8 && bpp <= 32 && (image->width & 7) == 0) 
+		if (BITS_PER_LONG % bpp == 0 && !start_index && 
+		    !pitch_index && bpp >= 8 && bpp <= 32 && 
+		    (image->width & (32/bpp-1)) == 0) 
 			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
 		else 
-			slow_imageblit(image, p, dst1, fgcolor, bgcolor, start_index, pitch_index);
+			slow_imageblit(image, p, dst1, fgcolor, bgcolor, 
+				       start_index, pitch_index);
 	}
 	else if (image->depth == bpp) 
 		color_imageblit(image, p, dst1, start_index, pitch_index);
diff -Naur linux-2.5.56-fbdev/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.56-fbdev/drivers/video/fbmem.c	2003-01-14 11:34:40.000000000 +0000
+++ linux/drivers/video/fbmem.c	2003-01-14 01:21:53.000000000 +0000
@@ -656,6 +656,8 @@
 	    count = info->fix.smem_len;
 	if (count + p > info->fix.smem_len)
 		count = info->fix.smem_len - p;
+	if (info->fbops->fb_sync)
+		info->fbops->fb_sync(info);
 	if (count) {
 	    char *base_addr;
 
@@ -692,6 +694,8 @@
 	    count = info->fix.smem_len - p;
 	    err = -ENOSPC;
 	}
+	if (info->fbops->fb_sync)
+		info->fbops->fb_sync(info);
 	if (count) {
 	    char *base_addr;
 

Re: [Linux-fbdev-devel] video dir reorg

[Sven L. <lu...@dp...>]

On Mon, Jan 13, 2003 at 06:02:07PM -0800, Jon Smirl wrote:
> Does it make sense to try merging the DRM drivers into
> the video directory? Maybe something like this:
> 
> video -- empty except for Kconfig file
> video/console -- generic fbconsole code
> video/DRM -- generic DRM code
> video/ati -- ati drivers (drm & fb)
> video/i810 -- i810 drivers (drm & fb)
> etc.....
> 
> This would allow the merging of the DRM and FB
> hardware device drivers over time. Switching VTs
> should be coordinated with saving 3D state.
> 
> Even with out merging DRM should the console driver be
> split out from the hardware drivers?

I think Linus rejected this last time James submitted it.

That said, there is a trend with the DRI people that now want to use the
drm modules to do memory allocation or something such, which was, i
think, previously done in the X server.

Maybe this would be of interrest to a fbdev<->drm merging James did
speak about some time ago.

Friendly,

Sven Luther

[Linux-fbdev-devel] video dir reorg

[Jon S. <jon...@ya...>]

Does it make sense to try merging the DRM drivers into
the video directory? Maybe something like this:

video -- empty except for Kconfig file
video/console -- generic fbconsole code
video/DRM -- generic DRM code
video/ati -- ati drivers (drm & fb)
video/i810 -- i810 drivers (drm & fb)
etc.....

This would allow the merging of the DRM and FB
hardware device drivers over time. Switching VTs
should be coordinated with saving 3D state.

Even with out merging DRM should the console driver be
split out from the hardware drivers?

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Linux-fbdev-devel] Re: [BK fbdev updates]

[Marcelo P. <ma...@ma...>]

>
>
>James,
>
>2.5 still doesn't work on my vaio (I think I told you about this 3-4
>months ago) with the neofb. It just crashes with a black screen. If you
>don't have any clues what the problem is, I can hook the machine up to a
>serial console and see if anything interesting pops up. Using vesafb
>does make it boot, however the screen stays pitch black until X loads...
>
I have 2 machines that are running 2.5.56 beatifully, except for fbcon 
and ISDN.
The laptop runs ATI radeon - when I attempt to boot with radeonfb+fbcon 
statically linked it wraps the pixels as if the driver is using 1410 
pixels per row while the hardware only has 1400
The desktop has a Vodoo 3500 AGP - when I attempt to boot with 
3dfxfb+fbcon statically it freezes early in the boot, probably right 
when the fb stuff starts.
I'm running 2.5.56 on both, so any tests, on any further info, just let 
me know.
I'm not on the list, so please CC me on any replies.

Marcelo Pacheco