Jump to content

Intel HD Graphics / i7 2600


  • Please log in to reply
153 replies to this topic

#41
c.craigen

c.craigen

    InsanelyMac Protégé

  • Members
  • Pip
  • 26 posts
There is unlikely to be one used in an official mac any time soon, Apple tends to stick with the higher end of Intel's offerings so the lowest common denominator is still probably going to be the HD3000.

The other thing I was worried about was sound over integrated HDMI. I know for a fact that I can get this to work with ATI cards (since I've used them in 2 of my 3 hackintosh builds so far) but it's still a blind shot with the Intel graphics.

#42
Kyle_C

Kyle_C

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
I could see it happening whenever Apple finally gets around to releasing a new Mac Mini. Something like an i5-2390T would be a great choice for that.

#43
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male
Anyone else trying to use hd3000 graphics via displayport? Under OSX lion, with my h67 chipset motherboard, I get usable graphics via DVI, with AppleIntelHDGraphics & AppleIntelSNBGraphicsFB loaded up, but the DVI port is just single-link (low resolution). Displayport can give me 2560x1600, but when I boot lion via displayport, the connector doesn't get mapped right (connector-type=0x400=dvidisplayport in the ioregistry yet nothing showing under connectors in the system profile->graphics) and I get no graphics (screen stays on b&w display at "macx_swapon SUCCESS" point; yet system is fully up multi-user). AppleIntelHDGraphics & AppleIntelSNBGraphicsFB are loaded in this case as well, just not initialized right.

If I boot vanilla 10.6 without AppleIntelHDGraphics & AppleIntelSNBGraphicsFB, I can use the displayport, of course without qe/ci and at lower resolution.

displayport @2560x1600 works fine under linux on this system.

#44
Kyle_C

Kyle_C

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
Well, I have a Sandy Bridge laptop, and I'm still on 10.6.7, but I can tell you that I see the same behavior (even with just the LCD) unless I use the Sandy Bridge graphics kexts with an older IOGraphicsFamily, the one from 10.6.6. And it seems no matter what combination of kexts I try I haven't been able to get the HDMI port to work. I can use the most recent AppleGraphics* kexts but not IOGraphicsFamily.

The solution probably lies in the ACPI table somewhere. 'AAPL,os-info' is the most important value in general, but I don't think anyone outside of Apple can say what the different fields in the bitmask are for. Looking at the ioreg output from a MacBookPro8,1, I see two AppleIntelFramebuffer devices with different values for the key called 'AAPL,DisplayPipe': the LCD is 0x00000000 and the displayport is 0x01000000. However, this is set the same way on my machine and "Detect Displays" doesn't work.

There is also a key called 'port-number' with values of 2 and 5, respectively. And 'av-signal-type' looks interesting, although maybe that just affects digital audio output.

I'm beginning to suspect that PC DSDTs are commonly written so that they "remap" these ports when you press a Fn key, boot with a different port connected, etc. But I think OS X just wants to be told about all the ports and handle this stuff itself. So FWIW, I'm focusing on trying to get "Detect Displays" in System Preferences to do something.

#45
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male
Sounds like the intel graphics driver support is understood a lot less than the ati&nvidia.
I thought that some of the problems people were having mixing&matching intel graphics kexts under 10.6 would go away with a clean 10.7 distribution... Guess not.
One could look at the driver code to see exactly what it's doing with the efi injection strings such as AAPL,os-info...
I did just try injecting that one via my dsdt, and it made no difference (showed up in the ioregistry correctly however).

Yes, av-signal-type must be 0x8 for HDMI or 0x10 for displayport before AppleHDAController will hoptplug hdmi/displayport audio.

Would be nice to see the ioregistry from a mac with a 2560x1600 display being driven by the hd3000 graphics. Then we'd at least know what state the ioregistry entries are in at that point.

#46
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male
I managed to get full 2560x1600 resolution working with my h67 motherboard, via displayport using the stock AppleIntelSNBGraphicsFB driver.

Once I checked the driver code, I saw that the issue was that AppleIntelSNBGraphicsFB checks the platform ID against a whitelist, and falls over to a generic case if there is not a match. The whitelist looks to just be list of sandy bridge product ids.
So I simply replaced SMboardproduct in my smbios.plist with the genuine macbookpro8,1 value: Mac-94245B3640C91C81

Viola, the driver now detects 4 possible connectors, instead of just 1, and detects the displayport with the correct connector type.

#47
beaups

beaups

    InsanelyMac Protégé

  • Members
  • PipPip
  • 85 posts

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

Once I checked the driver code, I saw that the issue was that AppleIntelSNBGraphicsFB checks the platform ID against a whitelist, and falls over to a generic case if there is not a match. The whitelist looks to just be list of sandy bridge product ids.
So I simply replaced SMboardproduct in my smbios.plist with the genuine macbookpro8,1 value: Mac-94245B3640C91C81

Viola, the driver now detects 4 possible connectors, instead of just 1, and detects the displayport with the correct connector type.


And do you get QE/CI?

#48
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

And do you get QE/CI?

Yes.
And opengl works.
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.

Got my fingers crossed that the event ring problems will go away once I get hdmi/displayport audio configured right.

#49
lenovo3000

lenovo3000

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
  • Gender:Male

Kyle_C,
Would it be possible to apply your patch to the new branch of chameleon called chimera? its one that is supported by tonymacx86 site. That bootloader is doing proper RAM and CPU identification for Sandy Bridge. But as far as i know does not contain any support for hd2000/3000 yet.

Thanks,
g\


IMHO a better solution is to add "device-properties" key into /Extra/com.apple.Boot.plist and to use any version of Chameleon, even recent Chimera 1.4.0 (have not been announced on main page yet, but downloadable since Friday).

For GFX on PciRoot(0x0)/Pci(0x2,0x0) the appropriate string is:
<key>device-properties</key><string>600000000100000001000000540000000100000002010c00d041030a000000000101060000027fff04001e0000004100410050004c002c006f0073002d0069006e0066006f0000001800000030490111111108000001f01f0100000010070000</string>

This string tells Chameleon/Chimera to inject 20h bytes long "AAPL,os-info" data: 30490111111108000001f01f0100000010070000.

I wonder, how did Kyle_C manage to find the exact data, since a dozen variants found inside Graphics kexts did not work for my Lenovo L520 (it might have a different port layout, I guess). Anyway, thanks both to Kyle_C and makolet for their work. At least I know the direction to dig further.

#50
Kyle_C

Kyle_C

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
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.

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

#51
lenovo3000

lenovo3000

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
  • Gender:Male

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 :P 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 ##### update.

EDIT: just found a bunch of ioreg/ACPI dumps:
http://tdev.me/2010/...hardware-dumps/

#52
lenovo3000

lenovo3000

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
  • Gender:Male

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?

#53
Kyle_C

Kyle_C

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
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.

#54
lenovo3000

lenovo3000

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
  • Gender:Male

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.

#55
Kyle_C

Kyle_C

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
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.

#56
lenovo3000

lenovo3000

    InsanelyMac Protégé

  • Members
  • Pip
  • 32 posts
  • Gender:Male

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.

#57
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

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

#58
Kyle_C

Kyle_C

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
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?

#59
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male

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

#60
Kyle_C

Kyle_C

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts

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





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy