Intel Framebuffer patching using WhateverGreen

[TUNIN96]

Hello guys, how can I patch my igpu on i7 1065g7? I already tried to do it with Hackintool, but my laptop always goes in kernel panic.

[deeveedee]

@MacKonsti Not sure if this helps you, but have you tried looking at the ACPI / IOReg dump from a real MacBookPro15,2 to see if it offers any clues?  I Googled and found a MacMini8,1 IOReg dump and ACPI dump on AppleLife (MacMini8,1 is the SMBIOS MacModel I'm using for my HP EliteDesk 800 G4 Mini).

Edited June 14, 2020 by tonyx86

[deeveedee]

On 6/8/2020 at 11:04 AM, Takiller said:

 To be honest with you it is now almost two months trying to get this right, googling and even trying my luck with different EFIs from other users. My IORegistry which I also attached shows that the patch is fine with the 00080000 for HDMI, but as soon as I plug the HDMI cable it changes back to the DP 00040000. it is like there's another patch pushing back the DP.

CLOVER.zip

IORegBeforeHDMI.zip

 

While experimenting with my HP EliteDesk 800 G4 Mini, I found what I think is behavior similar to the "patch pushing back" behavior that you observed.  See my experiment here.  Depending on my choice of device-id in my IGPU device properties, my connector-types may not be consistent with my configured patches.  I don't know if this helps you, but in my case, the choice of the correct device-id (0x3e92 for me) vs. the device-id for a MacMini8,1 (0x3e9b) seems to influence my patching behavior.

 

Maybe you need to experiment with other device-ids?

[MacKonsti]

6 hours ago, tonyx86 said:

@MacKonsti Not sure if this helps you, but have you tried looking at the ACPI / IOReg dump from a real MacBookPro15,2 to see if it offers any clues?  I Googled and found a MacMini8,1 IOReg dump and ACPI dump on AppleLife (MacMini8,1 is the SMBIOS MacModel I'm using for my HP EliteDesk 800 G4 Mini).

Thanks, I do have a MacMini dump but the question is, what is the alternative to FakePCIIDs for digital output on DP/HDMI? Do I inject a fake HDAU device? At what address? My PCI devices don't include such a B0D3/HDAU at all. What is the mechanism behind FakePCIIDs for HDMI audio that can or cannot be replicated with other (recent) methods? That is my question...

[Takiller]

On 6/14/2020 at 5:53 PM, tonyx86 said:

 

While experimenting with my HP EliteDesk 800 G4 Mini, I found what I think is behavior similar to the "patch pushing back" behavior that you observed.  See my experiment here.  Depending on my choice of device-id in my IGPU device properties, my connector-types may not be consistent with my configured patches.  I don't know if this helps you, but in my case, the choice of the correct device-id (0x3e92 for me) vs. the device-id for a MacMini8,1 (0x3e9b) seems to influence my patching behavior.

 

Maybe you need to experiment with other device-ids?

Thanks for your assistance, as I think I finally got my HDMI working today with a different DSDT.aml I found while googling and I am trying to see the difference to the previous one I was using. I first had to install High Sierra in order to experiment with it, as the user I got it from was on Sierra and after seeing that it was working, I then moved it to Catalina. The only issue so far is that it only works if I boot with the HDMI connected, as it does not allow hot plugging. 

[deeveedee]

On 6/14/2020 at 4:07 PM, MacKonsti said:

Thanks, I do have a MacMini dump but the question is, what is the alternative to FakePCIIDs for digital output on DP/HDMI? Do I inject a fake HDAU device? At what address? My PCI devices don't include such a B0D3/HDAU at all. What is the mechanism behind FakePCIIDs for HDMI audio that can or cannot be replicated with other (recent) methods? That is my question...

 

@MacKonsti, I looked around and found others who are not using WhateverGreen, so I'm not sure how to advise you.  Maybe it's best for you not to use it?  I am curious about your performance claims and would like to test my UHD 630 performance without WhateverGreen.  I need to change the default connector types, but I haven't figured out how to change the default connector-type without WhateverGreen.  I tried "@0,connector-type" thinking that it would duplicate WhateverGreen's framebuffer-con0-type property, but it did not change the connector type.

 

Does anyone know how to change UHD 630 connector types without WhateverGreen?

 

EDIT: I think this post should point me in the right direction?

 

EDIT2: It looks like the clues are already in this guide.  The guide gives the kext to patch (for Coffee Lake UHD 630, the kext is AppleIntelCFLGraphicsFramebuffer.kext) and it gives the hex to find.  For Coffee Lake UHD 630 0x3e920000, its 00000800 02000000 98000000, 
01050900 00040000 87010000, 02040A00 00040000 87010000.

Edited June 27, 2020 by tonyx86

[deeveedee]

I did some experimentation with framebuffer device properties for my I7-8700T / UHD 630 and am seeing quicker wake-from-sleep behavior after removing some unnecessary (for me) injected device properties.  See my experiment results / changes here.

[deeveedee]

This question is for anyone who has a thorough understanding of WEG and what / how it does its "magic."

 

I'd like to better understand what WEG is doing to patch my UHD 630 graphics (working perfectly with WEG).  I have attempted to patch my UHD 630 graphics here without WEG, but after a few reboots, graphics has glitches during boot (before the login prompt) and sometimes graphics boots to black screens (with monitors on).

 

I would appreciate some suggestions from someone who knows how WEG works and what it is doing to help me understand why my "manual" patches here don't work when WEG works fine.  What am I missing?

 

EDIT: I suspect that there are other UHD 630 graphics attributes that WEG is defining and that I have not defined with my manual patches.

 

Thank you.

Edited July 3, 2020 by tonyx86

[headkaze]

1 hour ago, tonyx86 said:

I'd like to better understand what WEG is doing to patch my UHD 630 graphics (working perfectly with WEG).

Back when the macOS Mojave beta 1 was released I discovered the Intel framebuffer data was no longer stored as a struct in the kext binary for easy patching using KextToPatch. I then contacted vit9696 and we devised a new patching system that would hook into the gPlatformInformationList data in memory and provide a mechanism for patching the data directly in memory.

 

WhateverGreen provides a couple of boot args to dump the platform list data from memory:

-igfxdump to dump IGPU framebuffer kext to /var/log/AppleIntelFramebuffer_X_Y (available in DEBUG binaries).
-igfxfbdump to dump native and patched framebuffer table to ioreg at IOService:/IOResources/WhateverGreen

If you want to take a look at the binary dumps they are located in the Hackintool repo. There's also a detailed explanation of the data layout in IntelFramebuffer.bt.

 

applyFramebufferPatches located in kern_igfx.cpp is the method used to patch the gPlatformInformationList data in memory.

 

It's likely still possible to patch the kext framebuffer binaries but because data is not in an organized layout anymore the patches are likely to break every update.

 

For the sake of argument if you want to try and patch the kext binary anyway you can open the framebuffer kext in a hex editor (eg. /System/Library/Extensions/AppleIntelKBLGraphicsFramebuffer.kext/Contents/MacOS/AppleIntelKBLGraphicsFramebuffer). You can see from the screenshots the data is in there; it's just not organized into a nice structure. As long as your patch can find and replace this data appropriately then the patch should in theory work. That being said it's not a recommended way to patch anymore so I advise against it.

Edited July 3, 2020 by headkaze

[MacKonsti]

Hi @headkaze good to see you active again! Can I please have your comment on my earlier post in this page?

 

Could you understand why I would get a "RAW" power of +80% on Geekbench 4 without using WhateverGreen.kext (namely about 55110 as OpenCL Score) and the moment I include WhateverGreen.kext in /L/E/ on Mojave, the score falls to 38175 approximately? Besides the fix for Safari mentioned in the GitHub notes (embedded video playback) being probably missed, the only other thing I get during boot is a "pink flash" for a brief moment. But can't see why WhateverGreen would provide these Geekbench results -- unless it's a misleading number and not a true one?  (kindly refer to my post for IDs etc)  Thanks!

[deeveedee]

1 hour ago, MacKonsti said:

But can't see why WhateverGreen would provide these Geekbench results -- unless it's a misleading number and not a true one?  (kindly refer to my post for IDs etc)  Thanks!

 

Headkaze is definitely the one to help.  Would you mind posting your IORegistryExplorer dumps for the two cases (with and without WEG)?

[headkaze]

22 hours ago, MacKonsti said:

Hi @headkaze good to see you active again! Can I please have your comment on my earlier post in this page?

 

Could you understand why I would get a "RAW" power of +80% on Geekbench 4 without using WhateverGreen.kext (namely about 55110 as OpenCL Score) and the moment I include WhateverGreen.kext in /L/E/ on Mojave, the score falls to 38175 approximately? Besides the fix for Safari mentioned in the GitHub notes (embedded video playback) being probably missed, the only other thing I get during boot is a "pink flash" for a brief moment. But can't see why WhateverGreen would provide these Geekbench results -- unless it's a misleading number and not a true one?  (kindly refer to my post for IDs etc)  Thanks!

I would check out the differences in Intel Power Gadget and also check your PStates.

 

Not sure what the alternative to FakePCIIDs is. These kexts inject data into the PCI table and I don't believe this ability is available to WhateverGreen or AppleALC. You could try adding a device-id entry for your audio device in Device / Properties in config.plist. According to the Intel_HDMI_Audio.plist the entry for 8086:9dc8 would look like this:

<key>device-id</key>
<data>cKEAAA==</data>

So according to this it's spoofing your 9dc8 device as a170

Edited July 4, 2020 by headkaze

[MacKonsti]

Thank you @headkaze for your reply.

 

I could not replicate the issue first detected with early Mojave versions and early WhateverGreen.kext where the Geekbench graphics score went up to 55000, perhaps later Mojave drivers for IGPU changed (or used the Apple GuC firmware natively, who knows, but igfxfw=2 does not increase performance or score, today). All I can tell you is that if I do not "force" some AAPL,ig-platform-id I get lower GPU scores when using WhateverGreen natively-vanilla, just tested today:

 

On my NUC8i7BEH computer with Intel Corporation Iris Plus Graphics 655 [8086:3ea5] (rev 01) set as MacMini8,1 in SMBIOS:

 

Scenario 1) Clean Clover configuration, no device properties patching for graphics, using WhateverGreen vanilla;

AAPL,ig-platform-id is set as <07 00 9b 3e> that I think belongs to MacMini8,1 but it's not 0x3E9A0000 as my hardware

Geekbench IGPU score for OpenCL is 23617 approx.

 

Scenario 2) Clover configuration forcing device property AAPL,ig-platform-id to use either <04 00 a5 3e> 0x3EA50004 (MacBookPro) or 0x3EA50009;

