Jump to content

Help me hack Nvidia drivers (for shared memory users)


29 posts in this topic

Recommended Posts

OK so here's a question for a developer. Lets just say that someone is crazy/brave/stupid enough (your choice) to hack NVDAResman, IONdrv, NVDANV50HAL and GeForce kexts with a hex editor. I think the (hex) string I am searching for in those respective kexts is "000002440000". Can I just replace any occurence with the value for my card?


Should I be looking for a specific offset? Is there some occurence of that value that I should not be changing? Is there anything else I need to change?






Please reference this thread:


Post number 80.


Complete guide to hacking the NVIDIA drivers as far as I can take them.

Link to comment
Share on other sites

the value for my card (the PCI ID) is 0247 and I am trying to hack the aforementioned executeables to support my unsuppported graphics card. :)


That is my hope anyway.


Yes, I know that shared memory cards are unsupported, but I have some other hacks that I would like to try in combination with the hacked kexts to see if I can get it to work.


I know, they have never worked, and they probably never will, but I'm ok with beating my head against the wall until I have nothing left but a bloody stump of a neck before I give up.





Link to comment
Share on other sites

There does appear to be a matching list inside the executeable. In addition, this post (which is old) references Arti's NVDAResman which changes ID's within the NVDAResman executeable.




Is there source for these drivers I can look at? Is the ROM revision part of the equation? Should I be looking for 0247+<rom revision id>?



Link to comment
Share on other sites

ok i got the latest (.41) nvidia drivers to work with my 6100. everything loads fine, but I am stuck at 1024x768 with no QE/CI.

Kernel parm: maxmem=1791










Hacked them by using 0xED and replaced 00000244 (geforce 6100) with 00000247 (geforce 6100 go). Sometimes you have to shorten (remove leading 00's a pair at a time) or lengthen (add trailing 00's in pairs) the string in order to get it to match anything. If you are unsure what you are doing, dont. Wait. It should not be that long before this is fixed permanently.


2nd hack (at least if you are using PCEFI) is you have to change two lines in NVDAResman Info.plist file.

The first is in IOKitPersonalities/NvidiaRM/IONameMatch/1






The second is in IOKitPersonalities/NvidiaRMTwinView/IONameMatch/1






3rd hack

You must edit all appropriate Info.plist files and put your card's PCI ID in them, as you would with any normal install.


I can boot all the way through without hanging, but I am stuck at 1024x768 with no QE/CI. And I need to modify my inject string, because somehow the NVCap value I included is mirroring the 1024x768 on my external display.


But at least the drivers load. Which is a BIG step forward, as far as I know.


Does anyone know if any of the included bundles (like GeForceGA.bundle) need to be hacked in order to enable QE/CI?


The one message in my startup log that indicates that everything is not 100% cool is:


kernel[0]: NVDA rmStart failed


Which kext generates this message? does anyone know? EDIT NVDAResman is responsible.


Does IONDrvSupport also need to be hacked?


I can supply my hacked drivers for educational purposes. Right now, they have only been modified to work on 6100 go.


Oh, to get the PCEFI to work, I took the 7600go hex and renamed it 6100go converted it to XML and edited it appropriately, then generated a string which i placed in the boot.plist files (I have several premade since I screw things up all the time and I am lazy and dont want to re-type all the kernel parms) If you want to see those, you are of course welcome to them as well.


Thanks for your help. Hopefully, with enough heads working on this we can get it running in a matter of days.


Also, if anyone wants to try the hacks with injectors instead of PCEFI, I would appreciate you experimenting and posting the results.





Link to comment
Share on other sites

This is really interesting. I'm willing to try this - can you post your NVDAResman ? To begin with - lets see if we can get native resolutions going.

Can you post your ioreg also ? It'll be interesting to see what the differences are with the MacVidia driver.


Good going !

Link to comment
Share on other sites

Im going to put together a guide on how to hack RESMAN in just a few mins. I will post it in the real QE/CI shared memory thread.


In the meantime, attached are 2 IOreg's that I just took from my machine. I am still experimenting with NVCAP values to see if I can get proper resolutions. I think that is what my issue is right now. I cant get past 1024x768 because resman does not recognise my monitor.


I'll send you a PM when I have the guide posted in the other thread.



Link to comment
Share on other sites

Hi spacklewoof, sorry but I don't understand. As far as I understand, you did all this for no result at all, so what's the benefit of following that tuto ? Am I missing something ? What does it do that the default VESA mode doesn't ?

Link to comment
Share on other sites

As I stated in the guide, it is:

1> Proof of concept. It can be done. Despite what everyone else says.

2> Others can add to it and maybe between all the great minds here we can figure out what the last few missing pieces are.

3> It is entirely possible that the only reason i cant get it to work is because I still have not figured out a valid NVCap for my card.


It has no benefits over VESA currently. I'm looking for help to put the final pieces of the puzzle together.


Any help you can provide would also be greatly appreciated.


Did I do something obviously wrong?


Do you know something about the QE/CI that I dont?


Maybe that framework should be hacked?


If QE/CI depends entirely on OpenGL, then maybe the OpenGL frameworks should be looked at.


Maybe the QuickDraw library.


Perhaps there is another library that is involved that I do not know about. I did not check the dependencies of all the involved objects. Maybe that should be my next step.


See, you helped already.





You also get access to my exclusive, totally awesome, completely original, never been seen before, never been done before, outstanding, amazing and delightful scripts and boot plists. Well worth the cost of the download and worth 1000 times more than what you paid for them. Even if you throw the rest of the guide away. Not to mention the ultra exclusive copies of my ioreg outputs. Available now, here only!


Lets see....1000 x $0.00 = HEY WAIT A SEC!

Link to comment
Share on other sites

1> Proof of concept. It can be done. Despite what everyone else says

But what can be done ?


According to what I see you associated/matched some things with some others, with no result.

Really no offense I just don't get what you are trying to do, and what you proved so far.

Anyway, I don't despair, if you are on something I just wait for the next :wacko:


About the NVCAP, it can't be the reason for your lack of acceleration, the NVCAP only controls the display output signal. So it's not related except some RARE cases where the NVCAP is invalid and "kills" any support.


My answer would simply be that it doesn't work because you messed up everything and/or your GFX isn't supported, hence my difficulties to understand the proof of something when it looks like you got no result.


Isn't your GFX supported with the good'ol methods aka NVinjectGo+correct device IDs ?


Maybe you sould simply clarify what you want to do and what you managed so far, before getting into a tutorial.

Link to comment
Share on other sites

OK, Dont laugh.

My ultimate goal is to be able to play Toontown (please stop laughing) on my hackintosh.

To accomplish this goal, I must get the video drivers on my laptop working with QE/CI.

In pursuit of that goal, I have tried many different driver combinations.

I have tried MacVidia, and that gave me resolution support, but no QE/CI and it severly crippled my OGL performance.

The stock NVidia drivers do not work with cards that only use shared memory (I.E. Memory taken away from the operating system for use with the video adapter.)


There is a thread on this very issue right here on insanely mac.



It is a long-time known issue with shared memeory video cards. Since we cant use the stock NVIDIA drivers, we have no driver support for QE/CI. We are forced to use the year and a half old MacVidia version 1.0.7 and all that gets us is native resolution support, no QE/CI and crippled OGL performance .


People on the other thread have been clamoring for quite a while for this. So, rather than complain about it, I am trying to do something about it.


The Ultimate goal for that thread is to get the stock NvIDIA drivers to work with shared memory video cards. Since that is not possible, the next best thing would be to come up with a repeatable procedure for hacking the stock NVidia drivers for use with shared memory video cards.


The guide I wrote gets us closer to that goal. But I have not reached it yet. I am putting out what I have been able to accomplish in the hopes that someone like you or gotoh or macgirl can say "Oh yeah,you can also find a lookup table in the XYZ kext/framework/bundle/plugin. Be sure to change values there too."


