2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Miles Lane]

Hi,

I have tried getting rivafb to work in 2.5.51.  It is much better
than before (thanks!).  It compiles and sorta works.

Here are the problems:

When I run "fbset -a 640x480", I get display that fills
the screen and looks okay, but most of the characters are
flipped along the vertical axis, so they are backwards, so that:

+----		    ----+
|			|
+---    becomes	     ---+
|			|
|			|

Also, when I boot, the penguin logo looks like it is being rendered
in about five colors.  In addition, the text is black, except for
the white underscore cursor, so all I can see is the cursor.
When the gpm gets loaded, the mouse pointer, instead of showing
a white rectangle that, when it passes over a character, shows that
character in reverse-video, shows a colored cursor that always
contains some character.  The character shown in the mouse cursor 
changes when it passes over text in the window, but it never shows
the character it is passing over.

Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows
a usable console window, but it is embedded in the larger high
resolution display, like this:

	+---------+----------------+
	|	  |		   |
	|	  |		   |
	|	  |		   |
	+---------+		   |
	|			   |
	|			   |
	|			   |
	|			   |
	|			   |
	+--------------------------+

The area outside of the 640x480 boundary is filled with colored
junk (no characters).

Any ideas?

	Miles



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[James Simmons]

> I have tried getting rivafb to work in 2.5.51.  It is much better
> than before (thanks!).  It compiles and sorta works.

Ug. Now that several drivers compile now I get bug reports :-( I'm getting
alot of positive feedback as well as one negative source.

> Here are the problems:
>
> When I run "fbset -a 640x480", I get display that fills
> the screen and looks okay, but most of the characters are
> flipped along the vertical axis, so they are backwards, so that:
>
> +----		    ----+
> |			|
> +---    becomes	     ---+
> |			|
> |			|

Okay. That is weird. I have this card so I will give it a try.

> Also, when I boot, the penguin logo looks like it is being rendered
> in about five colors.

Yipes. Imageblit sounds broken.

> In addition, the text is black, except for
> the white underscore cursor, so all I can see is the cursor.

I noticed this. The color palette is for some reason messed up.

> When the gpm gets loaded, the mouse pointer, instead of showing
> a white rectangle that, when it passes over a character, shows that
> character in reverse-video, shows a colored cursor that always
> contains some character.  The character shown in the mouse cursor
> changes when it passes over text in the window, but it never shows
> the character it is passing over.

Same things. Color palette is messed up.

> Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows
> a usable console window, but it is embedded in the larger high
> resolution display, like this:
>
> 	+---------+----------------+
> 	|	  |		   |
> 	|	  |		   |
> 	|	  |		   |
> 	+---------+		   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	+--------------------------+
>
> The area outside of the 640x480 boundary is filled with colored
> junk (no characters).
>
> Any ideas?

Yeap. I migrated changing the console from /dev/fb to actually using the
tty layer. I haven't merged those changes yet but you will be able to do a

stty -f /dev/ttyX 80 col 50 row

and change the video mode.

So I didn't plan to push so soon but I kept getting emails about various
drivers being broken. So I did this push to make more drivers work.
Unfortuenly I sent a watered down fbcon system.







-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Miles Lane]

James, I appreciate all your hard work.  I hope my bug report
isn't too upsetting for you.  I think you are making great progress.
It is also a shame that so much of the driver porting has fallen
on your shoulders.  If I were a programmer.  I'd help, but my skills
are in software testing, for the most part.

All the best,
	Miles

James Simmons wrote:
>>I have tried getting rivafb to work in 2.5.51.  It is much better
>>than before (thanks!).  It compiles and sorta works.
> 
> 
> Ug. Now that several drivers compile now I get bug reports :-( I'm getting
> alot of positive feedback as well as one negative source.
> 
> 
>>Here are the problems:
>>
>>When I run "fbset -a 640x480", I get display that fills
>>the screen and looks okay, but most of the characters are
>>flipped along the vertical axis, so they are backwards, so that:
>>
>>+----		    ----+
>>|			|
>>+---    becomes	     ---+
>>|			|
>>|			|
> 
> 
> Okay. That is weird. I have this card so I will give it a try.
> 
> 
>>Also, when I boot, the penguin logo looks like it is being rendered
>>in about five colors.
> 
> 
> Yipes. Imageblit sounds broken.
> 
> 
>>In addition, the text is black, except for
>>the white underscore cursor, so all I can see is the cursor.
> 
> 
> I noticed this. The color palette is for some reason messed up.
> 
> 
>>When the gpm gets loaded, the mouse pointer, instead of showing
>>a white rectangle that, when it passes over a character, shows that
>>character in reverse-video, shows a colored cursor that always
>>contains some character.  The character shown in the mouse cursor
>>changes when it passes over text in the window, but it never shows
>>the character it is passing over.
> 
> 
> Same things. Color palette is messed up.
> 
> 
>>Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows
>>a usable console window, but it is embedded in the larger high
>>resolution display, like this:
>>
>>	+---------+----------------+
>>	|	  |		   |
>>	|	  |		   |
>>	|	  |		   |
>>	+---------+		   |
>>	|			   |
>>	|			   |
>>	|			   |
>>	|			   |
>>	|			   |
>>	+--------------------------+
>>
>>The area outside of the 640x480 boundary is filled with colored
>>junk (no characters).
>>
>>Any ideas?
> 
> 
> Yeap. I migrated changing the console from /dev/fb to actually using the
> tty layer. I haven't merged those changes yet but you will be able to do a
> 
> stty -f /dev/ttyX 80 col 50 row
> 
> and change the video mode.
> 
> So I didn't plan to push so soon but I kept getting emails about various
> drivers being broken. So I did this push to make more drivers work.
> Unfortuenly I sent a watered down fbcon system.
> 
> 
> 
> 
> 
> 




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[James Simmons]

> James, I appreciate all your hard work.  I hope my bug report
> isn't too upsetting for you.  I think you are making great progress.
> It is also a shame that so much of the driver porting has fallen
> on your shoulders.  If I were a programmer.  I'd help, but my skills
> are in software testing, for the most part.

Thank you :-) Its getting there.




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Antonino Daplas]

On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> Hi,
> 
> I have tried getting rivafb to work in 2.5.51.  It is much better
> than before (thanks!).  It compiles and sorta works.
> 
> Here are the problems:
> 
> When I run "fbset -a 640x480", I get display that fills
> the screen and looks okay, but most of the characters are
> flipped along the vertical axis, so they are backwards, so that:
> 
> +----		    ----+
> |			|
> +---    becomes	     ---+
> |			|
> |			|
> 
What's the hardware, is it on a big endian machine? I think there's a
typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN).  This should
produce the "mirroring" effect.

Secondly, a lot of the changes there are for riva128, which may not
apply for all cards. Try doing fbset -accel false/true and see if
there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
and comment out the line with the FB_ACCELF_TEXT.  This should force the
hardware to do everything in software.  

> Also, when I boot, the penguin logo looks like it is being rendered
> in about five colors.  In addition, the text is black, except for
That's definitely a color map problem.

> the white underscore cursor, so all I can see is the cursor.
> When the gpm gets loaded, the mouse pointer, instead of showing
> a white rectangle that, when it passes over a character, shows that
> character in reverse-video, shows a colored cursor that always
> contains some character.  The character shown in the mouse cursor 
> changes when it passes over text in the window, but it never shows
> the character it is passing over.
> 
I get this with every framebuffer driver, so this is generic.

> Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows
> a usable console window, but it is embedded in the larger high
> resolution display, like this:
> 
> 	+---------+----------------+
> 	|	  |		   |
> 	|	  |		   |
> 	|	  |		   |
> 	+---------+		   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	|			   |
> 	+--------------------------+
> 
> The area outside of the 640x480 boundary is filled with colored
> junk (no characters).
Because changes done via fbset are not passed to fbcon anymore.  So
you'll see the display change, but fbcon still thinks it's still on
640x480.  I guess James will add some support for that via the console.

I'll test it myself too with a riva128 PCI.

Tony



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Miles Lane]

On Wed, 2002-12-11 at 04:49, Antonino Daplas wrote:
> On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> > Hi,
> > 
> > I have tried getting rivafb to work in 2.5.51.  It is much better
> > than before (thanks!).  It compiles and sorta works.
> > 
> > Here are the problems:
> > 
> > When I run "fbset -a 640x480", I get display that fills
> > the screen and looks okay, but most of the characters are
> > flipped along the vertical axis, so they are backwards, so that:
> > 
> > +----		    ----+
> > |			|
> > +---    becomes	     ---+
> > |			|
> > |			|
> > 
> What's the hardware, is it on a big endian machine? I think there's a
> typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN).  This should
> produce the "mirroring" effect.