Geekbench IGPU score for OpenCL is 38550 approx.

A slightly higher score (39352) is obtained when no  AAPL,ig-platform-id is injected in Clover device properties (I get only device-id 0x3EA50000) and disabling WhateverGreen via -wegoff

 

I am not sure if these are expected results?

 

As for replacing FakePCIID.kext and the injection of HDMI Audio: My computer has no HDAU or B0D3 device natively. Perhaps this is the reason?

Would making an SSDT that adds to GFX0 (renamed to IGPU via WhateverGreen) a device under it with name HDAU and ADDR 0x00 make the system find the sound-output for HDMI?

 

Thank you!

Edited July 4, 2020 by MacKonsti

[MacKonsti]

52 minutes ago, headkaze said:

Not sure what the alternative to FakePCIIDs is. These kexts inject data into the PCI table and I don't believe this ability is available to WhateverGreen or AppleALC. You could try adding a device-id entry for your audio device in Device / Properties in config.plist. According to the Intel_HDMI_Audio.plist the entry for 8086:9dc8 would look like this:

<key>device-id</key>
<data>cKEAAA==</data>

So according to this it's spoofing your 9dc8 device as a170

 

I am not sure it's changing it completely, mate. Besides, I cannot find any reference to 0xA170... Using FakePCIID.kext and its HDMI Audio injection, I get 2 different audio Codec devices under HDEF now, as posted earlier. Allow me to repeat that the ACPI/firmware has no HDAU or B0D3 device present...

 

