Jump to content

OpenCore 0.6.3 - Multiple Graphics Issues May Be Linked

Foxy Gekkerson

14 posts in this topic

Recommended Posts

Hello everyone, I've got a potentially weird one for ya.


Motherboard: ASUS Z170 Pro Gaming

CPU: Intel Core i7-6700k

GPU: AMD RX 5600 XT Phantom Gaming

Bootloader: OpenCore 0.6.3

macOS: Catalina 10.15.0 (HDD) / 10.15.7 (SSD)


I've got a few separate graphical issues that I suspect may be linked. Like it says on the tin, I'm using OpenCore 0.6.3. Whichever macOS drive I boot into, I only get one display out of two that I have.

The first weird thing is, which drive I boot into affects which display I get. macOS on my HDD likes my DisplayPort monitor, and macOS on my SSD likes the HDMI monitor.

Windows 10 happily works with both, but that's not what I'm here for.


I've also been having trouble with iCloud on my SSD, which keeps me from using SideCar for my 12.9" iPad Pro (but troubleshooting that is another story for another day.)

So, I upgraded my HDD from Mojave to Catalina so that I can try out Sidecar, since that boot drive has iCloud working. The second weird thing is, my iPad still pulls up a black screen, just like the secondary display. No Sidebar or Touch Bar, either.

On the HDD, System Preferences > Displays does not recognize either display device, or that more than one display is attached. On the SSD, System Preferences does recognize my HDMI display, but not the DisplayPort monitor.
macOS should see a Wacom Cintiq 27QHD Touch, an HP w2338h, and a 12.9" iPad Pro when I'm using Sidecar. The third weird thing is that macOS isn't even recognizing my Cintiq's tablet drivers either, so I can't use the touch screen nor any of my styli, which is rather disconcerting.

When I'm in my HDD, I'm getting weird graphical artifacts and screen tearing as though macOS doesn't have the proper display drivers installed; this is because System Information on the HDD doesn't recognize my GPU.


To recap, (or TL;DR,) my issues in brief:

1. macOS is only seeing one display

2. Sidecar only shows a black screen

3. Wacom tablet drivers don't see my Cintiq

4. HDD doesn't recognize GPU


I'm at least 80% confident that all of these issues are linked, and that solving one of them will solve them all. In case anyone needs it, I've attached a ZIP of the EFI partition (scrubbed of the unique identifiers, of course.)

On a side note, I've only recently switched over from Clover to OpenCore, but I can't seem to find my backup of Clover. I'll see about switching back as an experiment if I can find the backup.

I appreciate any assistance you can give.


Until next time, stay foxy!

Foxy Gekkerson

Foxy's EFI.zip

Edited by Foxy Gekkerson
Clarification for how each Mac installation sees my displays. HDD doesn't recognize any display hardware, but SSD recognizes only the HDMI display.
Link to comment
Share on other sites

Also, this is what System Information says about my displays. I took this first screenshot from macOS on my HDD. I'll have to reboot to the SSD to see what the other Mac installation says and edit this post accordingly.


Thought it might be pertinent.

Foxy's Displays - Catalina HDD.png


And here's what System Information on my SSD says. This one properly recognizes my GPU and doesn't have any artifacts or screen tearing like the HDD does, but I'm still only getting one display.

To reiterate, I can't check out Sidecar since my SSD isn't letting me sign into iCloud, but that's a separate issue.


Foxy's Displays - Catalina SSD.png

Link to comment
Share on other sites

I found a backup of Clover r5119, but temporarily switching back to Clover didn't change anything with regard to how my displays work.

I also added the agdpmod=pikera boot flag to OpenCore and Clover (don't worry, I didn't cram two bootloaders into one partition,) and it doesn't change the graphics on the HDD, either; it still shows artifacts and screen tearing like there are no graphics drivers.


I'll go ahead and switch back to OpenCore since Clover offered no change, and that's what I posted this thread under.

Link to comment
Share on other sites

20 hours ago, tonyx86 said:

Are you using any video adapters (e.g. DP > HDMI or HDMI > DVI)?  If you are using video adapters to convert from one connector type to another, this dramatically changes your framebuffer patching.


