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

[zzmadd]

I think you'd get more constructive responses if you shared your sanitized EFI.

I've attached my sanitised EFI.
For iGPU, with device-id 923E0000 I get sleep / wake working consistently. Other device-id, including no device-id specification lead to panic on wake from sleep.
This is the previous message text:
"
I'm having an issue with an Asus Prime H310I + i3 8100 that I'm running with the UHD 630 iGPU.
Basically in Catalina hardware acceleration works great both with H264 and H265. In Big Sur it only works with H264. HVEC/H265 hardware acceleration fails.
See attached image with DeviceProperties.
device-id is 0x3E91, I also tried 0x3E9B without success.
SMBIOS is Macmini8,1"

Any help is welcome

 

[deeveedee]

I've attached my sanitised EFI.

I think you've sanitized it too much

 

[zzmadd]

I think you've sanitized it too much

Indeed!!!

 

[deeveedee]

Indeed!!!

I am looking now - you clearly know what you are doing and I may be learning from you. I have a few observations/questions:

• I like your patching sense of humor! I never knew what AWAC stood for!
• You could eliminate DTGP, but I suspect you already know that
• Have you found that SSDT-NVME1 is necessary? I have noticed that a real Mac ACPI refers to NVME differently, but haven't patched before. What are the benefits?
• Same question for SSDT-Ethernet - Necessary? and are the benefits?
• I'm intrigued by your PPMC->PMCR rename. I have seen PPMC in another system ACPI that resembles the Mac's PMCR - very clever. Where did you find this rename patch?
• You are also injecting AirportBrcmFixup.kext/Contents/PlugIns/AirPortBrcm4360_Injector.kext and AirportBrcmFixup.kext/Contents/PlugIns/AirPortBrcmNIC_Injector.kext (in addition to AirportBrcmFixup.kext) - I haven't seen this additional kext injection method before (just because I haven't needed to). What happened when you didn't add this seperate injection and why didn't AirportBrcmFixup.kext do this for you? How did you figure this out?
• Do you still need FakePCIID.kext and FakePCIID_Intel_HDMI_Audio.kext with WhateverGreen? What happens without these?
• Your USBPorts.kext is injecting kUSB power properties and you are injecting USBX - are you finding that these conflict? Could you post your IORegistryExplorer 2.1 dump for me to look at?

EDIT: @zzmadd - one question I forgot to add above:

• You still have your 'HDAS -> HDEF' rename patch enabled. Why didn't WhateverGreen do this for you? Are you sure you still need it?

EDIT2: @zzmadd - thinking about your patches, I suspect that you are a RM student (like me). I ask myself all the time, "What Would RM Do?"

 

[zzmadd]

I like your patching sense of humor! I never knew what AWAC stood for!

You could eliminate DTGP, but I suspect you already know that

I kind of know it but...it's like a "you never know" scenario...Ok time to let it go.

Have you found that SSDT-NVME1 is necessary? I have noticed that a real Mac ACPI refers to NVME differently, but haven't patched before. What are the benefits?

In some systems you have internal NVME recognised as External. Most of the time just cosmetics.

Same question for SSDT-Ethernet - Necessary? and are the benefits?

Let's say I got used to patching names, so I actually don't know how the unpatched scenarios would unfold. It's like a mantra, a way to go over things and put a checkmark on them. The good old GLAN-->GIGE patchin Clover doesn't apply in this case so I dropped a SSDT. Probably just cosmetics.

I'm intrigued by your PPMC->PMCR rename. I have seen PPMC in another system ACPI that resembles the Mac's PMCR - very clever. Where did you find this rename patch?

I might as well ask you as I probably don't remember. I often go through other people configs. Sometimes I read OC guide. Then I drop stuff and see...it's more intuitive that really knowledgeable. Life's good though.

You are also injecting AirportBrcmFixup.kext/Contents/PlugIns/AirPortBrcm4360_Injector.kext and AirportBrcmFixup.kext/Contents/PlugIns/AirPortBrcmNIC_Injector.kext (in addition to AirportBrcmFixup.kext) - I haven't seen this additional kext injection method before (just because I haven't needed to). What happened when you didn't add this seperate injection and why didn't AirportBrcmFixup.kext do this for you? How did you figure this out?

Following he sense of wanting to rename I got used, in Clover, to rename the Wifi PCIe address to ARPT. At some point I thought why not just dropping AirportBrcmFixup.kext kext.
Then came OC and I had to implement some DW1560. Those like BrcmPatchRAM kexts in that particular order and AirportBrcmFixup.kext as well. WHat you see is the actual way OC handles those kexts. You add them and it creates 3 lines.

Do you still need FakePCIID.kext and FakePCIID_Intel_HDMI_Audio.kext with WhateverGreen? What happens without these?

No I don't. Truth is I'm having a hard time to make work AppleALC with such board. So I have no audio atm. This is going to be the next investigation. Basically the usual ways of doing it don't work. So the FakeIDs at least give me HDMI audio, that temporary are useful. Beside a sleep/wake cycle terminates it.
So I got to fix the audio.

Your USBPorts.kext is injecting kUSB power properties and you are injecting USBX - are you finding that these conflict? Could you post your IORegistryExplorer 2.1 dump for me to look at?

You see I just learned something!!! I have to delete USBX.
I can do the dump tomorrow as I'm waiting for a power supply to arrive for this little PC.

You still have your 'HDAS -> HDEF' rename patch enabled. Why didn't WhateverGreen do this for you? Are you sure you still need it?

Probably not. This one I haven't looked into it and so I drop it.

thinking about your patches, I suspect that you are a RM student (like me). I ask myself all the time, "What Would RM Do?"

