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

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

On Mon, 19 Jul 1999, Brent Fulgham wrote:

> Jon,
> 
> Thanks for the info.  I'll play with it this evening when I get 
> home and see if I can come up with anything.
> 
> > 
> > 	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?
> >  
> Hmm.  I am at a bit of a disadvantage here because I am fairly
> red-green color deficient.  So, I may be able to notice a shift in
> intensity but may not be able to provide a true reading of the "color".
> 
> Sorry! :-)

	No problem.  The debugging dumps should show us anyway.
 
> > > 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.
> >  
> 
> Should I stick with the data in the header files as present in CVS
> or continue using nVidia's version?

	Stick with the existing one, it should work.  I had it working on 
a RIVA128 back around the beginning of the year....
 
> > 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.
> > 
>
> Sorry to have to ask this, but when you refer to "register dumping" I
> assume you mean the registers in the graphic card itself, rather than
> the system's processor, right?  

	Right.

> If so, I'm not sure how to go about
> dumping these items.  

	Call the register-dumping functions within the driver.  All the 
low-level I/O handling is already written, all you should need to do is 
make use of it.

> I don't have much experience debugging device
> drivers -- I assume I can't just pull up gdb and read the registers.

	Unless the driver exposes the memory-mapped registers to 
userspace (which AFAIK it doesn't), you can't.  You either have to have 
the driver do it for you as described above, or hack up an suid root 
program that will read them out of /dev/mem.  The former is usually a lot 
easier.
 
> Am I to assume that the source generally has a routine someplace that
> will handle the dump if I enable it somehow?

	Yes.  IIRC, the nVidia driver already saves a copy of the initial 
register values so that the original mode can be restored when removing 
the driver, and it has to save the register values it programs itself to 
set modes, so you should just be able to do two dumps of those data 
structures and compare them.

Jon

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