CPU: AMD Athlon(tm) Processor stepping 01

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller (rev 25)

01:05.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256
DDR] (rev 10) (prog-if 00 [VGA])
        Subsystem: VISIONTEK: Unknown device 000b
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fd000000 (32-bit, non-prefetchable)
[size=16M]
        Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at feaf0000 [disabled] [size=64K]
        Capabilities: [60] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 2.0
                Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2,x4
                Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

> Secondly, a lot of the changes there are for riva128, which may not
> apply for all cards. Try doing fbset -accel false/true and see if
> there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
> and comment out the line with the FB_ACCELF_TEXT.  This should force the
> hardware to do everything in software.  

Thanks, I'll check this today.

	Miles




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Antonino Daplas]

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

On Wed, 2002-12-11 at 05:39, Miles Lane wrote: 
> Hi,
> 
> I have tried getting rivafb to work in 2.5.51.  It is much better
> than before (thanks!).  It compiles and sorta works.
> 
Can you test the attached patch (rivafb1.diff)?  It fixes some things: 

1. double ioremap/request_mem_region of the framebuffer memory.  Might
cause some initialization weirdness :-) 

2. riva_hw.c is outdated (no support for NV_ARCH_20) which will crash
the GeForce3's (I think I read one report of that in the  kernel mailing
list). 

3.  Matched the initialization ordering of rivafb in linux-2.4, except
that RivaGetConfig is executed at rivafb_open(). 

3. Not sure if the color problem will be fixed.  Miles, are you by
offchance using bpp > 8?  Because setting the DAC at 8 bpp should be a
very simple matter compared with directcolor which requires some
juggling acts 

Also, you mentioned that everything is okay except the characters are
mirrored in the vertical axis, is this correct?  Meaning colors are fine
etc.  If this is the case, try this patch also: 

diff -Naur linux-2.5.51/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.51/drivers/video/riva/fbdev.c	2002-12-12 13:59:07.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2002-12-12 13:59:30.000000000 +0000
@@ -917,9 +917,11 @@
 	size = width * h;
 	dat = cdat;
 
