From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 19 Jul 1999 12:51:48 -0700 (PDT)

Re: Request for Assistance: Anyone with RIVA128 kgicon success?

On Mon, 19 Jul 1999, Brent Fulgham wrote:

> I have working FB-level support for my RIVA128 card (Diamond MM Viper 330).
> I can start my system in a variety of color depths and resolutions.  The
> LIBGGI examples all work fine.
> 
> I attempted to compile and use a RIVA128-based kgicon module, but was
> unsuccessful.
> 
> Can someone who has a working RIVA128 kgicon get in contact with me?

	I have a TNT2 and not a Riva128, but I can try....
 
> I observed the following:
> 
> 1.  Hardare detection in the kgicon build process identified my card
> correctly.
> 2.  I build using a generic-generic monitor, and when I insmod the module,
> my screen
> goes "blank" and I have to reboot.  Removing the module does not reset the
> screen.
> I can start X when the screen is "blanked" and this works, but as soon as I
> leave X
> I return to the "blank" screen.

	Sounds like bad clock synthesis.  Often when this happens, the green 
light on the front of youyr monitor will turn amber to indicate that the 
frequency limit of the monitor has been exceeded.  Does this occur?
 
> The screen is not really "blank", but rather seems to be a light grey.  I
> can also hear
> a high-pitched noise from my monitor, consistent with a bad setting for
> screen refresh or similar.  If I do an alt-F2/3/4 I sometimes get slightly
> different colors (i.e., usually
> a green color or sometimes a blue background).

	Hm.  I was seeing that with TNT2, but I managed to fix it and the
latest commits I made should reflect that.  Perhaps it was a different 
problem, but the green/blue thing sounds pretty distinctive.
 
> I do not see text, or even "ASCII Graphic" text.  I see no on-screen
> indication that I am typing, although the system responds correctly (starts
> X, reboots the system, etc.)
> 
> 3.  If I capture STDOUT/STDERR to a file (and read it after rebooting) I see
> that the 
> RIVA128 support module has been loaded, and it correctly identifies the
> memory available to the card (4 Megs).

	Recompile with DEBUG_LEVEL=255 in all driver sourcefiles (chipset, 
ramdac, clockchip) and look at /var/log/messages.
 
> 4.  Copying the kgicon.o modules to another name (kgicon2.o) and installing
> after the first, then removing does not work (contrary to some reports in
> the mailing list archives).
> 
> 5.  Recompiling kgicon.o using my monitors' specific settings does not
> change matters.
> 
> 6.  Booting into a vga mode (instead of a text mode as previous) does not
> change the behavior of the card.  Neither does starting/stopping X before
> insmoding the card.
> 
> 7.  I notice that the header files used in the kgicon source do not reflect
> the most recent versions provided by nVidia.  I swapped these files out, but
> did not observe any benefit.

	Yeah, it sounds like the problem is something else.
 
> Can someone knowledgable either:
> 1)  Let me know what I am doing wrong.
> -or-
> 2)  Provide me with some data to help me isolate and debug the cause.

	The best help would be to get detailed debugging dumps like I
described above and look through those.  Also, one trick I use a lot when I
can't get to first base with a driver is to modify it so that it loads and
does a full register dump before and after the initial modeset. anything.  I
then load the driver on top of vesafb so that I can compare the two register
dumps - usually the differences will jump right out.  All of the
infrastructure to do this should be in the driver code already - if not, I
have some generic KGI register-dumping code I can easily adapt.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed