Not a new user but been away awhile; only lurking.
Is this thread partly a discussion as to why it most likely does not work and how to get it working from a hobbyist perspective, or is it just reserved to those seeking a solution and willing to pay for it?
I'm a bit more interested in the former, and I've only seen two threads that seem to look at things from that perspective but no active work arounds, or mention of workarounds.
While I own several Macs from old Powerbooks and G4s to a modern Intel MacMini and Macbook, I do have a PC with this build.
It's an HP G72-B60 with Intel Core i3, 4GB RAM and GMA5700 that for kicks/increasing my knowledge I installed OSX on to see if it was possible (I've done it before a few years back, with different desktop HW) and potentially figure out if other devices with undefined driver support can be made to work with my existing "real" Macs.
Since I decided to use a copy of 10.6 I bought it was a bit harder than I anticipated; apparently there is a later Snow Leopard retail disk that has 10.6.x updates. I went with what I bought and eventually I got it to work.
Everything works save for the traditional culprits: NIC, Broadcom wireless/bluetooth combo PCIe card and accelerated video. The Broadcom combo card is intriguing to me, because I'd like to use it elsewhere.
Regarding the video, since there are no Core based Macs that ship with GMA5700 as the sole video accelerator this seems a bit difficult, but I don't see the need to go through buying laptops and such.
I know I'm rehashing a bit, but the signaling that I see when loading the IntelHDGraphics.kext files leads me to believe that the timing expected is different, and this can be changed without hardware modification. It's a matter of changing definitions in the kexts.
There's a few paths here:
-Using the released Intel sources and Xcode, compile a driver and then bind that appropriately to the upper layers of the OS.
-Bypass the accelerated co-dependency on the Nvidia within the existing Intel HD driver
-Find a substitute kext/driver that will provide similar if not complete functionality.
You don't need to disassemble anything to do any of these, because the hardware that is causing the problem is not present. you just need to identify the call to the absent hardware.
Since most of you have the affected laptop architecture, and there are two expansive threads that begin to explore how that works, I'm at a loss why there hasn't been more of an effort to get this done for the challenge of doing it, versus expecting a handed over end result.
However, if you know of an active thread or users willing to toss in on that effort, I might throw in on that.