IOHDACodecDevice@1F,3,0 --> the original one

IOHDACodecDevice@1F,3,2 --> the added one for DP/HDMI output

 

 

So could it be that FakePCIID+HDMI Audio injection create a new digital audio device? Especially in the absence of a HDAU-B0D3 absence?

Edited July 4, 2020 by MacKonsti

[headkaze]

8 minutes ago, MacKonsti said:

I am not sure it's changing it completely, mate. Besides, I cannot find any reference to 0xA170...

Yes, it's likely adding a device not spoofing so probably no way to do that using just Devices / Properties.

 

I'm referring to this entry in Intel_HDMI_Audio.plist (which is used by FakePCIID_Intel_HDMI_Audio.kext).

        <key>Intel HDMI Audio - 300-series 0xa348 0x9dc8</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>org.rehabman.driver.FakePCIID</string>
            <key>IOClass</key>
            <string>FakePCIID</string>
            <key>IOMatchCategory</key>
            <string>FakePCIID</string>
            <key>IOPCIPrimaryMatch</key>
            <string>0xa3488086 0x9dc88086</string>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
            <key>FakeProperties</key>
            <dict>
                <key>RM,device-id</key>
                <data>cKEAAA==</data>
            </dict>
        </dict>

Check out the value in a plist editor (or convert the above Base64 to hex). So it's adding an a170 HDMI audio device. I don't know of any other way to add this device so you may have to keep using FakePCIID_Intel_HDMI_Audio.kext

