I'm currently working on getting complete support for Geforce FX for RivaFB.
Thanks to X's open source NV module, I have already gotten it to work
completely for monitor. I am still having trouble with TV out though. The
only working reference I have for that though is the binary, closed source,
official Nvidia X module.
I know very little about kernel hacking, the support that I got working at all
was mostly by pure guessing and trial and error. I would like some advice
about what actions I should take next in getting more complete support.
- ods15
On Wed, 2004-11-24 at 23:47 +0200, Oded Shimon wrote:
> I'm currently working on getting complete support for Geforce FX for RivaFB.
> The
> only working reference I have for that though is the binary, closed source,
> official Nvidia X module.
>
> I would like some advice
> about what actions I should take next in getting more complete support.
Are you asking "how do I reverse engineer a binary driver"? One method
is to run it under an emulator, and capture the PCI bus traffic. Then
there are tried and true methods like IDA Pro.
Lee
On Sunday 28 November 2004 00:01, Lee Revell wrote:
> Are you asking "how do I reverse engineer a binary driver"? One method
> is to run it under an emulator, and capture the PCI bus traffic. Then
> there are tried and true methods like IDA Pro.
>
Well, I was sort of hoping there might be something better/easier than working
on the binary driver (which btw is illegal.. oh well :).
Like I said I know very little about kernel hacking, this is really my first
experience with it ever. I know simple wrapper C, I'm new at low level
programming.
I have heard of IDA Pro, its a disassembler to COBOL, right?
If I go down the emulator idea, how do I do that?... could you give me a good
starting point to continue from or link me to a good guide?...
- ods15
On Friday 04 March 2005 00:53, Alan Jenkins wrote:
> Having a GeForce FX 5200 which I expected to work under rivafb (kernel
> version 2.6.11), I found the attached message on google groups.
>
> I know it is a little later now, but would you think about getting the
> work you've done committed?
>
> I recognise that updating the driver to work with more recent kernels
> would involve a reasonable amount of work. I don't need the driver
> personally (although it would be nice). I wouldn't be able to take
> advantage of TV out either, but if you can get the code into the kernel
> then more people are likely to look at it.
>
> If you're not going to do anything, could you send me the latest
> version? I don't promise to do anything but as a student I should have
> the time to do so. Actuall skill is another matter :)
Wow, it's been ages.. I eventually stopped caring about this patch because i
realized with my skills TV out would be utterly impossible, which was very
important for me.. So for now I am STILL using VesaFB and the binary nvidia X
driver...
The patch I did prepare were a few strategic copy pastes from the X "nv"
driver which "works" (without TV out) for Geforce FX... I hardly understand
at all what I have done (hardware, just ain't my thing :).
You're free to have the patch though.. I'd advise cleaning it up though, there
is still some debugging stuff in there...
Also, this is actually a common trait for Any rivafb output, the cursor is
horribly broken.. I had a hack in the patch to fix this, but this probably
not welcome for the official driver...
- ods15
On Friday 04 March 2005 01:03, Oded Shimon wrote:
> - ods15
Oops.
Query: register vpllB
I have a question about your patch: you added chip->vpllB and
chip->vpllB2 (presumably taken from the X driver). Do you know their
purpose, and did you find them to be necessary or useful?
Possible patch to add supported cards
I discovered that since your patch, some changes have been made to
support GeForce FX chips (which are classified as NV_ARCH_30), but the
only one recognised by the driver is the GeForce FX GO 5200 (the name
may be slightly mangled). I can get the driver to work on my card just
by adding it to the list of supported cards (altering
drivers/video/riva/fbdev.c and include/linux/pci_ids.h of 2.6.11).
The driver comments suggest that NV_ARCH_30 is applicable to the 5200,
5600, 5700, 5800 and 5900. As far as I can tell the actual code would
apply this classifaction to all GeForce FX cards, including the GeForce
FX Go series, and also the Quadro FX series.
My opinion is that theres no point in having the code there but not
letting people try it. I'd like to add every single card which would be
classified under NV_ARCH_30, taking them from the X driver
(hw/XFree86/drivers/nv/nv_driver.c), with a configuration warning that
rivafb has not really been tested on these cards. If nobody has any
objections I'll send a patch.
Additional information
I do see a cursor related problem, but I don't think its the same one
you describe. On the framebuffer console, sometimes when the cursor
moves the character at the new cursor position will be displayed at the
old position for a very short period of time.
EDID/DDC fails (it works with my monitor under X), and acceleration has
been disabled.
There are problems with some screen modes, particularly on 800x600-90
and 1024x768-43-lace. The screen wraps, so that about an 8th of the
left hand side appears on the right hand side instead, and there is
additional corruption (there seem to be pixels in the wrong places, but
colours are not affected).
My computer locked up during a console switch (X to console) with linux
rivafb, X framebuffer and X nv running.
Some rivafb debug output during boot:
rivafb: nVidia device/chipset 10DE0322
rivafb: Detected CRTC controller 0 being used
rivafb: RIVA MTRR set to ON
riva_get_EDID START
riva_get_EDID_i2c START
riva_get_EDID_i2c END
rivafb: could not retrieve EDID from DDC/I2C
riva_get_EDID END
riva_update_default_var START
riva_update_default_var END
riva_set_fbinfo START
rivafb: disabling acceleration
riva_set_fbinfo END
rivafb_check_var START
rivafb_do_maximize START
rivafb: setting virtual Y resolution to 209715
rivafb_do_maximize END
rivafb_check_var END
rivafb: PCI nVidia NV32 framebuffer ver 0.9.5b (128MB @ 0xC0000000)
rivafb_probe END
rivafb_open START
riva_save_state START
riva_save_state END
rivafb_open END
rivafb_release START
riva_load_state START
riva_load_state END
rivafb_release END