Intel HD Graphics / i7 2600

[lenovo3000]

Cool, thanks for that. Device strings have always been a mystery to me. As a long-time C programmer I had found it easier to just modify the source, but this is definitely a more flexible solution.

 

The value I used was taken from the ioreg dump of a MacBookPro8,1 machine.

 

Just sent you a message with the question Thanks a lot. Could you please share a link to the dump?

 

Hey, I used to call myself a C programmer too but strings appear to be more flexible, as long as "AAPL,os-info" is the only injection needed and the rest of SB support is provided by the newest Chimera 1.4.0.

 

BTW, it's available since Friday, including source, but no announcement on the main page yet. And no [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] update.

 

EDIT: just found a bunch of ioreg/ACPI dumps:

http://tdev.me/2010/12/apple-hardware-dumps/

[lenovo3000]

The value I used was taken from the ioreg dump of a MacBookPro8,1 machine.

 

Thanks for your hints, now it seems that I am closer than ever to working 1600x900 internal panel, using 20h bytes from MBP8,3 ioreg dump ("AAPL,os-info" = <30490101010108000001f0ff0100000010070000>):

 

Displays:

Display:

Resolution: 1600 x 900 @ 60 Hz

Pixel Depth: 32-Bit Color (ARGB8888)

Main Display: Yes

Mirror: Off

Online: Yes

Built-In: Yes

 

The output is heavily distorted, have to connect via ssh and use system_profiler to get display info. Probably have to set additional properties like "AAPL,DualLink".

 

Could you please confirm, that "AAPL,os-info" injection and GFX0->IGPU change in DSDT are the only modifications or did you also modified your graphics section in DSDT somehow?

[Kyle_C]

Yeah, the files on that page are the same ones I use.

 

Could you please confirm, that "AAPL,os-info" injection and GFX0->IGPU change in DSDT are the only modifications or did you also modified your graphics section in DSDT somehow?

 

Actually, a while ago I removed my modified DSDT file and everything still works the same. So it is just AAPL,os-info that matters. And at some point the driver was updated in such a way that even that isn't needed: it sounds like bcc9 got it working in Lion without that modification. I'm currently doing a fresh install, and I'm going to use the latest 10.6.8 preview and see what the situation is with that.

[lenovo3000]

Yeah, the files on that page are the same ones I use.

 

Actually, a while ago I removed my modified DSDT file and everything still works the same. So it is just AAPL,os-info that matters. And at some point the driver was updated in such a way that even that isn't needed: it sounds like bcc9 got it working in Lion without that modification. I'm currently doing a fresh install, and I'm going to use the latest 10.6.8 preview and see what the situation is with that.

 

Thanks, it improves my chances. If I am not mistaken, your native resolution is 1600x900 as well, and I guess a different port layout prevents my laptop from achieving the same result a your ASUS did. Hope to force correct output with additional AAPL values.

 

Just to be sure: I believe you were recently using 10.6.7 (common, non-SB) + 10.7.3 kernel with Chimera 1.4.0 (or legacy kernel) and manually added kexts from 10.6.7.MBP update:

AppleIntelHDGraphics.kext

AppleIntelHDGraphicsGLDriver.bundle

AppleIntelSNBGraphicsFB.kext

AppleIntelSNBVA.kext

IOGraphicsFamily.kext

 

Is is correct? Or did you have to add some more kexts (IONDRVSupport, etc.)?

 

Please post your findings with 10.6.8 here -- and good luck.

[Kyle_C]

My original recipe was the 2011 Macbook version of 10.6.7 with 10.7.0 legacy kernel and reversion of the IOPCIFamily and System kexts (also ACPIPlatformSupport.kext, I think?) allowing this legacy kernel to work right.

 

Now that Chameleon RC5 and Chimera 1.4 allow me to use a vanilla kernel I have ended up with a really messy mix of different kext versions, which is why I've decided to do a fresh install. So I'll get back to you.

[lenovo3000]

Now that Chameleon RC5 and Chimera 1.4 allow me to use a vanilla kernel I have ended up with a really messy mix of different kext versions, which is why I've decided to do a fresh install. So I'll get back to you.

 

Ok, thanks. I keep a clean install on a separate partition for emergency boot only. It seems a good idea to start my explorations from clean install as well to concentrate on AAPL properties and exclude any unexpected kext versions conflicts.

 