[MacKonsti]

So from your experience, since my computer has no HDAU device natively like other desktops, would making an SSDT that adds to GFX0 (renamed to IGPU via WhateverGreen) such a device under it with name HDAU so that the system detects the sound-output for HDMI? I've seen some SSDT code for laptops adding HDAU right under the graphics device, but not sure if it was for NVIDIA or AMD... perhaps WhateverGreen in combination with AppleALC would make this injected HDAU device active...

[headkaze]

6 minutes ago, MacKonsti said:

So from your experience, since my computer has no HDAU device natively like other desktops, would making an SSDT that adds to GFX0 (renamed to IGPU via WhateverGreen) such a device under it with name HDAU so that the system detects the sound-output for HDMI? I've seen some SSDT code for laptops adding HDAU right under the graphics device, but not sure if it was for NVIDIA or AMD... perhaps WhateverGreen in combination with AppleALC would make this injected HDAU device active...

I don't know if an SSDT can create a fake PCI device but I guess you could try? Can anyone else confirm or deny this approach?

[978b029efa981d618699b09868]

On 7/4/2020 at 5:51 PM, headkaze said:

I would check out the differences in Intel Power Gadget and also check your PStates.

 

Not sure what the alternative to FakePCIIDs is. These kexts inject data into the PCI table and I don't believe this ability is available to WhateverGreen or AppleALC. You could try adding a device-id entry for your audio device in Device / Properties in config.plist. According to the Intel_HDMI_Audio.plist the entry for 8086:9dc8 would look like this:

<key>device-id</key>
<data>cKEAAA==</data>

So according to this it's spoofing your 9dc8 device as a170

WhateverGreen does fake PCI device ID: https://github.com/acidanthera/WhateverGreen/blob/master/WhateverGreen/kern_weg.cpp#L705

[deeveedee]

On 7/7/2020 at 5:08 AM, 978b029efa981d618699b09868 said:

WhateverGreen does fake PCI device ID: https://github.com/acidanthera/WhateverGreen/blob/master/WhateverGreen/kern_weg.cpp#L705

It's a pleasure to meet the person who took the user name that I wanted!  I looked at your link and can't figure out how it demonstrates that WEG "does fake PCI device."  Would you care to explain?

 

@MacKonsti I looked in the IORegistry dump for what is supposed to be a real MacMini8,1 (which has UHD 630 and an HDMI 2.0 port) and there is no HDAU device.  Are you sure that you need an HDAU device for working HDMI audio?