I'm not using any adapters in either of my displays; just one cable end-to-end for each of them. They're both plugged into my RX 5600 XT, which in turn is plugged into the motherboard's PCIE port.

Would it be safe to say that Framebuffer patching for my integrated GPU could also fix the issues I'm having with my discrete GPU?


I also matched the UEFI settings to the ones in the guide you linked, and that didn't really produce any changes that I noticed.

Let's hope that Framebuffer patching is what does the trick.


Thanks for dropping in, bee tea dubs. :3

Link to comment
Share on other sites

I misunderstood your issue and didn't realize you were struggling with your discrete GPU.  If you want to use your discrete GPU, choose a framebuffer with 0 connectors for your integrated GPU.  Configuring your discrete GPU is different than what I posted.

Link to comment
Share on other sites

Ok - just to confirm: you are using one DP port and one HDMI port and both ports are connected to DP and HDMI ports respectively on your displays (no port conversions) - correct?


Assuming that is the case, could you please post your IORegistry dump?  Please use IORegistryExplorer 2.1 and post the output here.


Since it may be a while before I see your posted IOReg, you might want to try running without WhateverGreen.kext. I have seen others reporting success with their 5700XT (not exactly your model) and they suggest that they're having more luck when running without WhateverGreen.  To test this, you can just disable Kernel > Add > Item7. I would recommend making this test with a USB EFI so it's easy for you to recover your old config if necessary, but whatever works for you that allows you to easily recovery your known working state.


@Foxy Gekkerson I forgot to comment on you strange observation that your system behavior is different when booting with different drives.  Assuming all else is exactly the same (which is a big assumption), you could be experiencing an NVRAM issue.  I'm not an expert on this, but try clearing NVRAM before you boot on each drive and see if the behavior of the two drives returns to the same.

Link to comment
Share on other sites

Yes, my HDMI and DisplayPort monitors are both connected to my discrete GPU without adapters either end.

For the moment, I'm kinda stuck with macOS on my HDD, and that macOS installation is picking my DP monitor.

My other macOS installation on my SSD was picking my HDMI monitor, but I tried upgrading that one to Big Sur without much success, but that's another story for another day.

It'll go back to the way it was before if I restore Catalina from Time Machine.


In the meantime, I'll try scrubbing WEG from OpenCore, and see how that goes.


On a side note, I've been doing some research on my own, which leads me to a question I'm not sure is relevant.

Can a motherboard's native NVRAM support (or lack thereof) affect GPU drivers?

Long story short, I flashed the BIOS/UEFI to fix a different issue, and outside forums say that ASUS 100 series motherboards lose native NVRAM support with later BIOS versions.

I don't know if that's relevant, but if it is, it could be a new lead to follow.

Link to comment
Share on other sites

@tonyx86 Right, I forgot. Here's the IOReg output. Hopefully it's safe to upload as is and that there's nothing I need to scrub from the file the way we need to scrub from the EFI's config.plist file.


I also tried scrubbing WEG from OpenCore, and nothing changed. Should I restore it?

Foxy's iMac17,1.ioreg

Link to comment
Share on other sites

I don't think you need to enable WEG if you don't see any difference in behavior.  However, you would need WEG to use the agdpmod=pikera bootflag (which I think you do need with this card). I edited my previous post with a comment about NVRAM and the disk behavior difference you were seeing.  I'm not sure if the ASUS NVRAM issue would explain anything.  


I'm confused by your IOReg dump, because I don't see the macOS driver binding - I'm familiar with the AMD9500 driver binding that I see with my RX580, so maybe it's not the same?  Maybe you need an ACPI rename (e.g. rename GFX0 > IGPU and/or PEGP > GFX0)?  Also, have you disabled your IGPU in BIOS?


@Gigamaxx is the expert on this graphics series.  Maybe he has suggestions?

Edited by tonyx86
Link to comment
Share on other sites

EDIT: Just to keep this informative for others who may stumble upon this solution.  The GFX0 and PEGP renames that I suggest below are needed only if you're attempting a solution without WhateverGreen.  If you use WEG, WEG does this renames for you.  Read more here.