-	for (i = 0; i < size; i++) {
-		*dat = byte_rev[*dat];
-		dat++;
+	if (par->riva.Architecture == NV_ARCH_03) {
+		for (i = 0; i < size; i++) {
+			*dat = byte_rev[*dat];
+			dat++;
+		}
 	}
 
 	switch (info->var.bits_per_pixel) {

Tony

[-- Attachment #2: rivafb1.diff --]
[-- Type: text/x-patch, Size: 9901 bytes --]

diff -Naur linux-2.5.51/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.51/drivers/video/riva/fbdev.c	2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2002-12-12 13:58:05.000000000 +0000
@@ -916,6 +916,7 @@
 
 	size = width * h;
 	dat = cdat;
+
 	for (i = 0; i < size; i++) {
 		*dat = byte_rev[*dat];
 		dat++;
@@ -923,17 +924,11 @@
 
 	switch (info->var.bits_per_pixel) {
 	case 8:
-		fgx = image->fg_color | ~((1 << 8) - 1);
-		bgx = image->bg_color | ~((1 << 8) - 1);
+		fgx = image->fg_color;
+		bgx = image->bg_color;
 		
 		break;
 	case 16:
-		/* set alpha bit */
-		if (info->var.green.length == 5) {
-			fgx = 1 << 15;
-			bgx = fgx;
-		}
-        /* Fall through... */
 	case 32:
 		fgx |= par->riva_palette[image->fg_color];
 		bgx |= par->riva_palette[image->bg_color];
@@ -1169,6 +1164,9 @@
 		save_vga(&par->state);
 
 		RivaGetConfig(&par->riva);
+		CRTCout(par, 0x11, 0xFF);	/* vgaHWunlock() + riva unlock (0x7F) */
+		par->riva.LockUnlock(&par->riva, 0);
+
 		riva_save_state(par, &par->initial_state);
 	}
 	
@@ -1554,13 +1552,14 @@
 	info->display_fg = NULL;
 	info->pseudo_palette = pseudo_palette;
 
-	cmap_len = riva_get_cmap_len(&info->var);
-	fb_alloc_cmap(&info->cmap, cmap_len, 0);
 #ifndef MODULE
 	if (mode_option)
 		fb_find_mode(&info->var, info, mode_option,
 			     NULL, 0, NULL, 8);
 #endif
+	cmap_len = riva_get_cmap_len(&info->var);
+	fb_alloc_cmap(&info->cmap, cmap_len, 0);
+
 	return 0;
 }
 
@@ -1713,13 +1712,6 @@
 		goto err_out_free_base1;
 	}
 	
-	info->screen_base = ioremap(rivafb_fix.smem_start,
-				   rivafb_fix.smem_len);
-	if (!info->screen_base) {
-		printk(KERN_ERR PFX "cannot ioremap FB base\n");
-		goto err_out_iounmap_ctrl;
-	}
-	
 	default_par->riva.EnableIRQ = 0;
 	default_par->riva.PRAMDAC = (unsigned *)(default_par->ctrl_base + 
 						 0x00680000);
@@ -1744,6 +1736,25 @@
 
 	default_par->riva.IO = (MISCin(default_par) & 0x01) ? 0x3D0 : 0x3B0;
 
+	if (default_par->riva.Architecture == NV_ARCH_03) {
+		/*
+		 * We have to map the full BASE_1 aperture for Riva128's
+		 * because they use the PRAMIN set in "framebuffer" space
+		 */
+		if (!request_mem_region(rivafb_fix.smem_start,
+					rivafb_fix.smem_len, "rivafb")) {
+			printk(KERN_ERR PFX "cannot reserve FB region\n");
+			goto err_out_free_base0;
+		}
+	
+		info->screen_base = ioremap(rivafb_fix.smem_start,
+					 rivafb_fix.smem_len);
+		if (!info->screen_base) {
+			printk(KERN_ERR PFX "cannot ioremap FB base\n");
+			goto err_out_iounmap_ctrl;
+		}
+	}
+
 	switch (default_par->riva.Architecture) {
 	case NV_ARCH_03:
 		default_par->riva.PRAMIN = (unsigned *)(info->screen_base + 
@@ -1767,17 +1778,23 @@
 
 	info->par = default_par;
 
-	if (!request_mem_region(rivafb_fix.smem_start,
-				rivafb_fix.smem_len, "rivafb")) {
-		printk(KERN_ERR PFX "cannot reserve FB region\n");
-		goto err_out_free_base0;
-	}
+	if (default_par->riva.Architecture != NV_ARCH_03) {
+		/*
+		 * Now the _normal_ chipsets can just map the amount of
+		 * real physical ram instead of the whole aperture
+		 */
+		if (!request_mem_region(rivafb_fix.smem_start,
+					rivafb_fix.smem_len, "rivafb")) {
+			printk(KERN_ERR PFX "cannot reserve FB region\n");
+			goto err_out_free_base0;
+		}
 	
-	info->screen_base = ioremap(rivafb_fix.smem_start,
-				 	  rivafb_fix.smem_len);
-	if (!info->screen_base) {
-		printk(KERN_ERR PFX "cannot ioremap FB base\n");
-		goto err_out_iounmap_ctrl;
+		info->screen_base = ioremap(rivafb_fix.smem_start,
+					    rivafb_fix.smem_len);
+		if (!info->screen_base) {
+			printk(KERN_ERR PFX "cannot ioremap FB base\n");
+			goto err_out_iounmap_ctrl;
+		}
 	}
 
 #ifdef CONFIG_MTRR
diff -Naur linux-2.5.51/drivers/video/riva/riva_hw.c linux/drivers/video/riva/riva_hw.c
--- linux-2.5.51/drivers/video/riva/riva_hw.c	2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/riva_hw.c	2002-12-12 13:17:40.000000000 +0000
@@ -41,7 +41,7 @@
  * GPL licensing note -- nVidia is allowing a liberal interpretation of
  * the documentation restriction above, to merely say that this nVidia's
  * copyright and disclaimer should be included with all code derived
- * from this source.  -- Jeff Garzik <jgarzik@pobox.com>, 01/Nov/99 
+ * from this source.  -- Jeff Garzik <jgarzik@mandrakesoft.com>, 01/Nov/99 
  */
 
 /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/riva_hw.c,v 1.8 2000/02/08 17:19:11 dawes Exp $ */
@@ -1220,6 +1220,7 @@
             state->repaint1 = hDisplaySize < 1280 ? 0x04 : 0x00;
             break;
         case NV_ARCH_10:
+	case NV_ARCH_20:
             nv10UpdateArbitrationSettings(VClk, 
                                           pixelDepth * 8, 
                                          &(state->arbitration0),
@@ -1285,6 +1286,7 @@
             chip->Tri05 = (RivaTexturedTriangle05 *)&(chip->FIFO[0x0000E000/4]);
             break;
         case NV_ARCH_10:
+	case NV_ARCH_20:
             /*
              * Initialize state for the RivaTriangle3D05 routines.
              */
@@ -1393,6 +1395,7 @@
             chip->PGRAPH[0x0000067C/4] = state->pitch3;
             break;
         case NV_ARCH_10:
+	case NV_ARCH_20:
             LOAD_FIXED_STATE(nv10,PFIFO);
             LOAD_FIXED_STATE(nv10,PRAMIN);
             LOAD_FIXED_STATE(nv10,PGRAPH);
@@ -1421,15 +1424,31 @@
                     chip->Tri03 = 0L;
                     break;
             }
-            chip->PGRAPH[0x00000640/4] = state->offset0;
-            chip->PGRAPH[0x00000644/4] = state->offset1;
-            chip->PGRAPH[0x00000648/4] = state->offset2;
-            chip->PGRAPH[0x0000064C/4] = state->offset3;
-            chip->PGRAPH[0x00000670/4] = state->pitch0;
-            chip->PGRAPH[0x00000674/4] = state->pitch1;
-            chip->PGRAPH[0x00000678/4] = state->pitch2;
-            chip->PGRAPH[0x0000067C/4] = state->pitch3;
-            chip->PGRAPH[0x00000680/4] = state->pitch3;
+
+	    if (chip->Architecture == NV_ARCH_10) {
+            	chip->PGRAPH[0x00000640/4] = state->offset0;
+            	chip->PGRAPH[0x00000644/4] = state->offset1;
+            	chip->PGRAPH[0x00000648/4] = state->offset2;
+            	chip->PGRAPH[0x0000064C/4] = state->offset3;
+            	chip->PGRAPH[0x00000670/4] = state->pitch0;
+            	chip->PGRAPH[0x00000674/4] = state->pitch1;
+            	chip->PGRAPH[0x00000678/4] = state->pitch2;
+            	chip->PGRAPH[0x0000067C/4] = state->pitch3;
+            	chip->PGRAPH[0x00000680/4] = state->pitch3;
+	    } else {
+		chip->PGRAPH[0x00000820/4] = state->offset0;
+		chip->PGRAPH[0x00000824/4] = state->offset1;
+		chip->PGRAPH[0x00000828/4] = state->offset2;
+		chip->PGRAPH[0x0000082C/4] = state->offset3;
+		chip->PGRAPH[0x00000850/4] = state->pitch0;
+		chip->PGRAPH[0x00000854/4] = state->pitch1;
+		chip->PGRAPH[0x00000858/4] = state->pitch2;
+		chip->PGRAPH[0x0000085C/4] = state->pitch3;
+		chip->PGRAPH[0x00000860/4] = state->pitch3;
+		chip->PGRAPH[0x00000864/4] = state->pitch3;
+		chip->PGRAPH[0x000009A4/4] = chip->PFB[0x00000200/4];
+		chip->PGRAPH[0x000009A8/4] = chip->PFB[0x00000204/4];
+	    }
             chip->PGRAPH[0x00000B00/4] = chip->PFB[0x00000240/4];
             chip->PGRAPH[0x00000B04/4] = chip->PFB[0x00000244/4];
             chip->PGRAPH[0x00000B08/4] = chip->PFB[0x00000248/4];
@@ -1607,6 +1626,7 @@
             state->pitch3   = chip->PGRAPH[0x0000067C/4];
             break;
         case NV_ARCH_10:
+	case NV_ARCH_20:
             state->offset0  = chip->PGRAPH[0x00000640/4];
             state->offset1  = chip->PGRAPH[0x00000644/4];
             state->offset2  = chip->PGRAPH[0x00000648/4];
@@ -1970,6 +1990,7 @@
             nv4GetConfig(chip);
             break;
         case NV_ARCH_10:
+	case NV_ARCH_20:
             nv10GetConfig(chip);
             break;
         default:
diff -Naur linux-2.5.51/drivers/video/riva/riva_hw.h linux/drivers/video/riva/riva_hw.h
--- linux-2.5.51/drivers/video/riva/riva_hw.h	2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/riva_hw.h	2002-12-12 13:17:42.000000000 +0000
@@ -41,7 +41,7 @@
  * GPL licensing note -- nVidia is allowing a liberal interpretation of
  * the documentation restriction above, to merely say that this nVidia's
  * copyright and disclaimer should be included with all code derived
- * from this source.  -- Jeff Garzik <jgarzik@pobox.com>, 01/Nov/99 
+ * from this source.  -- Jeff Garzik <jgarzik@mandrakesoft.com>, 01/Nov/99 
  */
 
 /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/riva_hw.h,v 1.6 2000/02/08 17:19:12 dawes Exp $ */
@@ -75,6 +75,7 @@
 #define NV_ARCH_04  0x04
 #define NV_ARCH_10  0x10
 #define NV_ARCH_20  0x20
+
 /***************************************************************************\
 *                                                                           *
 *                             FIFO registers.                               *
diff -Naur linux-2.5.51/drivers/video/riva/riva_tbl.h linux/drivers/video/riva/riva_tbl.h
--- linux-2.5.51/drivers/video/riva/riva_tbl.h	2002-12-12 13:57:09.000000000 +0000
+++ linux/drivers/video/riva/riva_tbl.h	2002-12-12 13:17:42.000000000 +0000
@@ -41,7 +41,7 @@
  * GPL licensing note -- nVidia is allowing a liberal interpretation of
  * the documentation restriction above, to merely say that this nVidia's
  * copyright and disclaimer should be included with all code derived
- * from this source.  -- Jeff Garzik <jgarzik@pobox.com>, 01/Nov/99 
+ * from this source.  -- Jeff Garzik <jgarzik@mandrakesoft.com>, 01/Nov/99 
  */
 
 /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/riva_tbl.h,v 1.5 2000/02/08 17:19:12 dawes Exp $ */

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[James Simmons]

> Can you test the attached patch (rivafb1.diff)?  It fixes some things: 

I tested the patch. The colors are still messed up :-( I'm running at 8 
bpp mode. I applied the patch since it fixed some important things. 
I also add support and more functionality. I still have some to go.
 



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Antonino Daplas]

On Fri, 2002-12-13 at 10:09, James Simmons wrote:
> 
> > Can you test the attached patch (rivafb1.diff)?  It fixes some things: 
> 
> I tested the patch. The colors are still messed up :-( I'm running at 8 
> bpp mode. I applied the patch since it fixed some important things. 
> I also add support and more functionality. I still have some to go.
>  
I'm confused too :-(.  If I'm going to expect color problems, it's not
at bpp8 since you don't really do anything except write to the DAC.  And
the fact that the driver works perfectly for the Riva128 (nvidia's first
chipset) makes me wonder even more.  Currently, I'm running everything
with the riva128, directfb, xfbdev, even the xgamma utility works,
flawlessly.

The only thing I can think of that we're doing differently from the 2.4
driver is the save_vga() part in rivafb_open.  Perhaps touching the vga
registers somehow confuses the hardware.  Unlikely, but maybe worth a
try.

How extensive is the color problem?  Does it just affect the logo, or
everything? Also, is the color problem present in both hardware and
software mode (just do fbset -accel true/false to find out)?  Is the
vertical mirroring as reported by Miles still present?  How about bpp16
or bpp32?

How I would love to debug that,  but I don't have the hardware :-(

Tony 




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).

[Miles Lane]

On Friday, December 13, 2002, at 01:34  AM, Antonino Daplas wrote:
> How extensive is the color problem?  Does it just affect the logo, or
> everything? Also, is the color problem present in both hardware and
> software mode (just do fbset -accel true/false to find out)?  Is the
> vertical mirroring as reported by Miles still present?  How about bpp16
> or bpp32?

I have had mixed results with 2.5.51 (vanilla).  I have booted
once where I didn't see the mirroring.

I have not had a chance to test your patch.  Hopefully I'll have
time tomorrow.  Sorry for the delay.

	Miles



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/