When that finally gets done, I'll be in ToonTown nirvana. If you think the idea of me playing toontown is silly, consider this: I'm 41 years old.


When you have picked yourself up off the floor after reading the last sentence, I would like to say that I want to give something back to the community that has made all of this possible. My contribution (I hope) will be video drivers that can work with shared memory, and eventually a package or program that will patch the stock NVIDIA for us, so that shared memory video card users dont end up in a macvidia type situation ever again. Forced to use crippling drivers that function at only the most basic level. Even worse performance than VESA support alone, but with resolution support that is so tempting that many are willing to put up with the crippling performance it causes.


Toontown is an OGL appllication written in Panda3D. Toontown refuses to launch on my machine right now, because the OGL support is broken. The OGL is broken because the NVidia drivers dont work with shared memory.


toontown exits withe the message:

:display:osxdisplay(error): osxGraphicsStateGuardian::buildG Error Getting Pixel Format


On the panda3d board, they indicate that this is a video driver issue.


So, here I am. Trying my hardest to make shared memory NVIDIA cards work.





Link to comment
Share on other sites

Ok, I had already got that you wanted to have QE/CI with shared memory GFX, but I'm still in the smoke about the content of your tuto. I still don't see the proof of what's possible :D

So, after looking a bit, I see that you change an hardcoded ID, change some IOReg names to match them differently, add a maxmem parameter + all the usual tricks.


So here's what I think about it :


-Changing the hardcoded ID : useless, it only sets a different renderer, which seems it's not what's preventing those boards from working so far.


-IOReg values : useless, that just bypasses the NVMac "display server" to directly match the displays with some other values upper in the tree, which can IMO only be worse since some other required values may be missing at this level, or simply not matched with what they belong with (especially display B )


-maxmem=1919. Actually I have no idea about this one, but I think doing something with the memory is a better track to follow.

To me, if there's a solution somewhere, it's inside lowlevel stuff related to chipset/PCI bus/system memory handling. There are big chances that those nvidia kexts would work perfect if the memory was recognised as "usual" video memory, so messing with them is probably pointless. Afaik, the kext that does this kind of lowlevel IO stuff is geforce.kext


PS : I see you mess with geforce 8 and other models kexts, don't make things more complicated you can trash those (GeForce8xxxGLDriver.bundle, NVDANV10Hal.kext, NVDANV20Hal.kext, NVDANV30Hal.kext, NVDANV50Hal.kext)

Link to comment
Share on other sites

Since there is no render in the kexts at all for PCI ID 0247, that is why I am doing all the searching and replacing inside the executables. to give the renderer a path to follow.


They left out ID's for 0247 and a lot of other cards.


0244=GEForce 6100 and there is a path for that card.

0247=GEForce 6100 Go and there is no render path for this card in any of the kexts. I might as well be running VESA.


Thus, the manual searching and replacing of 0244 to 0247. Since I cant easily change the card's ID, I'm hacking the software to match the card.


Believe it or not, the 6100 is a C51 based engine. (BIOS attached) and there are many occurrences of 000002440000 in all of the HAL's. Including NVDANV50Hal.kext. That is why I hacked them too.




Thanks for the tip on GEForce.kext. That is the EXACT kind of information I am looking for. Hints to help me fill in the missing pieces of the puzzle and hopefully make the guide complete.


We are getting closer to completion. Thanks for your help!



Link to comment
Share on other sites

i think if u hack the ati driver like what u did for nvdaresman and othrs with some extra work...we will get all right...like what the alex pointed to..but dont know which is the ati shared card is similar (equivalent) to these nvidia shared cards....but there is a problem the register adresses are completly different if they changed then can get qe/ci :) ....i dont know much in these things but gave u just a suggestion...

Link to comment
Share on other sites

  • 2 months later...
  • 3 months later...

  • Create New...