UPDATE for other laptop users having black screen on boot: The "AAPL,os-info" data discovered by Kyle_C does actually deal with L520 internal LCD, but it seems that another Display Connector is discovered (seen in System Profiler and in ioreg as "port-number" 5) and selected as default, since drivers get correct EDID for internal LCD.

[bcc9]

@bcc9, awesome find! I can't wait to try it out. When you say that you looked at the driver source, I assume you mean that you disassembled the kext?

 

Let us know what you find out about that "gotcha" also. And I'll try to help out with testing.

Exactly, one would disassemble and or decompile the kext. That's why I wrote "driver code" not source. If I had the source I'd just fix it to support my hardware without any config tweaks

 

I injected the expected hda-gfx strings for HDMI/DP audio, but I haven't been able to silence all of the audio assertion errors, or get rid of the hotplug requirement before the displayport works without the driver hangs.

 

In 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.

 

PS: AAPL,os-info is only used by AppleIntelHDGraphicsFB, in AppleIntelHDGraphicsFB::getOSInformation() which is not loaded in my case (I have AppleIntelSNBGraphicsFB loaded, where AppleIntelSNBGraphicsFB::getOSInformation() is using the above mentioned getPlatformID() instead.

[Kyle_C]

Oh okay, interesting. Thanks for the info.

 

Say, as long as I've got you here, do you mind if I go OT for a sec? I'm getting these little occasional lockups that last for like half a second. It seems to be associated with random access to the hard drive (I get dismal scores in the Xbench disk benchmarks, on the 4k random read test especially). I tried some DSDT changes to clear up IRQ conflicts on the SATA controller, and I think I managed to do that, but the problem remains. What is your opinion: should I continue to debug the problem or just try out a different hard drive and see if it goes away?

[bcc9]

Oh okay, interesting. Thanks for the info.

 

Say, as long as I've got you here, do you mind if I go OT for a sec? I'm getting these little occasional lockups that last for like half a second. It seems to be associated with random access to the hard drive (I get dismal scores in the Xbench disk benchmarks, on the 4k random read test especially). I tried some DSDT changes to clear up IRQ conflicts on the SATA controller, and I think I managed to do that, but the problem remains. What is your opinion: should I continue to debug the problem or just try out a different hard drive and see if it goes away?

Didn't that have something to do with using nawcom/et. all's legacy kernel and having the busratio set wrong?

If it really corresponds to filesystem I/O I think you could track it down with dtrace (I assume you already checked /var/log).

[Kyle_C]

Didn't that have something to do with using nawcom/et. all's legacy kernel and having the busratio set wrong?

If it really corresponds to filesystem I/O I think you could track it down with dtrace (I assume you already checked /var/log).

 

Hmm, I wasn't aware of that. It was doing it with vanilla 10.7.3 as well, but I never thought to remove the busratio boot argument so I'll try that. And I wasn't aware of dtrace, so thanks. (Although, it feels to me like it's an issue within the kernel since the whole UI locks up for a moment.)

[lenovo3000]

In 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.

 

PS: AAPL,os-info is only used by AppleIntelHDGraphicsFB, in AppleIntelHDGraphicsFB::getOSInformation() which is not loaded in my case (I have AppleIntelSNBGraphicsFB loaded, where AppleIntelSNBGraphicsFB::getOSInformation() is using the above mentioned getPlatformID() instead.

 

I have just checked again -- AppleIntelHDGraphicsFB.kext is not loaded, only AppleIntelSNBGraphicsFB.kext and AppleIntelHDGraphics.kext (probably I should delete HDGraphics kexts not related to SNB). Nevertheless modification of 5th byte in os-info data block does effect the port layout. 00h and 8ah stands for port 0 only, while 44h corresponds for ports 7 & 8, etc.. I do not see any logic in this mapping, the lowest port number available is 0, others are 5-8.

 

My SMboardproduct is Mac-94245B3640C91C81.

 

I managed to get full 2560x1600 resolution working with my h67 motherboard, via displayport using the stock AppleIntelSNBGraphicsFB driver.

 

Could you please confirm, did you get it with 10.6.7 kexts or with clean 10.7 DP2 install?

[bcc9]

Hmm, I wasn't aware of that. It was doing it with vanilla 10.7.3 as well, but I never thought to remove the busratio boot argument so I'll try that. And I wasn't aware of dtrace, so thanks. (Although, it feels to me like it's an issue within the kernel since the whole UI locks up for a moment.)

