Jump to content

Intel HD Graphics 4600 (Haswell) working displayport

bcc9

By bcc9,
in OSx86 10.9 (Mavericks)

 Share
190 posts in this topic

Recommended Posts

bcc9
bcc9
Posted
Posted

At last, I have working QE/CI via displayport with my built-in haswell HD Graphics 4600. My system is a gigabyte z87mx-d3h.

 

Existing instructions suggest setting AAPL,ig-platform-id to either 00 00 26 0c or 00 00 16 0a, but these platform IDs map to layouts that leave my displayport blank.

 

Upon investigation, these 2 layouts share the same port maps with port 0 being LVDS, port 1 DP (displayport) and port 2 HDMI. I can get video out of my gigabyte motherboard's DVI port with these, but the resolution is busted (driver attempts full 2560x1440 resolution, but motherboard doesn't do dual-link DVI, and so result is a distorted desktop display.

 

The AAPL,ig-platform-id that works with DP on my system is 03 00 22 0d. That platform-id is the only one that maps to a layout that uses DP for port #0.

To set the AAPL,ig-platform-id for gigabyte haswell systems, inject via DSDT a new device entry:

        Device (IGPU)
        {
            Name (_ADR, 0x00020000)
            Method (_DSM, 4, NotSerialized)
            {
                Store (Package (0x04)
                {
                      "AAPL,ig-platform-id",
                       Buffer (0x04) { 0x03, 0x00, 0x22, 0x0d },
		      "hda-gfx", Buffer () { "onboard-1" }
                  }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
                }
        }
The existing DSDT for this motherboard doesn't have anything for the IGPU device so you have to add the entire Device section, not just the injection method. You do of course have to add the DTGP method to your DSDT as well. I can explain more fully if there's interest. I can also detail decoding much of the haswell PlatformInformationList like I did for the hd graphics 3000 way back when sandy bridge was new.

 

The result:

% system_profiler SPDisplaysDataType
Graphics/Displays:

    Intel Iris Pro:

      Chipset Model: Intel Iris Pro
      Type: GPU
      Bus: Built-In
      VRAM (Total): 1024 MB
      Vendor: Intel (0x8086)
      Device ID: 0x0412
      Revision ID: 0x0006
      Displays:
        HP ZR2740w:
          Resolution: 2560 x 1440
          Pixel Depth: 32-Bit Color (ARGB8888)
          Display Serial Number: CNTXXXXXXX  
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Built-In: Yes
          Connection Type: DisplayPort

%
  • Like 6
Link to comment
Share on other sites
TimeWalker75a
TimeWalker75a
Posted
Posted

Good find as usual. Sadly I can't test my haswell build yet as my Goofabyte mobo came DOA and I had to RMA. But please do describe the information list as you did back then!

 

Edit:

Oh and I was also wondering, how come you inject another device at the same address where \_SB.PCI0.GFX0 already resides ? I believe GFX0 has the same address of 0x00020000 - it's not included in the DSDT itselft, but in one of SSDTs rather, since all the GFX0 methods are being called as externally in DSDT. Maybe it's just absent from there (SSDTs I mean) as well .. I just don't have my ACPI tables dumped as I was unable to get a successfull POST, but at least this was the case with Z77 Gigabyte boards.

 

So, basically, based on Pike's "knowledge base", there is 03 00 22 0D:

03 00 22 0D //AAPL,ig-platform-id = 0x0d220003: Intel Haswell (GT3) Iris Pro 5200
00 03 03 03  //?????, fPipeCount, fPortCount, fNumFramebuffer 
//32 bytes of platform data (fStolenMemorySize, fFramebufferMemorySize, fCursorBytes, VRAM, fBacklightFrequency, fBacklightMax)
1@ 01 05 12 00 00 04 00 00 87 00 00 00 //Port @0 DP
2@ 02 04 14 00 00 04 00 00 87 00 00 00 //Port @1 HDMI
3@ 03 06 10 00 00 04 00 00 11 00 00 00 //Port @2 ???
  • Like 1
Link to comment
Share on other sites
toleda
toleda
Posted
Posted

 

So, basically, based on Pike's "knowledge base", there is 03 00 22 0D:

03 00 22 0D //AAPL,ig-platform-id = 0x0d220003: Intel Haswell (GT3) Iris Pro 5200
00 03 03 03  //?????, fPipeCount, fPortCount, fNumFramebuffer 
//32 bytes of platform data (fStolenMemorySize, fFramebufferMemorySize, fCursorBytes, VRAM, fBacklightFrequency, fBacklightMax)
1@ 01 05 12 00 00 04 00 00 87 00 00 00 //Port @0 DP
2@ 02 04 14 00 00 04 00 00 87 00 00 00 //Port @1 HDMI
3@ 03 06 10 00 00 04 00 00 11 00 00 00 //Port @2 ???

All connectors are DP (00 04) in 03 00 22 0D.  Other connectors:

02 00 - LVDS

04 00 - DVI

00 08 - HDMI

00 0C - 4K?

 

For HDMI  (assumes HDMI is on Port 0x05)

Port 0x5 DP > HDMI

 

Use a hex editor:

Open AppleIntelFramebufferAzul.kext/Contents/MacOS/AppleIntelFramebufferAzul (binary)

Find: 03 00 22 0D
 
Find: 01 05 12 00 00 04 00 00 87 00 00 00
Repl: 01 05 12 00 00 08 00 00 06 00 00 00
  • Like 4
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

Good find as usual. Sadly I can't test my haswell build yet as my Goofabyte mobo came DOA and I had to RMA. But please do describe the information list as you did back then!

Good luck with the RMA, hope you got your replacement cross-shipped. I'll try to add some more details, though at this point editing the connector info hasn't been necessary so I'd like to keep it simple.

 

Oh and I was also wondering, how come you inject another device at the same address where \_SB.PCI0.GFX0 already resides ?

Oops, I only read the DSDT, and didn't notice that the device was defined in one of the SSDTs instead. Luckily my DSDT edit seems to be working fine :) But given the existing definition, I think it'd be best to change the DSDT edit to reference the same GFX0 device, then the _ADR shouldn't have to be re-declared.

You can instead do the edit via the SSDT of course, but chameleon doesn't just let you replace 1 of the static SSDTs keeping the dynamic ones.

So, basically, based on Pike's "knowledge base", there is 03 00 22 0D:

My info on 03 00 22 0D came from my own read of the driver and my own dump&decode of PlatformInformationList not that revo evangelist blog. Looks like much of that info is correct though I agree with toleda that the port #1 and port #2 connectors appear mis-labeled there.

 

Best if I just post my decode details for PlatformInformationList I think.

Find: 03 00 22 0D

 

Find: 01 05 12 00 00 04 00 00 87 00 00 00

Repl: 01 05 12 00 00 08 00 00 06 00 00 00

The funny thing is, the 03 00 22 0d platform's connector list is working just fine for me with both displayport and DVI. No edit required. (My DVI port comes up at single-link resolution, but that's all the gigabyte motherboard is allowing).
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

