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

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/

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

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

Yipes. Imageblit sounds broken.

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

Same things. Color palette is messed up.

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/

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

-------------------------------------------------------
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/

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/

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.

That's definitely a color map problem.

I get this with every framebuffer driver, so this is generic.

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/

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>

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/

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
@@ -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

diff -Naur linux-2.5.51/drivers/video/riva/riva_hw.h linux/drivers/video/riva/riva_hw.h
@@ -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 <[email protected]>, 01/Nov/99 
+ * from this source.  -- Jeff Garzik <[email protected]>, 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
@@ -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 <[email protected]>, 01/Nov/99 
+ * from this source.  -- Jeff Garzik <[email protected]>, 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 $ */

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/

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/

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/