I wasn't suggesting removing the busratio boot argument, rather setting it to the workaround value, ie busratio=29 (even though 29 is likely not the real ratio for your cpu). My memory is getting fuzzy on this as I've only been using 10.7 lately, but I think this is the step that got rid of the mouse lag issue. See for example: http://www.tonymacx86.com/viewtopic.php?p=73042#p73042

"My geekbench score jumped to over 10,000 when I used busratio=29/30. My audio is working well and my mouse is a lot smoother, but it does get stuck from time to time.

If I don't use busratio, or if I use busratio=34, I get the same choppy mouse movements and bad audio as everyone else"

 

It was because of these kinds of issues that I moved to 10.7 early even though I'm not big on running beta OS releases.

 

 

 

 

I have just checked again -- AppleIntelHDGraphicsFB.kext is not loaded, only AppleIntelSNBGraphicsFB.kext and AppleIntelHDGraphics.kext (probably I should delete HDGraphics kexts not related to SNB). Nevertheless modification of 5th byte in os-info data block does effect the port layout. 00h and 8ah stands for port 0 only, while 44h corresponds for ports 7 & 8, etc.. I do not see any logic in this mapping, the lowest port number available is 0, others are 5-8.

 

My SMboardproduct is Mac-94245B3640C91C81.

 

 

 

Could you please confirm, did you get it with 10.6.7 kexts or with clean 10.7 DP2 install?

I am using 10.7 DP2 with the 3 updates installed. "Clean" in that I didn't replace any kexts to make things work. I did add the PCI-id for my on-chip graphics to the match clauses in AppleIntelHDGraphics&AppleIntelSNBGraphicsFB. (One could instead just inject device-id=0x26010000 to match the macbook).

 

Anyways, in the 10.7 kexts, the only kext that references os-info is AppleIntelHDGraphicsFB, which is why I claimed as much. My whole analysis was only of 10.7 DP2.

 

I just checked the older 10.6 2011 MBP update version of AppleIntelSNBGraphicsFB, and yes, it does look at os-info like AppleIntelHDGraphicsFB does instead of the platform ids like the newer 10.7 driver does.

 

So if you're seeing a difference from modifying os-info, I assume you're using an old 10.6 version of AppleIntelSNBGraphicsFB.

[lenovo3000]

So if you're seeing a difference from modifying os-info, I assume you're using an old 10.6 version of AppleIntelSNBGraphicsFB.

 

Thanks a lot for the details. You are quite right, my recent attempts were concetrated on 10.6.7 nonSB+ 10.6.7 SB (I have just tried 10.6.8 DP2 kexts, same outcome). After a week of experiments it looks like something is really different with my Lenovo, might be a port layout or internal LCD connection interface. Since Kyle_C "AAPL,os-info" solution gives me a heavily distorted image. It does correctly determine EDID, sets native resolution + full QE/CI, but I can see a normal image only via Screen Shraing, while internal LCD still reflects awfully distorted picture -- I can recognize some multiply mirrored changes when open/close windows, etc.

 

Additional "AAPL" values like "DualLink", etc. did not improve the situation. Neither CRT0, DP0-DP2 removal from DSDT did. If fact I'm not quite sure, that modified DSDT.aml was properly loaded by Chimera -- according to bdmesg it was, but I suspect it has been skipped silently (since the dsl was compiled with some errors/warnings).

 

Too much time wasted in attempts to get 1600x900 with 10.6.x. It looks like I have to try 10.7 DP2 just to know, that future Lion release might support my laptop properly and live with Screen Sharing patiently till that moment. BTW, may I ask you, whether you succeeded with 10.7 installation through Chimera 1.4.0 or did you have to use legacy kernel and/or some other tricks? I made few attempts last week and it stopped before welcome screen.

[Kyle_C]

I have just checked again -- AppleIntelHDGraphicsFB.kext is not loaded, only AppleIntelSNBGraphicsFB.kext and AppleIntelHDGraphics.kext (probably I should delete HDGraphics kexts not related to SNB).

 

Correct me if I'm wrong, but I think AppleIntelHDGraphics is the part that contains the common denominator used by both Sandy Bridge macs and the earlier macs with hybrid Intel/Nvidia graphics. So it really does do stuff.

 