DP 4 Just killed my display using HD4600. I am using HDMI with the same injection method as posted above with 0000160A. Haven't figured it out yet....

The graphics update 1.0 that was pushed out between DP3 and DP4 broke my system, but when I restored back to DP3, skipped the graphics update, and went straight to DP4, then everything was fine. Maybe it's just the graphics update 1.0 that is causing people problems?
Link to comment
Share on other sites
toleda
toleda
Posted
Posted

The funny thing is, the 03 00 22 0d platform's connector list is working just fine for me with both displayport and DVI. No edit required. (My DVI port comes up at single-link resolution, but that's all the gigabyte motherboard is allowing).

DVI working on DP connectors makes sense.  I don't understand a DVI connector in 9 of the 15 mobile Azul framebuffers.  Will we see the Haswell MBP with a mini DVI connector?

  • Like 1
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

DVI working on DP connectors makes sense.  I don't understand a DVI connector in 9 of the 15 mobile Azul framebuffers.  Will we see the Haswell MBP with a mini DVI connector?

Pretty sure all apple systems went from mini DVI to mini DP a few years ago. Maybe the DVI is there to support apple's mini dp to dvi dongle.
  • Like 1
Link to comment
Share on other sites
jsl
jsl
Posted
Posted (edited)

At last, I have working QE/CI via displayport with my built-in haswell HD Graphics 4600. My system is a gigabyte z87mx-d3h.

 

Existing instructions suggest setting AAPL,ig-platform-id to either 00 00 26 0c or 00 00 16 0a, but these platform IDs map to layouts that leave my displayport blank.

 

