[GUIDE] General Framebuffer Patching Guide (HDMI Black Screen Problem)

[Nodarkthings]

i7 3770 Ivy Bridge on GA-Z68XP-UD3 Sandy Bridge

Hi!
I followed your guide meticulously but can't get past stage 3. of the Preflight Checklist, no matter what I tried...

CPU: Intel i7 3770 — Ivy Bridge
Mobo: Gigabyte GA-Z68XP-UD3 (UEFI Bios U1J) — Sandy Bridge with only one physical port (HDMI)
GFX: EVGA GeForce GT210
SMBIOS: I've set Macmini6,1 as recommended by Hackintool.

Scope: make my IGPU ready in case my NVidia GT210 GC dies.

2. Lilu.kext v1.4.9 + WhateverGreen.kext v1.4.4 ok

3.
Devices --> Fake ID --> IntelGFX --> 0x01628086*
Graphics --> Inject Intel --> Checked
Graphics --> ig-platform-id : 0x01620007*
(*= values appearing in Hackintool)
I only get those 2 lines in Hackintool, no details such as QE/CI, etc. as mentioned in the guide:

Hackintool has changed a lot and I don't know for sure how your guide relates to the last versions...

I've tried other ig-platform-id 0x01660000, 5, A and B as mentioned here: https://github.com/acidanthera/What...el-hd-graphics-25004000-ivy-bridge-processors and I always get those two lines and nothing else.
As per those FAQ, I've added PciRoot(0x0)/Pci(0x16,0x0) > device-id 3A1E0000 and put the file SSDT-IMEI.dsl in /EFI/CLOVER/ACPI/patched/ but it doesn't change anything.

Nevertheless, I've tried the rest of your guide with ig-platform-id 0x0166000A (Recommended default), and the indexes are different: it's not -1,1,2,3 but 0,2,3,4...
So before going further and testing the twenty possible combinations of index/BusID, I need to know if what I get at stage 3. is what's expected for my setup?
Thank you.

 

[deeveedee]

Lesson Learned: Start UHD/HD framebuffer patching with SMBIOS MacMini8,1