Edited July 14, 2020 by tonyx86

[Andrey1970]

HDAU only for Haswell/Broadwell IGPU or discrete GPU.

[MacKonsti]

28 minutes ago, Andrey1970 said:

HDAU only for Haswell/Broadwell IGPU or discrete GPU.

So not for Coffee Lake or Whiskey Lake, for example? Interesting, I guess.

 

@tonyx86 it was just a guess i.e. the use of HDAU, in order to be able to attach the audio codec that FakePCIID succeeds with the HDMI Audio injection Oh well.

Edited July 14, 2020 by MacKonsti

[978b029efa981d618699b09868]

14 hours ago, tonyx86 said:

It's a pleasure to meet the person who took the user name that I wanted!  I looked at your link and can't figure out how it demonstrates that WEG "does fake PCI device."  Would you care to explain?

 

@MacKonsti I looked in the IORegistry dump for what is supposed to be a real MacMini8,1 (which has UHD 630 and an HDMI 2.0 port) and there is no HDAU device.  Are you sure that you need an HDAU device for working HDMI audio?

Oh, the line numbers are off now because master updated. You should check WEG::processBuiltinProperties and wrapConfigRead16. Essentially, it hooks PCI configuration space read handler to return the desired device ID instead of the real one.

[deeveedee]

2 hours ago, 978b029efa981d618699b09868 said:

Oh, the line numbers are off now because master updated. You should check WEG::processBuiltinProperties and wrapConfigRead16. Essentially, it hooks PCI configuration space read handler to return the desired device ID instead of the real one.

Thanks!  I looked at void WEG::processBuiltinProperties(IORegistryEntry *device, DeviceInfo *info) and see that it is used to "rename" an existing video device and "cast" it as another device.  Is WEG actually able to "create" a new device that does not already exist?

[Neblogas]

well, if I disable IGPU & IMEI renames in clover, my system does not boot. Also deleting fakepciidhdmiaudio.kext my Audio doen not work anymore.

 

short to speak: if I do everything as in the whatevergreen manual - nothing works, system does not boot anymore.

 

i7 10510U

Catalina 10.5.5

Mojave 10.14.6

newest kexts

 

What I want to fix is only the HDMI. When I connect external monitor I just get mouse lagging, till I disconnect HDMI cable.

[MisterKeeks]

I'm wondering if there is a way to use Whatevergreen to tell macOS that a display is internal and is of type "AppleBackLightDisplay" rather than "AppleDisplay"? 

 

I have a Dell 9010 AIO with a built-in LCD panel (M230HGE-L20) connected over LVDS. The GPU is Intel HD 4000 graphics on an i5-3475S. I am using the latest Whatevergreen with OpenCore 0.5.9. Right now I

• lose backlight after sleep - I can see display if I shine a light on it
• Don't have any brightness adjustment

Here is my Whatevergreen info in config.plist (I've uploaded the whole thing in a zip on this post too). 

 

Note that AAPL02,override-no-connect is in use to correct the EDID so that macOS uses RBG instead of YCbCr.

Here is an IORegistry Explorer Screenshot (more screenshots in attachments).

 

Note that it says "AppleDisplay" and not "AppleBacklightDisplay". 

In System Profiler, it says that the Connection Type is Analog VGA or Analog of DVI-I:

I think this is wrong, because I believe the display is connected over Digital LVDS. Isn't Analog VGA output not even possible anymore?

 

I've also used both SSDT-PNLF.aml (generic) and SSDT-PNLF-SNB_IVB.aml - both of these are in the attached EFI, and backlight does not work. 

 

Is it possible that I need to tweak SSDT-PNLF.aml because this is a desktop, not a laptop? I'm not sure if macOS doesn't see any backlight device to hook into - or if it isn't looking for one because it thinks the display is internal. 

 

If necessary, the original DSDT dump is located under "Results" in the attached EFI. Please let me know what information I left out from this post and I will find it. 

 

Also, thanks for making Whatevergreen possible. I'm typing this on a Kaby Lake Dell Inspiron using Whatevergreen and it is fantastic!

EFI.zip