Primary Thanks to bcc9, how did you find this fix?
The information comes from reading the code. You can disassemble (or better, decompile) the code, and look at the logic used in and around the references to the various ioregistry information, (such as os-info under 10.6). To be able to reconstruct the references in higher level logic, it helps to have a software engineering background, and considerable c and c++ programming experience.
After having already done analogous detective work for the osx radeon hd driver, http://www.insanelym...howtopic=249642
the intel sandy bridge driver was actually a simpler case.
A partial recap from the parent thread:
Per this post:http://www.insanelym...p...t&p=1686937
I saw that AppleIntelSNBGraphicsFB checks the platform ID against a whitelist, and falls over to a generic case if there is not a match. The whitelist is just a list of sandy bridge product ids, which can be set via the SMboardproduct key in smbios.plist
In the routine AppleIntelSNBGraphicsFB::getPlatformID(), the platform IDs are mapped to indexes into the PlatformInformationList table. With the macbookpro8,1 value I posted, the index is 0, and I get 4 usable display connectors (as seen under system profiler). Other sandy bridge platform IDs map to indexes 1 thru 5, and with those, I achieve 0 or 3 connectors (where 0 connectors means no working display at all).
The intel driver seems to be treating platform IDs a lot like the ATI driver treats personality names (Vervet, Uakari, etc), where those names map to which connectors are available.
With both the ATI and intel drivers, once I found the connector tables, it was a matter of looking at how the data is used by the driver to verify the semantics of the various fields. The information is incomplete as I stopped when I got far enough to solve the problem I was having with the driver.