I wasn't suggesting removing the busratio boot argument, rather setting it to the workaround value, ie busratio=29 (even though 29 is likely not the real ratio for your cpu). My memory is getting fuzzy on this as I've only been using 10.7 lately, but I think this is the step that got rid of the mouse lag issue.

 

Okay, thanks for clearing that up. I'll experiment with it a bit.

 

Since Kyle_C "AAPL,os-info" solution gives me a heavily distorted image. It does correctly determine EDID, sets native resolution + full QE/CI, but I can see a normal image only via Screen Shraing, while internal LCD still reflects awfully distorted picture -- I can recognize some multiply mirrored changes when open/close windows, etc.

 

I see screen artifacts now and then. Maybe it is a mild incarnation of the problem you have? I see two different types: a sort of checkered gray pattern that shows up in some windows (especially Microsoft Word), and lots of thin horizontal lines (especially on the desktop). It seems to be fairly random how badly I suffer from the problem on any particular boot: if I get a good one, there aren't any. Anyway, just thought I'd describe that in case you think your issue is related.

 

I did my fresh install of 10.6.8, here are the notes I took. This is considerably simpler now that improved Sandy Bridge bootloaders are available.

 

* use [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] to install SL retail

** I installed onto an MBR-formatted disk (here's a neat trick I just discovered: you can do this by plugging in a USB flash drive and then doing 'cd /Volumes/USBFLASH/ ; /System/Library/CoreServices/Installer.app/Contents/MacOS/Installer /System/Installation/Packages/OSInstall.mpkg'. No need to patch OSInstall.mpkg!)

* remove ACPI_SMC_PlatformPlugin.kext (to prevent a KP during OS update), touch /System/Library/Extensions, and reboot

* update to 10k524, but don't reboot

* use [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] 3.6.0 to install fakesmc, nullcpupowermanagement and macbookpro8,1 definition

* install chimera 1.4

* (because of my screwy hard drive) boot into linux to manually write the boot1h file)

* add the device-properties string posted by lenovo3000 to the Boot plist

* reboot with working graphics and proceed to install whatever other kexts

 