Upon investigation, these 2 layouts share the same port maps with port 0 being LVDS, port 1 DP (displayport) and port 2 HDMI. I can get video out of my gigabyte motherboard's DVI port with these, but the resolution is busted (driver attempts full 2560x1440 resolution, but motherboard doesn't do dual-link DVI, and so result is a distorted desktop display.

 

The AAPL,ig-platform-id that works with DP on my system is 03 00 22 0d. That platform-id is the only one that maps to a layout that uses DP for port #0.

To set the AAPL,ig-platform-id for gigabyte haswell systems, inject via DSDT a new device entry:

        Device (IGPU)
        {
            Name (_ADR, 0x00020000)
            Method (_DSM, 4, NotSerialized)
            {
                Store (Package (0x04)
                {
                      "AAPL,ig-platform-id",
                       Buffer (0x04) { 0x03, 0x00, 0x22, 0x0d },
		      "hda-gfx", Buffer () { "onboard-1" }
                  }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
                }
        }
The existing DSDT for this motherboard doesn't have anything for the IGPU device so you have to add the entire Device section, not just the injection method. You do of course have to add the DTGP method to your DSDT as well. I can explain more fully if there's interest. I can also detail decoding much of the haswell PlatformInformationList like I did for the hd graphics 3000 way back when sandy bridge was new.

 

The result:

% system_profiler SPDisplaysDataType
Graphics/Displays:

    Intel Iris Pro:

      Chipset Model: Intel Iris Pro
      Type: GPU
      Bus: Built-In
      VRAM (Total): 1024 MB
      Vendor: Intel (0x8086)
      Device ID: 0x0412
      Revision ID: 0x0006
      Displays:
        HP ZR2740w:
          Resolution: 2560 x 1440
          Pixel Depth: 32-Bit Color (ARGB8888)
          Display Serial Number: CNTXXXXXXX  
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Built-In: Yes
          Connection Type: DisplayPort

%

Setting AAPL,ig-platform-id to either 00 00 26 0c or 00 00 16 0a, my Asus Z87 Deluxe Dual MB will load both AppleIntelFramebufferAzul.kext and AppleIntelHD5000Graphics.kext successfully, but its HDMI port blanks and only Nvidia GTX 780 card working.

Does it mean that I need hexedit its connection ID because applying this new ig-platform-id will cause KP during booting ?

Edited by jsl
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

Oops, I only read the DSDT, and didn't notice that the device was defined in one of the SSDTs instead. Luckily my DSDT edit seems to be working fine :) But given the existing definition, I think it'd be best to change the DSDT edit to reference the same GFX0 device, then the _ADR shouldn't have to be re-declared.

You can instead do the edit via the SSDT of course, but chameleon doesn't just let you replace 1 of the static SSDTs keeping the dynamic ones.

So it turns out I wasn't able to just add to the existing GFX0 device entry in my DSDT when it isn't declared until an SSDT. (Any GFX0 definition in the DSDT overrides the SSDT one). To add to GFX0 I had to instead move the injection string to an SSDT, and this works. So here's an example alternate way to inject this, in its entirety. Works on my gigabyte system:

/*
 * Intel ACPI Component Architecture
 * AML Disassembler version 20120913-64 [Sep 15 2012]
 * Copyright (c) 2000 - 2012 Intel Corporation
 */

DefinitionBlock ("SSDT.aml", "SSDT", 1, "SaSsd", "SaSsdt", 0x00003000)
{
    External (\_SB_.PCI0.GFX0, DeviceObj)
    Scope (\_SB.PCI0.GFX0)
    {
            Method (_DSM, 4, NotSerialized)
            {
                Store (Package (0x04)
                {
                      "AAPL,ig-platform-id",
                       Buffer (0x04) { 0x03, 0x00, 0x22, 0x0d },
		      "hda-gfx", Buffer () { "onboard-1" }
                  }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
                }
    }
    Method (DTGP, 5, NotSerialized)
    {
        If (LEqual (Arg0, Buffer (0x10)
                {
                    /* 0000 */    0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44, 
                    /* 0008 */    0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
                }))
        {
            If (LEqual (Arg1, One))
            {
                If (LEqual (Arg2, Zero))
                {
                    Store (Buffer (One)
                        {
                            0x03
                        }, Arg4)
                    Return (One)
                }

                If (LEqual (Arg2, One))
                {
                    Return (One)
                }
            }
        }

        Store (Buffer (One)
            {
                0x00
            }, Arg4)
        Return (Zero)
    }
}

I was wrong about chameleon too - I add the above to /Extra/SSDT.dsl and chameleon picks it up and osx reads in the rest of the ssdt's as well.

  • Like 2
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

Setting AAPL,ig-platform-id to either 00 00 26 0c or 00 00 16 0a, my Asus Z87 Deluxe Dual MB will load both AppleIntelFramebufferAzul.kext and AppleIntelHD5000Graphics.kext successfully, but its HDMI port blanks and only Nvidia GTX 780 card working.

Does it mean that I need hexedit its connection ID because applying this new ig-platform-id will cause KP during booting ?

For my gigabyte MB, the HDMI works just like the DVI, ie it works with all 3 mentioned ig-platform-id values, but only at lousy single-link resolution. Have you verified that the ig-platform-id injection string is making it into the right place (and right byte order) in your ioregistry? I've seen some posts using the wrong byte order for ig-platform-id.
  • Like 1
Link to comment
Share on other sites
toleda
toleda
Posted
Posted

So it turns out I wasn't able to just add to the existing GFX0 device entry in my DSDT when it isn't declared until an SSDT. (Any GFX0 definition in the DSDT overrides the SSDT one). To add to GFX0 I had to instead move the injection string to an SSDT, and this works. 

You are a genius.  This may obsolete dsdt edits.  Here is your ssdt without Method DTGP.

DefinitionBlock ("iASLFLrPKE.aml", "SSDT", 1, "SaSsd", "SaSsdt", 0x00003000)
{
    External (_SB_.PCI0.GFX0, DeviceObj)

    Scope (\_SB.PCI0.GFX0)
    {
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            If (LEqual (Arg2, Zero))
            {
                Return (Buffer (One)
                {
                     0x03
                })
            }

            Return (Package (0x04)
            {
                "AAPL,ig-platform-id", 
                Buffer (0x04)
                {
                     0x03, 0x00, 0x22, 0x0D
                }, 

                "hda-gfx", 
                Buffer (0x0A)
                {
                    "onboard-1"
                }
            })
        }
    }
}

Credit: PikeRAlpha Intel HD4600 with full resolution | Pike's Universum

  • Like 2
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

You are a genius.  This may obsolete dsdt edits.  Here is your ssdt without Method DTGP.

Ha. It's finally obvious to me I should have switched over from dsdt to ssdt editing when I started using uefi bios (that tend to only need simple dsdt edits in the first place). But I was too lazy till now. Older systems with more complex edits (like my battery _BIF method fix) would be a lot messier to try and do via ssdt.

 

PS: This kind of SSDT edit works for HDEF layout-id injecting as well; maybe you should use that as your preferred method instead of an hdaenabler kext in your audio packages.

  • Like 2
Link to comment
Share on other sites
jsl
jsl
Posted
Posted

For my gigabyte MB, the HDMI works just like the DVI, ie it works with all 3 mentioned ig-platform-id values, but only at lousy single-link resolution. Have you verified that the ig-platform-id injection string is making it into the right place (and right byte order) in your ioregistry? I've seen some posts using the wrong byte order for ig-platform-id.

Thanks for your kind and prompt reply.

Please read the attached files one of  which is my IORegistry data because I don't know how to make sure whether I have the wrong byte order for ig-platform-id, and the other is my current DSDT.aml renamed as IGPU.aml

Z87-Deluxe-Dual.zip

IGPU.aml.zip

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

Just to chime in on this, I've been editing dsdt like this (adding dsm through ssdt) for ages now, ever since loading ssdt tables was made possible. Thought this was a common approach...

Yes, some have, it's nothing revolutionary. Just editing the DSDT has been a more common approach in the past - the modified DSDT database over at tonymac is an example of that.

 

I could just make chameleon take the ig-platform-id as a config option so that experimenting is simple...

Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

Thanks for your kind and prompt reply.

Please read the attached files one of  which is my IORegistry data because I don't know how to make sure whether I have the wrong byte order for ig-platform-id, and the other is my current DSDT.aml renamed as IGPU.aml

If you look at your ioreg -lw0 -r -n IGPU (or -n GFX0 depending upon how your dsdt is set up), you see the AAPL-ig-platform-id injection key and value, as well as 3 child AppleIntelFramebuffer nodes. From your ioregistry, this shows that your injection was done right and the driver attached (matched up to the real hardware).

 

Looking a little further, we can see that none of your AppleIntelFramebuffer nodes have IOFBDetailedTimings, so none of your ports picked up the EDID from your display. I don't know why; perhaps you have your BIOS set to disable your built-in graphics if pci-express graphics are installed? Have you tried without your nvidia graphics installed?

Link to comment
Share on other sites
toleda
toleda
Posted
Posted

PS: This kind of SSDT edit works for HDEF layout-id injecting as well; maybe you should use that as your preferred method instead of an hdaenabler kext in your audio packages.

Tested and confirmed.  That was the basis of my post.

 

I could just make chameleon take the ig-platform-id as a config option so that experimenting is simple...

ErmaC Chameleon/Enoch branch supports ig-platform-id selection.

  • Like 1
Link to comment
Share on other sites
jsl
jsl
Posted
Posted

If you look at your ioreg -lw0 -r -n IGPU (or -n GFX0 depending upon how your dsdt is set up), you see the AAPL-ig-platform-id injection key and value, as well as 3 child AppleIntelFramebuffer nodes. From your ioregistry, this shows that your injection was done right and the driver attached (matched up to the real hardware).

 

Looking a little further, we can see that none of your AppleIntelFramebuffer nodes have IOFBDetailedTimings, so none of your ports picked up the EDID from your display. I don't know why; perhaps you have your BIOS set to disable your built-in graphics if pci-express graphics are installed? Have you tried without your nvidia graphics installed?

Thanks for your explanation and suggestion.

I have Enable both IGPU and Nvidia Graphics in BIOS to get this IORegistry and Load AppleIntelFramebuffer & AppleIntelHD5000.

Unfortunately if I remove my Nvidia card after booting the screen freezes after IOBluetooth completed.

So is there any further advice for me now ?

Should I put 7 SSDT.aml in /Extra too ?

Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

Wish he'd get it cleaned up & in the mainline. I see just a binary-only module in the branch.

Hi bcc9, Hi toleda,
 
ErmaC has not yet published that implementation, but I think this topic is very interesting. Unfortunately I do not have that hardware to test, for which a list of all possible ig-platform with associated device ID can help for that implementation...to put it in gma.c (lunch ready  ^_^ ...)
 
In Enoch the Key to be set for HD4000 ig-platforms in ocbp is HD4K-ig=x , but can be created another called HD5K-ig for the new Integrated GPU.
 
 
Micky
Link to comment
Share on other sites
bcc9
bcc9
Posted
  • Author
Posted

Thanks for your explanation and suggestion.

I have Enable both IGPU and Nvidia Graphics in BIOS to get this IORegistry and Load AppleIntelFramebuffer & AppleIntelHD5000.

Unfortunately if I remove my Nvidia card after booting the screen freezes after IOBluetooth completed.

So is there any further advice for me now ?

Should I put 7 SSDT.aml in /Extra too ?

Not sure what you mean by 7 SSDT. You can use a dsdt edit or an ssdt edit, up to you.

Have you tried other graphics ports on the motherboard?

Perhaps try what mirone23 did - hotplugging the HDMI after boot.

Check also if your system is logging errors in /var/log/system.log

In Enoch the Key to be set for HD4000 ig-platforms in ocbp is HD4K-ig=x , but can be created another called HD5K-ig for the new Integrated GPU.

 

here the link http://www.insanelymac.com/forum/topic/288241-intel-hd4000-inject-aaplig-platform-id/

 

Micky

Hi, thanks for the link.

 

Not sure that naming scheme is going to work out very well. The ivy bridge integrated graphics added hd graphics 4000, now the haswell graphics added hd graphics 4600/4400/4200 (and 5000/5100/5200). So thanks to intel's crazy naming scheme, that HD4K-ig key is overloaded.

 

Seems that the keyword doesn't even need the marketing number in it. I'd suggest a more general keyword such as intel-integrated, where the possible choices are built-in, and dynamically determined depending upon the PCI ID of the detected hardware.

For haswell hd graphics 4600, with PCI ID 8086:0412 the choices 0, 1, 2 could be the 3 platform-ids mentioned in this thread.

Link to comment
Share on other sites
toleda
toleda
Posted
Posted

 

I'm having black screen after installing DP4 mavericks,
using the HDMI someone has a solution?
 

What framebuffer are you using?  Even though the thread topic is DP, try the 00 00 16 04 framebuffer for HDMI boot.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...