Been a while since I visited this thread and wanted to post something I discovered while patching the framebuffer on an HP EliteDesk 800 G3 Mini (i7-7700T HD630 Kabylake): I discovered that initially setting SMBIOS MacModel to MacMini8,1 with WEG boot-arg igfxagdc=0 is a very "forgiving" SMBIOS for framebuffer patching. Using MM8,1 (even though it's not the correct SMBIOS for Kabylake CPU power management) made framebuffer patching much easier. I found with MM8,1 that I could reliably remote desktop into my hack after booting to black screen, so that it was easy to make framebuffer config changes to continue my framebuffer experimentation. After finding working WEG framebuffer patching with MM8,1, I then switched to iMac18,2 (the best CPU power management match for my i7-7700T) and my framebuffer patching continued to work fine.

For whatever reason, my first attempts to find correct framebuffer patches with SMBIOS iMac18,2 prevented me from remoting into my rig when incorrect framebuffer patches resulted in booting to black screen.

I hope this helps others.

 

[matony]

Hey Nodark-things: indexes change depending on your system-definition. So for now: If you have 0,2,3,4 this is fine. From what I understood, macOS can only drive 3 Monitors max. The question is: Does one of your Indexes turn red within Hackintools-Patch-Area? If so: You are pretty good to go. Use this Connector for your patch and just set the other connectors to -1 which will deactivate them. This way macOS won't try to use these frambuffers.
Correct me, if I'm wrong. I still haven't finished my own frambuffer-patch entirely. My system won't reboot, with two monitors connected. But in all other aspects, my system works as expected and I can't see any difference to a real mac.

 

[Nodarkthings]

Hey Nodark-things: indexes change depending on your system-definition. So for now: If you have 0,2,3,4 this is fine. From what I understood, macOS can only drive 3 Monitors max. The question is: Does one of your Indexes turn red within Hackintools-Patch-Area? If so: You are pretty good to go. Use this Connector for your patch and just set the other connectors to -1 which will deactivate them. This way macOS won't try to use these frambuffers.
Correct me, if I'm wrong. I still haven't finished my own frambuffer-patch entirely. My system won't reboot, with two monitors connected. But in all other aspects, my system works as expected and I can't see any difference to a real mac.

Thanks! You cleared up a few things.
I've never seen any connector turn red... But I think my issue relies on the fact that it's an Ivy Bridge CPU on a Sandy Bridge mobo, it doesn't seem to fit together perfectly.
I don't even know if I'm doing it the good way with PciRoot(0x0)/Pci(0x16,0x0) > device-id 3A1E0000 and /EFI/CLOVER/ACPI/patched/SSDT-IMEI.dsl as per WEG's FAQ... (I've compiled the SSDT myself with MacIASL, but I don't know if I must check Automerge or not, or when it crashes at boot, why? )
Gotta try again.

 

[deeveedee]

@Nodarkthings and @matony - hoping not to confuse things with my findings. For me, indices starting with 0 did not work. See my experiments here and here. As you said matony, I'm sure things are different with different system definitions. Also see my lesson learned here. Starting with MM8,1 and igfxagdc=0 greatly simplified my Kabylake HD630 framebuffer patching.

Also remember that once you introduce a video adapter on any video port (e.g. dp > dvi), framebuffer patching become much more complicated (still doable).

EDIT: one other thing (promise - last one): this may help to understand what WEG is doing behind the scenes. I attempted to patch without WEG (just to learn) and this exercise was valuable to me so that I understand what/why I was patching with WEG.

 

[deeveedee]

As per those FAQ, I've added PciRoot(0x0)/Pci(0x16,0x0) > device-id 3A1E0000 and put the file SSDT-IMEI.dsl in /EFI/CLOVER/ACPI/patched/ but it doesn't change anything.

Really dumb question for you - you put the .aml in your ACPI/patched folder - correct?

Do you want to post your EFI to get some feedback?

 

[Nodarkthings]

Really dumb question for you - you put the .aml in your ACPI/patched folder - correct?

Do you want to post your EFI to get some feedback?

Thanks! Yes, I've put the .aml in the ACPI/patched folder — that's what I understood from WEG's FAQ. Actually that file makes it crash at boot when I'm using a Sys Def or a ig-platform-id that it doesn't like... but I'm not even sure it's actually doing anything good.
I think I'm going to open a dedicated thread, because I've done so many tests that I begin to lose my mind...
I've also tested other guides, such as https://www.tonymacx86.com/threads/intel-hd-graphics-framebuffer-edits-desktop.125239/ may be better for my build as I don't have the same device id, looking at IOJones or Hackintool, depending if WEG is installed or not:
with WEG > 0x01620007
without WEG> 0x01620005
And the point is that 0x01620007 is an empty one (that I don't know how to set) and 0x01620005 makes it crash at boot...
On the other side, Toleda's guide only mentions "HD4000 ig-platform-id/0166000a"...
Can you tell me if I'm better off when I get this in System Info/Graphics Cards:

or when I get this under PCI (and only the GT210 under GC):

And what are we aiming for in the end: is it something appearing in PrefPane/Displays, like when you have only one GC? — I've never had 2 GC in a computer so I'm quite going blindly...

 

[deeveedee]

I think I'm going to open a dedicated thread

Definitely post a link to your dedicated thread and we can continue there.

 

[Nodarkthings]

Definitely post a link to your dedicated thread and we can continue there.

I'll do it as soon as possible, but can you at least answer to whether I'm on the right track having HD4000 showing in System Info/Graphics Cards or in System Info/PCI, please?
This way I'll be able to upload the best EFI folder, as a starting point.

 

[matony]

I would say: System Info/graphics cards should be populated with both: your Graphics Card and the internal graphics
System Info/PCI should only hold your graphics card
So I would use this Platform-ID
You should also check this resource for more Options on what framebuffers you could choose. For example 0x01620007 has 0 connectors so no output.(don't ask me, for what - maybe just internal rendering or so).
I'm a bit rusty with clover, as I have switched to Opencore some time ago.