I have the same SMboardproduct that you all have mentioned, the one from the MacBookPro8,1, but I still can't get anything to happen with 'detect displays'. I do have an AppleIntelFramebuffer device for the HDMI port in my ioreg, and when I plug in a monitor the screen flashes, but I don't end up with any additional IODisplayConnect device (I can see from a comparison of ioreg dumps that the 'display0' IODisplayConnect device for the LCD gets recreated with the same device details under a new id number, and that's it). I guess the next thing to try would be to fix my connector-type so that it is 0x800 instead of 0x400.

[bcc9]

Too much time wasted in attempts to get 1600x900 with 10.6.x. It looks like I have to try 10.7 DP2 just to know, that future Lion release might support my laptop properly and live with Screen Sharing patiently till that moment. BTW, may I ask you, whether you succeeded with 10.7 installation through Chimera 1.4.0 or did you have to use legacy kernel and/or some other tricks? I made few attempts last week and it stopped before welcome screen.

I did not use chimera, a legacy kernel or any "tricks" to install 10.7.

Once I got sandy bridge support merged into chameleon, the mainline chameleon code booted DP2 via usb thumb drive just fine via DVI. With all the important features (most notably lion&sandy bridge support) merged into the chameleon trunk, I don't see a need for using a branch such as Chimera at this point.

[lenovo3000]

I did not use chimera, a legacy kernel or any "tricks" to install 10.7.

Once I got sandy bridge support merged into chameleon, the mainline chameleon code booted DP2 via usb thumb drive just fine via DVI. With all the important features (most notably lion&sandy bridge support) merged into the chameleon trunk, I don't see a need for using a branch such as Chimera at this point.

 

Good news, thanks. Let me try the latest Chameleon with Lion today and post my findings here.

[lenovo3000]

Correct me if I'm wrong, but I think AppleIntelHDGraphics is the part that contains the common denominator used by both Sandy Bridge macs and the earlier macs with hybrid Intel/Nvidia graphics. So it really does do stuff.

 

Fear not, quite right you are... © Yoda

 

No offense, really. Please excuse my attempt to humour, no offense intended.

 

In fact, I was so sure AppleIntelHDGraphics does contain "general" code, while AppleIntelHDGraphicsFB and AppleIntelSNBGraphicsFB do include the rest ("specific"), that did not even bother to delete AppleIntelHDGraphicsFB and other kexts related to i3-i5-i7 1st generation graphics (it might be the 5th generation of Intel onboard GFX in fact, while SB's HD is the 6th, if I am not mistaken).

 

But then I read bcc9's report about "os-info" related code found in AppleIntelHDGraphicsFB kext only, which is not shown by kextstat on my system, while I definitely saw the influence of the "os-info" injection (regadless of modified DSDT.aml, by the way).

 

Well, I do trust most people (until they prove I should not), thus my paranoia strikes and I start to suspect AppleIntelHDGraphicsFB for dirty tricks, like loading, messing up my settings and unloading silently (with no evidence in kextstat).

 

I would consider it as a bad practice, since according to Info.plist the kext is not supposed to interfere as long as the newest HD 2000/3000 graphics is concerned. By the way, did you notice that format of values for IOPCIPrimary match varies? It is not alwas explicitly hex (with 0x prefix). Almost sure it does not matter but IMHO strange to see such a mix in the production code.

 

And then bcc9 confirmed that he was writing about 10.7 kexts only.

 

Okay, thanks for clearing that up. I'll experiment with it a bit.

 

I see screen artifacts now and then. Maybe it is a mild incarnation of the problem you have? I see two different types: a sort of checkered gray pattern that shows up in some windows (especially Microsoft Word), and lots of thin horizontal lines (especially on the desktop). It seems to be fairly random how badly I suffer from the problem on any particular boot: if I get a good one, there aren't any. Anyway, just thought I'd describe that in case you think your issue is related.

 

If my memory still serves me, the 1st type of artifacts was seen (on Screen Sharing) with "single port layout, not internal display" configurations.

 

Whenever I use "double port layout", even strange "Display on port #0 (detected and native 1600x900 selected) + Display connector on port #0 (not detected)", my Screen Sharing is perfectly artifact free, while internal LCD is either blank (backlit, not switched off) or contains the boot time image (gray background with apple logo and a frozen wheel-style progress bar (not sure what is a proper name for this stuff).

 

The 2nd type described above reminds me artifacts I do see while using openSUSE LiveCD 11.4 for dumping hardware info, etc. -- any touch down menu (the whole rectangular area) is heavily corrupted, while the rest of the X11 interface looks pretty good.

 

The distortion mentioned by me earlier looks like "bad timings", it occurs on internal LCD with "Display on single port #0" configurations (01h or 8ah in the 5th byte of "os-info"). But EDID is always detected correctly! Still tried to force EDID manually Display Override trick, no difference.

 

I suspect, that some part of my "os-info" forces wrong timings, overriding the EDID (my os-info mostly contains nils, in fact). Still have to try "AAPL,Tn" / "AAPL,overried-has-edid-digital" and other values.

 

I did my fresh install of 10.6.8, here are the notes I took. This is considerably simpler now that improved Sandy Bridge bootloaders are available.

 

* use [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] to install SL retail

** I installed onto an MBR-formatted disk (here's a neat trick I just discovered: you can do this by plugging in a USB flash drive and then doing 'cd /Volumes/USBFLASH/ ; /System/Library/CoreServices/Installer.app/Contents/MacOS/Installer /System/Installation/Packages/OSInstall.mpkg'. No need to patch OSInstall.mpkg!)

* remove ACPI_SMC_PlatformPlugin.kext (to prevent a KP during OS update), touch /System/Library/Extensions, and reboot

* update to 10k524, but don't reboot

* use [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] 3.6.0 to install fakesmc, nullcpupowermanagement and macbookpro8,1 definition

* install chimera 1.4

* (because of my screwy hard drive) boot into linux to manually write the boot1h file)

* add the device-properties string posted by lenovo3000 to the Boot plist

* reboot with working graphics and proceed to install whatever other kexts

 

I have the same SMboardproduct that you all have mentioned, the one from the MacBookPro8,1, but I still can't get anything to happen with 'detect displays'. I do have an AppleIntelFramebuffer device for the HDMI port in my ioreg, and when I plug in a monitor the screen flashes, but I don't end up with any additional IODisplayConnect device (I can see from a comparison of ioreg dumps that the 'display0' IODisplayConnect device for the LCD gets recreated with the same device details under a new id number, and that's it). I guess the next thing to try would be to fix my connector-type so that it is 0x800 instead of 0x400.

 

Thanks a lot indeed for the details! I noticed your earlier claims and came to conclusion, that writing step-by-step guides is not your favourable hobby. No offense, once again Hope to try 10.6.8 full update today, just before the Lion testing. I would expect 10.6.8 to deal more correctly with HD2000/3000, since it is a common release for all the hardware, including the newest SB models (not a separate MBP-only update, I mean).

[Krooklyn]

Correct me if I'm wrong, but I think AppleIntelHDGraphics is the part that contains the common denominator used by both Sandy Bridge macs and the earlier macs with hybrid Intel/Nvidia graphics. So it really does do stuff.

 

 

 

Okay, thanks for clearing that up. I'll experiment with it a bit.

 

 

 

I see screen artifacts now and then. Maybe it is a mild incarnation of the problem you have? I see two different types: a sort of checkered gray pattern that shows up in some windows (especially Microsoft Word), and lots of thin horizontal lines (especially on the desktop). It seems to be fairly random how badly I suffer from the problem on any particular boot: if I get a good one, there aren't any. Anyway, just thought I'd describe that in case you think your issue is related.

 

I did my fresh install of 10.6.8, here are the notes I took. This is considerably simpler now that improved Sandy Bridge bootloaders are available.

 

* use [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] to install SL retail

** I installed onto an MBR-formatted disk (here's a neat trick I just discovered: you can do this by plugging in a USB flash drive and then doing 'cd /Volumes/USBFLASH/ ; /System/Library/CoreServices/Installer.app/Contents/MacOS/Installer /System/Installation/Packages/OSInstall.mpkg'. No need to patch OSInstall.mpkg!)

* remove ACPI_SMC_PlatformPlugin.kext (to prevent a KP during OS update), touch /System/Library/Extensions, and reboot

* update to 10k524, but don't reboot

* use [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] 3.6.0 to install fakesmc, nullcpupowermanagement and macbookpro8,1 definition

* install chimera 1.4

* (because of my screwy hard drive) boot into linux to manually write the boot1h file)

* add the device-properties string posted by lenovo3000 to the Boot plist

* reboot with working graphics and proceed to install whatever other kexts

 

I have the same SMboardproduct that you all have mentioned, the one from the MacBookPro8,1, but I still can't get anything to happen with 'detect displays'. I do have an AppleIntelFramebuffer device for the HDMI port in my ioreg, and when I plug in a monitor the screen flashes, but I don't end up with any additional IODisplayConnect device (I can see from a comparison of ioreg dumps that the 'display0' IODisplayConnect device for the LCD gets recreated with the same device details under a new id number, and that's it). I guess the next thing to try would be to fix my connector-type so that it is 0x800 instead of 0x400.

 

Guys, call me an idiot if this is a stupid question, but is this whole research on a Laptop or a Desktop. I'm asking because I have the new Alienware m14x (i2630qm - Optimus Intel HD3000/Nvidia GT555m) and I have been able to get EVERYTHING to successfully work except for the Graphics. I have clean installed multiple times trying different ways starting with the [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] + SL method (ei. after install updated to 10.6.7 which got me a fully running OSX, just not reading GFX - then I tried again with MBP 2011 10.6.7 and once installed and reboot, I get a hang at DSMOS Arrived but it freezes with crazy gfx distortion) When I try this method and update to 10.6.6 then to 10.6.8 beta, I get a kernel panic at the end of install.

 

Trying to figure all this {censored} out. I was hoping that there was a solution to Optimus GFX by now, but by my research, I'm thinking not so much. If you guys happen to know otherwise please let me know, thank you!

[Kyle_C]

It's not yet clear whether the situation is really any different on a laptop compared to a desktop (aside from desktop processors with HD Graphics 2000 only, which is potentially an issue).

 

My feeling is, if you get really bad distortions, AND you're using the AAPL,os-info fix (ie, the second to last item in my list above), then you should try Lion because we don't know how to fix the distortions.

 

On the other hand, if you had 10.6.7 2011 MBP installed but didn't use the AAPL,os-info fix, yeah, it won't work. You just see some distortions in the console and never really get to the GUI.

 

If you get a kernel panic while doing an update try removing ACPI_SMC_PlatformPlugin.kext as I mentioned in my notes. It is inside IOPlatformFamily.kext.

 

edit: I call it console because I come from the Linux world. The black-and-white text-based interface that you see if you do a verbose boot and that you remain in when you boot single user. Is there a Mac name for that?

[bcc9]

One major gotcha is that the graphics driver has some sort of repeated event ring hang until the port is hotplugged. Before hotplugging, this manifests as the GUI behaving extra slowly. I actually didn't notice this at first as I had hotplugged the displayport first thing by coincidence.

Just an update on this... I have found that if I boot with both DVI&displayport active, then I have a 2 screen desktop with no graphics driver hanging problem.

However if I boot with just one or the other (just displayport or just single link dvi), I get the hanging issue, until I hotplug one or the other. Very confusing behavior. BTW, the hang looks like the following, as seen via dmesg or /var/log/kernel.log, repeating every 5 seconds or so:

May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: WaitForStamp: Overflowed waiting for stamp 0x2f3 on Main ring: called from
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: timestamp = 0x02cc
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: ****  Debug info for apparent hang in Main graphics engine  ****
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: ring head	= 0x00600eb4, wrap count = 0x 3
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: ring tail	= 0x00000110 ring control = 0x00003801   enabled, auto report disabled,  waiting, semaphore not waiting, length = 0x004 4KB pages
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: timestamps = 0x02cc
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: Semaphore register values:
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: VRSYNC: (0x12044) = 0x2cc
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: BRSYNC: (0x22040) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: RVSYNC: (0x 2040) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: BVSYNC: (0x22044) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: RBSYNC: (0x 2044) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: VBSYNC: (0x12040) = 0x0
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: Looks like Main ring is stuck waiting on an event
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: After attempt to clear wait condition = 0x00003001 no longer waiting
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: kIPEHR: 0x7a000003
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: kINSTDONE: 0xfffb
May 25 23:20:45 xs-MacBook-Pro-2 kernel[0]: kINSTDONE_1: 0x230003f

[hchinasky]

@bcc9

 

Are you using a laptop or a desktop?

[bcc9]

I see screen artifacts now and then. Maybe it is a mild incarnation of the problem you have? I see two different types: a sort of checkered gray pattern that shows up in some windows (especially Microsoft Word), and lots of thin horizontal lines (especially on the desktop). It seems to be fairly random how badly I suffer from the problem on any particular boot: if I get a good one, there aren't any. Anyway, just thought I'd describe that in case you think your issue is related.

When the driver is hanging, it'll take maybe 5-10 seconds for a visible response to an action such as moving a window or clicking on a menu. Graphics are drawn incompletely for a few seconds as well (acts as if the cpu load is high, yet it is not; response time is peflectly fine if you ssh into the system).

I do also see a completely garbled screen for a few seconds at startup before the GUI screen is displayed. Both DVI & displayport.

Are you using a laptop or a desktop?

I'm using a gigabyte h67ma-ud2h-b3 motherboard with core i7 2600k cpu (ie desktop).

The only intel graphics laptop I have is 2005 vintage (not a good vintage at that).

[lenovo3000]

Let me report my recent progress.

 

I have finally got a DP->HDMI adapter:

http://h10010.www1.hp.com/wwpc/us/en/sm/WF...ng=en&cc=us

 

And gladly found, that the graphics bundle extracted from 10.6.7MBP or 10.6.8Beta does allow to use mobile HD3000 with "AAPL,os-info" fix discovered by Kyle_C -- via external connection.

 

Concerning the internal one (most likely using LVDS) I am 99% sure, that the problem is caused by the same 20h magical bytes from MBP8,1 ioreg. It seem to hardcode display port layout: just #0 and #5 (types 0x2 and 0x400 respectively) regardless of the actual hardware.

 

In my DSDT the 1st device inside GFX0 is denoted as CRT0 in DSDT, while the 2nd is marked as LCD. I do have a problem with port #0 behavior under SL 10.6.x -- both internal LCD and VGA D-Sub show garbage, nevertheless, EDID of internal LCD is determined correctly, native resolution selected and shown in System Profiler.

 

"AAPL,os-info" might force 10.6.x driver to treat both 1st and 2nd ports as #0 -- in my case, since Kyle_C does not report the same problem.

 

The 3rd device (DP0) in DSDT does work perfectly via DP->HDMI or DP->HDMI->DVI connection to external fullHD panel -- if and only if I select the 3rd port as default in BIOS.

 

So, I would recommend selecting external port as the default one in BIOS for those, who need external connection on laptop. I believe that the "connector-type" 0x4000 of port #5 should not prevent proper detection and operation.

 

I suppose that 10.6.x version of AppleIntelSNBGraphicsFB.kext was not intended to be "rather general" (i.e. to be used with future MacBooks and Mac mini). It might not check the real hardware, just relies on "os-info". There is a property "overried-os-info", but it does not seem to work, at least in the way I hoped -- "ignore os-info and use EDID/DSDT instead".

 

The above stated assumptions are based on the fact, that both 10.7 DP3 installer and a driver bundle taken from 10.7 DP3 works perfectly both with internal LCD and an external one via any of my digital connectors (did not try CRT0/D-Sub). As it was reported by bcc9, 4 connectors are detected by driver bundle: #0, #5-7. In fact my DSDT contains 5 devices in GFX0 section, not 4: CRT0, LCD, DP0, DP1, DP2. So it also looks like a hardcoded layout, but simply a better one.

 

And as reported by Kyle_C, OpenGL framework seems to be heavily modified in Lion, my attempts to overcome filename mismatch reported in system log and force framework loading by using symbol links did not help a lot. I would not expect QE/CI support with 10.7 drivers under 10.6 Mac OS. If anyone succeed, please let us now here.

 

Long story short: those people, who need QE/CI with HD3000 urgently could try:

 

1) to use "os-info" trick in com.apple.Boot.plist with 10.6.7/10.6.8 HDGraphics bundle on SL -- it should be ok with external port, but may not work with internal LCD on laptops. This configuration appears to be limited to 2 ports only. You may be required to select the desired external connector as the default one in BIOS.

 

2) to use 10.7DP3 bundle -- it is a fast and simple way to get native resolution and 4 ports, but no QE/CI.

 

In case you have a problem, try "ioreg -lwo0 | grep EDID" and compare with other source (monitor-edid under linux liveCD, etc.) -- in case EDID is not detected properly, use /System/Library/Display/Overrides/ to provide correct EDID.

 

Those who can wait for a few months, please be aware, that forthcoming 10.7 release might definitely support you HD2000/3000 out of the box.

 

UPDATE: an issue with lion kexts (on 10.6.7) discovered: when I use a single 2GiB DDR3 module (288MiB allocated for graphics) -- no artifacts at all. With the second module installed (384 MiB reported to be reserved for graphics) -- some gray artifacts appeared on first restart. BTW, the same module was working for half-year without any issues in another laptop and it was the only module in that system.

 

FINAL UPDATE: for those people, who have an issue with internal LCD/VGA, thus, unable to use 10.6.7MBP kexts: you should not replace AppleIntelHDGraphics*, just take AppleIntelSNB* from 10.7 -- and then you get full QE/CI/OpenGL without artifacts at all.

[Kyle_C]

Ah, you've been digging up my old posts. That is gratifying!

 

You did a great job of researching and pulling together a lot of useful information there. We've got a pretty good handle on the situation with SL now. I'm getting ready to join bcc9 in Lion-land, despite also being a little wary of running a major-version developer preview.

[lenovo3000]

Ah, you've been digging up my old posts. That is gratifying!

 

Google's a deadly weapon, you know. Even your extensive laptop market research was traced and read (well, it could be another guy with similar nick, but I guess those posts were yours).

 

You did a great job of researching and pulling together a lot of useful information there. We've got a pretty good handle on the situation with SL now. I'm getting ready to join bcc9 in Lion-land, despite also being a little wary of running a major-version developer preview.

 

Thanks for kind words.

 

I hope Lion meets your expectations. It may be either amazing and/or amusing, but IMHO hardly usable for production, many packages have not been updated yet to run properly on 10.7 -- neither Xcode 3.2.6 nor 4.0.2 are Lion compartible. The former installs silently, but incompletely, while the later refuses to install and declares version 10.6.6 requirement (I did not bother to fake the OS version number, since it is unlikely to do well anyway).

 

A less important problem might be caused by a sandbox issue, I guess -- full QE/CI support improves visual experience, while the overall graphics performance is not perfect. Desktop is rather laggy sometimes.