Foxy Gekkerson Posted December 6, 2020 Share Posted December 6, 2020 (edited) 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 December 7, 2020 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 More sharing options...
Foxy Gekkerson Posted December 6, 2020 Author Share Posted December 6, 2020 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. 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. Link to comment Share on other sites More sharing options...
Foxy Gekkerson Posted December 7, 2020 Author Share Posted December 7, 2020 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 More sharing options...
deeveedee Posted December 8, 2020 Share Posted December 8, 2020 (edited) @Foxy Gekkerson I saw this thread by @kushwavez after I posted my comments below (deleted). You should review that thread. Edited December 10, 2020 by tonyx86 Link to comment Share on other sites More sharing options...
Foxy Gekkerson Posted December 9, 2020 Author Share Posted December 9, 2020 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 More sharing options...
deeveedee Posted December 9, 2020 Share Posted December 9, 2020 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 More sharing options...
deeveedee Posted December 10, 2020 Share Posted December 10, 2020 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 More sharing options...
Foxy Gekkerson Posted December 10, 2020 Author Share Posted December 10, 2020 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. PS~ 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 More sharing options...
Foxy Gekkerson Posted December 10, 2020 Author Share Posted December 10, 2020 @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 More sharing options...
deeveedee Posted December 10, 2020 Share Posted December 10, 2020 (edited) 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 December 10, 2020 by tonyx86 Link to comment Share on other sites More sharing options...
deeveedee Posted December 11, 2020 Share Posted December 11, 2020 (edited) 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 Spoiler Spoiler 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 December 13, 2020 by tonyx86 Link to comment Share on other sites More sharing options...
deeveedee Posted December 12, 2020 Share Posted December 12, 2020 @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. 1 Link to comment Share on other sites More sharing options...
Foxy Gekkerson Posted December 13, 2020 Author Share Posted December 13, 2020 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. Spoiler 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. 1 Link to comment Share on other sites More sharing options...
deeveedee Posted December 13, 2020 Share Posted December 13, 2020 (edited) 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: Spoiler 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 December 13, 2020 by tonyx86 1 Link to comment Share on other sites More sharing options...
Recommended Posts