@Foxy Gekkerson I'm going to take a guess that you can try until we get "expert" advice from others: Apply two ACPI rename patches as follows:

  • Rename GFX0 to IGPU
  • Rename PEGP to GFX0

I see the entries below in your IORegistry which leads me to believe that these renames are required.


After you apply the renames, test without and with WhateverGreen.  When you test with WhateverGreen, you may need to add the agdpmod=pikera boot-arg.


Observations in your IORegistry








Your IORegistry dump suggests that GFX0 is being associated with Intel (iGPU) and PEGP is being associated with AMD (dGPU).  I think you want IGPU to be associated with Intel and GFX0 to be associated with AMD (thus the need for the renames patches).

Edited by tonyx86
Link to comment
Share on other sites

@Foxy Gekkerson Remember that link that I suggested for you here?  Did you review it yet?  I just looked at the  Z170-DELUXE_Clover_v5126.zip file that he attaches to Post #1 in his thread and guess what?  He renames GFX0 to IGPU in his CLOVER config.plist!  I think you should study that solution.  I also think that the PEGP->GFX0 rename I suggested won't hurt.

  • Thanks 1
Link to comment
Share on other sites

I don't like that a scorched-earth solution is what wound up working, but that was the route I had to take with my SSD.


Since OpenCore updated to 0.6.4, I rebuilt OpenCore from the ground up using Dortania's OpenCore guide, then wiped my SSD entirely and upgraded to Big Sur from scratch.

I even double-checked the cabling between all my displays. The upside is, *on my SSD,* Big Sur is working, I have all my displays, I can sign into iCloud, and most importantly, I even have Sidecar functional.

At this point, I'm personally satisfied, since my SSD is my primary Mac drive in the first place.


But it's not about me, it's about providing solutions for the community in case anyone else runs into this problem; I wanna make sure they have a solution.


Keep in mind I still have macOS Catalina on my HDD, so I'm still going to leave this thread open for the moment since I can't seem to boot into Catalina anymore, and troubleshooting that would probably require its own thread.

Long story short, I'm getting weird hangups while booting.

I'm at least 60% certain that double-checking the display cabling did the trick, but I'm over 90% certain that the real solution was to go into OpenCore's config.plist and making sure that DeviceProperties > Add > PciRoot(0x0)/Pci(0x2,0x0) only had the following entry: AAPL,ig-platform-id | Data | 00001219

My old config.plist had a few extra unnecessary entries tucked away in the spoiler that I suspect actually prevented the GPU drivers from loading properly.


framebuffer-patch-enable | Data | 01000000
framebuffer-stolenmem    | Data | 00003001
framebuffer-fbmem        | Data | 00009000
device-id                | Data | 1B190000


From Dortania's OpenCore guide:

  • Note: Headless framebuffers(where the dGPU is the display out) do not need framebuffer-patch-enable, framebuffer-stolenmem and framebuffer-fbmem


Once I can boot into my Catalina drive, I'll confirm that for sure and request that this thread be marked closed, unless someone else can confirm that this is the solution to similar setups to mine.

  • Like 1
Link to comment
Share on other sites

8 hours ago, Foxy Gekkerson said:

...but I'm over 90% certain that the real solution was to go into OpenCore's config.plist and making sure that DeviceProperties > Add > PciRoot(0x0)/Pci(0x2,0x0) only had the following entry: AAPL,ig-platform-id | Data | 00001219

That's the same ig-platform-id used in this solution, so you may be on to something. Note that the other solution injects the property with CLOVER's ig-platform-id, but the result is the same:





0x19120000 is not a "headless" framebuffer - it is a 3-connector mobile Skylake Framebuffer according to this, which is not what I would have picked, so this framebuffer patching really can be a game of trial and error, persistence and patience.  I would have tried the 0-connector headless framebuffer values from this:

  • 0x19020001 
  • 0x19170001
  • 0x19120001 (the one he uses in his config-headless.plist here)
  • 0x19320001


Excellent patience and persistence.  Well done!

Edited by tonyx86
  • Thanks 1
Link to comment
Share on other sites


  • Create New...