RM? Who is RM? mmmmm...


Well what about the H265 hardware acceleration I was asking about...that works in Catalina and doesn't in Big Sur.
Thanks for your help!!

 

[deeveedee]

RM? Who is RM? mmmmm...


Well what about the H265 hardware acceleration I was asking about...that works in Catalina and doesn't in Big Sur.
Thanks for your help!!

I'll let you keep guessing about RM, since I know you'll remember... I was hoping that something would jump out at me for H265 and to be honest - it doesn't. What tool are you using to determine your rig's support for H265?

 

[zzmadd]

I'll let you keep guessing about RM, since I know you'll remember... I was hoping that something would jump out at me for H265 and to be honest - it doesn't. What tool are you using to determine your rig's support for H265?

One for all I try to encode a video file using handbrake using hardware acceleration and it fails.
You can pick the encoding type (videobox) but then it fails. As well as VideoProc.app fails to determine acceleration working.
As I said H264 works and Catalina has both H264/H265 working.

Thanks...

 

[deeveedee]

One for all I try to encode a video file using handbrake using hardware acceleration and it fails.
You can pick the encoding type (videobox) but then it fails. As well as VideoProc.app fails to determine acceleration working.
As I said H264 works and Catalina has both H264/H265 working.

Thanks...

I installed the free version of VideoProc.app on my rig running Big Sur 11.1 (see here) and ran its hardware detection with the results below. I think my results below indicate that VideoProc detects H265, so we know that H265 is possible with Big Sur and UHD630. My CPU is i7-8700 (CoffeeLake) and my chipset is Q370. I'll continue to look at your EFI and I encourage you to look at mine and my BIOS settings here.

EDIT: @zzmadd - here are some differences between your config and mine. Maybe worth investigating:

• you define frame buffer-stolenmem in device properties. Do you need this?
• you are not running with SIP fully enabled (csr-active-config=67 instead of csr-active-config=0)
• With MM8,1 I needed to add boot-arg igfxagdc=0 to disable AGDC for multiple displays. I'm not sure if this could also impact H265 detection?
• Your OC config.plist still contains remnants of other boot loader configs (e.g. you have PlatformInfo>PlatformNVRAM and PlatformInfo>SMBIOS (CLOVER?). These shouldn't matter, but have you tried starting with a clean sample OC config.plist and moving your settings to this clean config.plist?

 

[zzmadd]

I installed the free version of VideoProc.app on my rig running Big Sur 11.1 (see here) and ran its hardware detection with the results below. I think my results below indicate that VideoProc detects H265, so we know that H265 is possible with Big Sur and UHD630. My CPU is i7-8700 (CoffeeLake) and my chipset is Q370. I'll continue to look at your EFI and I encourage you to look at mine and my BIOS settings here.

EDIT: @zzmadd - here are some differences between your config and mine. Maybe worth investigating:

• you define frame buffer-stolenmem in device properties. Do you need this?
• you are not running with SIP fully enabled (csr-active-config=67 instead of csr-active-config=0)
• With MM8,1 I needed to add boot-arg igfxagdc=0 to disable AGDC for multiple displays. I'm not sure if this could also impact H265 detection?
• Your OC config.plist still contains remnants of other boot loader configs (e.g. you have PlatformInfo>PlatformNVRAM and PlatformInfo>SMBIOS (CLOVER?). These shouldn't matter, but have you tried starting with a clean sample OC config.plist and moving your settings to this clean config.plist?

View attachment 506168

Thanks a lot for your help!!
I will go through all the changes and report the finding soon.

EDIT: @deeveedee - I tested a config with all the modification you suggested:

• Removed buffer-stolenmem in device properties.
• Fully Enabled SIP (csr-active-config=0)
• Added boot-arg igfxagdc=0 to disable AGDC for multiple displays.
• Removed sectins from config.plist file:
  PlatformInfo>PlatformNVRAM and PlatformInfo>SMBIOS

BUT

Unluckily the result is the same...no H265 acceleration.
As I said it works in Catalina with exactly the same config file.

EDIT: @deeveedee - Iìve added my IOReg 2,1 just in case.

 

[deeveedee]

EDIT: @deeveedee - Iìve added my IOReg 2,1 just in case.

Nothing about graphics jumps out at me in your IOReg dump. Could it be that Big Sur is treating an Intel i3 differently than Catalina did? I see you're spoofing device-id 0x3e92 (same as my i7-8700). The IOReg dump from my rig running Catalina (with i7-8700) is attached. Maybe this will offer some clues. You might want to carefully examine your IOReg dumps from Catalina and Big Sur to see if you notice any differences. I'm still running Catalina as my baseline and only "visit" Big Sur for occasional testing. If you haven't solved this and I run Big Sur again, I'll post my IOReg dump with Big Sur. Sorry I don't have more to offer.

@zzmadd One other thing that I didn't inspect too closely, but you may want to examine. Your OC config.plist enables an ACPI rename of PPMC->PMCR. If you examined your extracted ACPI and found that you do indeed have a PPMC that can simply be renamed to PMCR - that's a clever solution; however, your config.plist also enables injection of SSDT-PMC.aml which also defines Device (PMCR). Are you getting any ACPI errors at boot that indicate that you have conflicting definitions of PMCR?

@zzmadd Take a close look at your IOReg dump. You'll see that you have two instances of PMCR. I only have one instance of PMCR in my IOReg, so something's not right with your PMCR patching. Without seeing your extracted ACPI, I am not sure of the proper PPMC/PMCR patching for you, but I suspect that you don't need the PPMC->PMCR rename.