deeveedee Posted Tuesday at 09:28 PM Author Share Posted Tuesday at 09:28 PM (edited) The attached SSDT-GFX0 is replaced here ========================================= In addition to looking at revising my connectors definition to comply with the 24-byte format, I am looking at fixing the multi-display issues. This guide suggests the use of property connector-priority. I suspect that the connector-priority works only when there are multiple Radeon connectors (different from the mixed-mode dGPU / iGPU configuration of this hack), but I'm willing to experiment. A sample Radeon SSDT is provided here. Note that the sample provides example 16-byte connectors patches, so it is not helpful for our ModernConnector patch. EDIT: I am now using the attached SSDT-GFX0 with properties borrowed from Dortania's sample Radeon SSDT here. I'm not certain that I'm going to keep all of the new properties - just testing. Note that the properties in SSDT-GFX0 are combined with the config.plist DeviceProperties for PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0). SSDT-GFX0.aml.zip EDIT2: I believe that I am observing improved multi-display behavior with the attached SSDT-GFX0. I will continue to test and operate with this kext. EDIT3: I don't think that property CAIL_DisableDrmdmaPowerGating is helpful or relevant to our RX560x. I only included it because it was in the sample SSDT. Edited Wednesday at 01:38 PM by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted Wednesday at 10:06 AM Author Share Posted Wednesday at 10:06 AM (edited) The attached SSDT-GFX0 is replaced here ========================================= The attached SSDT-GFX0 has resolved the multi-display issues that I was experiencing. I now boot Sonoma and Sequoia with multiple displays (Main Display connected to the dGPU DP port and Extended Displays connected to iGPU DP ports) with no issues. The difference between the attached SSDT-GFX0 and my the attached SSDT-GFX0 in my previous post is that my latest SSDT-GFX0 eliminates the CAIL_DisableDrmdmaPowerGating property. I don't yet know which of my SSDT-GFX0 changes fixed the multi-display issues. EDIT: Note that in Sequoia, with this SSDT-GFX0, the dock is visible in both the Main and Extended displays when my dock is set to auto-hide (I can drag the cursor to the bottom of any display in Sequoia and the dock appears in that display). This is still not the case for me in Sonoma. EDIT2: I am continuing to experiment with different connectors patches in my SSDT-GFX0. I have noticed that when I test a patch that doesn't work (resulting in boot to black screen), I must reset NVRAM (sometimes multiple times) and then boot with a single-display connected to dGPU with a working connectors patch. For some reason, application of a bad patch sends the RX560x and/or macOS into a tizzy. SSDT-GFX0.aml.zip Edited Wednesday at 01:39 PM by deeveedee Link to comment Share on other sites More sharing options...
hardcorehenry Posted Wednesday at 01:10 PM Share Posted Wednesday at 01:10 PM 15 hours ago, deeveedee said: I suspect that the connector-priority works only when there are multiple Radeon connectors Seems like Whatevergreen doesn't fix connector-priority on "newer" MacOS, see issue. 1 Link to comment Share on other sites More sharing options...
deeveedee Posted Wednesday at 01:18 PM Author Share Posted Wednesday at 01:18 PM (edited) EDIT: There is still something strange about this connectors patch. I'm leaving the post below, but this patch still requires more work. It turns out that the attached patch "works" because I forgot to change the connectors Buffer length to 16 (it is still defined as a 20-byte buffer from my original patch). When the Buffer length is changed to 16-bytes, this patch no longer works. joevt believes that when the patch is defined as 20-bytes, WEG is not applying the patch. I'm inclined to agree with him, but this hack does not work without the patch (and WEG boot-arg -raddvi does not auto-patch the connector). There's something else going on which leads me to believe that I got much luckier with this RX560x patch than I initially believed here. ========================================== Many thanks to @joevt who showed me why my 16-byte patch attempt here did not work. I was forgetting to convert the pri and feat byte sequences to little endian (reverse byte order). With properly formatted feat byte sequence, the 16-byte patch now works. We still can't explain why my 20-byte patch works, too. The revised SSDT-GFX0 (with 16-byte connectors patch) is attached. @hardcorehenry Thanks! If that's the case, then it must be the addition of the "AAPL,slot-name" property that improved multi-display performance? Not sure. Some of this still seems like black magic to me. SSDT-GFX0.aml.zip Edited Wednesday at 05:28 PM by deeveedee 3 Link to comment Share on other sites More sharing options...
deeveedee Posted Wednesday at 02:09 PM Author Share Posted Wednesday at 02:09 PM (edited) I am going to stop spamming this thread with every minor issue that I discover. I will record issues (and hopefully their solution) in Known Issues. The latest issue that I discovered at the time of this post (Firefox browser) is recorded in Known Issues. Edited Wednesday at 02:11 PM by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted Thursday at 01:15 PM Author Share Posted Thursday at 01:15 PM (edited) ************************************************************************************************************************ *** Tests below are performed in macOS Sequoia Beta 2 With WhateverGreen.kext (DEBUG) version 1.6.7 (Commit 21c7ffb) *** *** and Lilu.kext (DEBUG) version 1.6.8 (Commit 4256f43). *** *** *** *** NOTE: When generating Lilu/WEG debug logs, pay attention to the time stamp. I found that after some reboots to test *** *** a new EFI, the /var/log/Lilu* debug log was not updated. I am now in the habit of checking the log time stamp *** ***. and if I don't see that the log has a new time stamp, I reboot and check again. *** *** *** *** NOTE2: My test results below are collected with SMBIOS MM8,1 and the UHD630 displays enabled. This simplifies log *** *** collection when the RX560x display boots to black-screen (can still operate with UHD630-connected displays. *** ***. I have confirmed that the display behavior remains the same when using SMBIOS iMac19,2 and a headless *** ***. UHD630. With iMac19,2, working RX560x display still requires 20-byte connectors patch. *** *** *** *** NOTE3: I have tested without WhateverGreen.kext and SMBIOS models MM8,1, iMac19,1 & iMac19,2 and display does *** *** not work at all. *** ************************************************************************************************************************ When I first published my working EFI for this hack, I stated here that there was some luck involved in my discoveries. The fact that I am only able to avoid the RX560x black-screen problem with a 20-byte connectors patch (and not the WEG-required 16 or 24-byte connectors patch) has been part of my Known Issues since I first published my working EFI. I've been confused by my test results (especially this one here which I am no longer able to reproduce) as I've attempted to figure out why my connectors patch appears to work only when it is a 20-byte patch. I am now realizing that I was much luckier than I suspected. Attached are WhateverGreen logs for the following configurations WEG-20-working-4.log: Working display. Connectors patch declared in SSDT-GFX0 as an empty, 20-byte Buffer. WEG-16-nonworking-1.log: Black screen. Connectors patch declared in SSDT-GFX0 as 16-byte Buffer and initialized such that the patch makes no change to WEG's detected RX560x connector. WEG-none-nonworking-1.log: Black screen. No connectors Buffer defined in SSDT-GFX0. WEG-none-nonworking-2.log: Black screen. No connectors Buffer and connector-count not defined in SSDT-GFX0 (connector-count was defined as 1 for the other tests). WEG-24-nonworking-3.log: Black screen. Connectors patch declared in SSDT-GFX0 as 24-byte Buffer and initialized such that the patch makes no change to WEG's detected RX560x connector. WEG-raddvi-nonworking-1.log: Black screen. SSDT-GFX0 does not define connectors or connector-count. Added -raddvi to boot-args based on this comment in previous WEG logs: rad: @ (DBG) autocorrectConnector use -raddvi to enable connector autocorrection WEG-16-raddvi-nonworking-1.log: Black screen. Connectors patch declared in SSDT-GFX0 as 16-byte Buffer and initialized such that the patch makes no change to WEG's detected RX560x connector. Addition of -raddvi boot-arg to enable connector autocorrection. WEG-20-raddvi-working-1.log: Working display. Connectors patch declared in SSDT-GFX0 as an empty, 20-byte Buffer. Addition of -raddvi boot-arg to enable connector autocorrection. The connectors patch definitions associated with WEG-20-working-4.log, WEG-16-nonworking-1.log, WEG-24-nonworking-3.log, WEG-16-raddvi-nonworking-1.log and WEG-20-raddvi-working-1.log are listed at the beginning of each log file. I have reviewed the attached logs and am unable to determine why the different connectors patching strategies produce the results that they do. Pinging @joevt and asking for help from others reviewing this. This WEG connector patching is still black magic for me and I'm not sure what WEG is doing differently for the working and non-working configurations. The only thing I know at this time is that, as long as I declare connectors (in SSDT-GFX0) as a 20-byte Buffer, the RX560x in this hack works (does not boot to black screen). When I don't declare a connectors patch or I define the connectors patch as a 16-byte value, this hack's RX560x boots to black screen. The RX560x in this hack has a single DP connector. This hack has two DP connectors driven by Intel UHD630. EDIT: I have attached the EFI that I'm using when generating the Lilu/WEG debug log. The attached EFI is working (no black screen) with an empty, 20-byte connectors Buffer defined in SSDT-GFX0. EDIT2: I have attached WEG-24-nonworking-3.log to show that the nonworking results are the same when using 16 and 24-byte connectors Buffer. EDIT3: I have attached WEG-raddvi-nonworking-1.log generated after adding boot-arg -raddvi to enable WEG connector auto-correct. While boot still results in black screen, the log includes the statement: rad: @ (DBG) autocorrectConnector found unsupported connector type 13. Not sure if this log offers any clues. EDIT4: I have attached WEG-16-raddvi-nonworking-1.log and WEG-20-raddvi-working-1.log to repeat earlier tests, but with the addition of the -raddvi boot-arg to enable WEG connector auto-correct. WEG-20-working-4.log WEG-16-nonworking-1.log WEG-none-nonworking-1.log WEG-none-nonworking-2.log EFI-MM81-RX560x-OC100-16-DEBUG.zip WEG-24-nonworking-3.log WEG-raddvi-nonworking-1.log WEG-16-raddvi-nonworking-1.log WEG-20-raddvi-working-1.log Edited Thursday at 08:48 PM by deeveedee Added debug logs with boot-arg -raddvi 1 Link to comment Share on other sites More sharing options...
joevt Posted Friday at 04:33 AM Share Posted Friday at 04:33 AM Seems kind of random. 1,2,5,7,8 don't seem to change the connector info at all. The logs show the before and after are identical. 3,4,6 only change the priority from 0 to 1. Is 0 a valid priority? -raddvi doesn't do anything because you have "unsupported connector type 13" which is CONNECTOR_OBJECT_ID_DISPLAYPORT. -raddvi is applicable to these connector types: CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_I CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D CONNECTOR_OBJECT_ID_LVDS Patches that are not 16 or 24 appear to be ignored in the WEG code, so I don't see how a 20 byte patch would affect anything. The size override works in any case, but if the size before is 1 then it's not really changing. The following two lines: *sz = consCount; DBGLOG("rad", "getConnectorsInfo got size override to %u", *sz); should be changed to this (for better logging): DBGLOG("rad", "getConnectorsInfo got size override to %u from %u", consCount, *sz); *sz = consCount; I see one interesting thing. "setting fb limit to 1" occurs in 2,3,4,5,6,7, but not 1,8. This sets a property "CFG_FB_LIMIT" in ioreg. The reason it doesn't get set for #1 and #8 is because "getConnectorsInfo conoverrides have invalid size 20". I would add some more debugging like this: void RAD::applyPropertyFixes(IOService *service, uint32_t connectorNum) { if (service && getKernelVersion() >= KernelVersion::HighSierra) { // Starting with 10.13.2 this is important to fix sleep issues due to enforced 6 screens OSObject *theProperty = service->getProperty("CFG,CFG_FB_LIMIT"); if (!theProperty) { DBGLOG("rad", "setting CFG_FB_LIMIT to %u", connectorNum); service->setProperty("CFG_FB_LIMIT", connectorNum, 32); } else { OSNumber *theNumber = OSDynamicCast(OSNumber, theProperty); if (!theNumber) { DBGLOG("rad", "CFG_FB_LIMIT is not a number!"); } else { UInt32 theVal = theNumber->unsigned32BitValue(); if (theVal == connectorNum) DBGLOG("rad", "CFG_FB_LIMIT is already set to %u", theVal); else DBGLOG("rad", "CFG_FB_LIMIT is set to %u instead of %u", theVal, connectorNum); } } // In the past we set CFG_USE_AGDC to false, which caused visual glitches and broken multimonitor support. // A better workaround is to disable AGDP just like we do globally. } } I would also maybe add a flag to disable setting `CFG_FB_LIMIT` which might allow 16 and 24 byte patches to work? But maybe research the info contained in the comments of RAD::applyPropertyFixes 1 1 Link to comment Share on other sites More sharing options...
hardcorehenry Posted Friday at 10:56 AM Share Posted Friday at 10:56 AM On 6/26/2024 at 1:10 PM, hardcorehenry said: Seems like Whatevergreen doesn't fix connector-priority on "newer" MacOS, see issue. Big apologies for link to the issue which seems to be invalid. I struggled with forcing DVI to be as first in ioreg(otherwise PP_BootupDisplayState, PP_VBlankTime and PP_RefreshRate properties are not initialized) and I managed to achieve it with "connectors"(24-byte) and "connector-priority" properties. I have no idea why it didn't work earlier so again sorry if I misled. Spoiler Link to comment Share on other sites More sharing options...
deeveedee Posted Friday at 12:06 PM Author Share Posted Friday at 12:06 PM (edited) @joevt Thank you for your thorough reply. Setting CFG,CFG_FB_LIMIT=0 allows the 16-byte connectors patch to work. Attached is the WEG debug log with a 16-byte connectors patch and CFG,CFG_FB_LIMIT=0. EDIT: Also attached is my updated SSDT-GFX0. Thank you for your time and careful review. Now I just need to learn why setting CFG,CFG_FB_LIMIT=0 "fixes" this. I'm going to run a test with only CFG,CFG_FB_LIMIT=0 (no connectors patch) to see if that also works. WEG-16-working-1.log SSDT-GFX0.aml.zip Edited Friday at 12:10 PM by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted Friday at 12:29 PM Author Share Posted Friday at 12:29 PM (edited) @joevt My luck in finding a working solution for this hack is laughable. It turns out that the only reason my 20-byte connectors patch works is because it caused WEG to throw an error that prevented WEG from setting CFG_FB_LIMIT. This hack boots macOS Sequoia Beta 2 without the RX560x black-screen issue with the simple addition of property CFG,CFG_FB_LIMIT=0. My updated SSDT-GFX0 and the associated WEG debug log are attached. Now I just need to study this and learn. Thank you again for your help. EDIT: In my next published EFI, I am going to eliminate SSDT-GFX0 and simply add the CFG,CFG_FB_LIMIT property to DeviceProperties in the OC config.plist. EDIT2: I now have a working EFI that eliminates SSDT-GFX0 and incorporates CFG,CFG_FB_LIMIT=0 and other GFX0 properties into the OC config.plist DeviceProperties. I'm going to test and review a bit more and will post my updated EFI after my review and further testing. I hope this journey is as entertaining and enlightening for you as it is for me. EDIT3: WEG debug log with my revised DeviceProperties is attached (WEG-none-working-2.log). My revised GFX0 DeviceProperties are listed at the top of the log. With these DeviceProperties, SSDT-GFX0 is no longer needed. WEG-none-working-1.log SSDT-GFX0.aml.zip WEG-none-working-2.log Edited Friday at 02:40 PM by deeveedee 1 Link to comment Share on other sites More sharing options...
deeveedee Posted Friday at 09:18 PM Author Share Posted Friday at 09:18 PM (edited) I read the following in the WhateverGreen Radeon FAQ My framebuffer amount exceeds connector amount in IOReg (starting with 10.13.2)? This is a bug Apple added by fixing another bug of incorrect connector detection from VBIOS. In certain kexts (e.g. AMD9500Controller) they hardcoded 6 connectors as a total connector amount regardless of the number read from VBIOS. The consequences are black screen after wake and/or failure to sleep. To fix this issue you should specify CFG,CFG_FB_LIMIT with a correct number, via SSDT for example. Starting with version 1.1.4 this problem is fixed automatically. It appears that the automatic behavior of WhateverGreen is to attempt to fix an incorrect CFG_FB_LIMIT. For this hack's RX560x, WhateverGreen seems to have the incorrect automatic behavior, which explains why we need to manually define CFG_FB_LIMIT. EDIT: Now that we know the culprit is CFG_FB_LIMIT, search for it and you will find many mentions in various forums. See here, for example, where vit9696 is participating in a discussion on MacRumors. EDIT2: When I said that WEG is incorrectly changing CFG_FB_LIMIT, I didn't mean to imply that there is a bug in WEG. Instead, I think that the CFG_FB_LIMIT is likely to be set differently for this RX560x than other Radeon graphics cards tested by Acidanthera. I never found a posted working solution for this HP EliteDesk 800 RX560x graphics card, so it appears that this black-screen problem has stumped everyone since the card's release in 2018. It's not very satisfying to learn that I just got lucky with my 20-byte connectors patch, but I'll take the luck this time. EDIT3: WEG's automatically handling of CFG_FB_LIMIT was discussed and addressed way back here. Edited Saturday at 02:45 PM by deeveedee 1 Link to comment Share on other sites More sharing options...
joevt Posted Friday at 11:13 PM Share Posted Friday at 11:13 PM With your original 20 byte patch, did CFG_FB_LIMIT exist in ioreg? Is there a difference in behaviour with CFG_FB_LIMIT not existing, and CFG_FB_LIMIT=0? Link to comment Share on other sites More sharing options...
deeveedee Posted Friday at 11:53 PM Author Share Posted Friday at 11:53 PM (edited) @joevt yes, with the 20-byte connectors patch, CFG_FB_LIMIT=0 exists in ioreg. That's the first thing I looked at after you interpretted the debug logs. Thank you again for your help! EDIT: Not sure about difference in behaviour between CFG_FB_LIMIT not existing and CFG_FB_LIMIT=0, but I didn't need to test that. EDIT2: @joevt Here's the IOReg after booting Sequoia Beta 2 with an empty, 20-byte connectors patch: Spoiler EDIT3: Here's the IOReg after booting Sequoia Beta2 with no connectors patch and CFG,CFG_FB_LIMIT=0. Note that in my DeviceProperties, CFG,CFG_FB_LIMIT=0 (number) but in IOReg, CFG,CFG_FB_LIMIT=<00 00 00 00> (data). Not sure why, but it doesn't seem to matter. Spoiler DeviceProperties: CFG,CFG_FB_LIMIT=0 Spoiler EDIT4: Here's the IOReg after booting Sequoia Beta 2 without defining CFG,CFG_FB_LIMIT=0. WEG is automatically and incorrectly changing the already defined CFG_FB_LIMIT to 1 which results in booting RX560x-connected display on this hack to black-screen. Spoiler EDIT5: Maybe a pri=0000 is correct for this RX560x (so I shouldn't be overriding Priority to 1). EDIT6: @joevt In EDIT4, I said that WEG is incorrectly changing CFG_FB_LIMIT. I didn't mean to imply that there was a bug in WEG. Instead, I think that the CFG_FB_LIMIT is likely to be set differently for this RX560x than other Radeon graphics cards tested by Acidanthera. I never found a posted working solution for this HP EliteDesk 800 RX560x graphics card, so it appears that this black-screen problem has stumped everyone since the card's release in 2018. It's not very satisfying to learn that I just got lucky with my 20-byte connectors patch, but I'll take the luck this time. Edited Saturday at 11:32 AM by deeveedee Link to comment Share on other sites More sharing options...
joevt Posted Saturday at 01:32 AM Share Posted Saturday at 01:32 AM Oh, I didn't notice that CFG,CFG_FB_LIMIT and CFG_FB_LIMIT are two different things. The following describes the purpose of the "CFG," prefix: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.Radeon.en.md Any property with a "CFG," prefix is then used to override the same property without the "CFG," prefix. This is handled by RAD::wrapGetProperty which calls RAD::mergeProperties. So your setting of CFG,CFG_FB_LIMIT doesn't change the original setting of CFG_FB_LIMIT because it is already zero. Having CFG,CFG_FB_LIMIT just stops RAD::applyPropertyFixes from changing CFG_FB_LIMIT to 1 (the number of connectors in the connectors list). 1 1 Link to comment Share on other sites More sharing options...
deeveedee Posted Saturday at 01:35 AM Author Share Posted Saturday at 01:35 AM (edited) 11 minutes ago, joevt said: So your setting of CFG,CFG_FB_LIMIT doesn't change the original setting of CFG_FB_LIMIT because it is already zero. Having CFG,CFG_FB_LIMIT just stops RAD::applyPropertyFixes from changing CFG_FB_LIMIT to 1 (the number of connectors in the connectors list). That was the only way I could think to stop WEG from changing CFG_FB_LIMIT (after I confirmed that it was 0 with a 20-byte connector). I'm open to your suggestion if you think there is a better way. EDIT: I removed my connector-priority=1 property (allowing pri=0000 to remain unchanged). I don't think it makes a difference with the single DP connector on this RX560x, but I'll continue to test. Edited Saturday at 01:44 AM by deeveedee Link to comment Share on other sites More sharing options...
deeveedee Posted Saturday at 01:37 PM Author Share Posted Saturday at 01:37 PM (edited) For those who are following this thread and who may be confused by the current solution baseline, the unchanged EFI attached to Post #1 still works fine, but not for the reasons that I initially thought it worked. I won't be attaching a new EFI to Post #1 until after the next Open Core release, so if you want to create your own EFI with the latest working solution, use the EFI attached to Post #1 and replace EFI/OC/ACPI/SSDT-GFX0.aml with the SSDT-GFX0 attached here. The next EFI that I post will remove SSDT-GFX0 and insert the required GFX0 property assignment CFG,CFG_FB_LIMIT=0 into the Open Core config.plist DeviceProperties. The connectors patch is not required for this hack's RX560x. EDIT: Continue to monitor Known Issues here. Edited Saturday at 02:29 PM by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted yesterday at 09:54 AM Author Share Posted yesterday at 09:54 AM (edited) See candidate multi-display solution in next post. ========================================== If you would like to help with testing multiple displays (or you're just curious about multi-display testing), this post is for you. I would greatly appreciate test help, so if you are able to test and experiment with multiple displays, please report your test configuration and results in this thread. Thank you. Now that the black-screen issue is fully understood, I'd like to focus on the continuing multi-display issues that I am seeing. I am still finding occasional anomalies when using multiple displays (with one display connected to the RX560x (dGPU) DP port and one or two displays connected to one or both of the UHD630 (iGPU) DP ports). If you are interested in helping to test, here's what I am finding so far: Whenever I Reset NVRAM (from Open Core boot menu), I must first boot macOS with only the dGPU display powered on. After macOS boots and I login, I can turn on the other display(s). After one successful boot cycle (single display at boot followed by turning on additional displays after login), I can leave all displays on during subsequent boot / login cycles (until the next NVRAM Reset). When I first started creating the macOS solution for the HP EliteDesk 800 G4 Mini in May 2020, I needed to disable iGFX AGDC to enable multi-display operation (initially using a kext patch and then ultimately using WhateverGreen boot-arg igfxagdc=0) (Thanks @shuhung for his AppleGraphicsDevicePolicy tip here). I tried disabling AGDC for the RX560x (using DeviceProperty CFG,CFG_USE_AGDC=false), but this results in RX560x black-screen I am not sure if setting the connector priority for the RX560x matters (using DeviceProperty connector-priority=<01>). I am experimenting with and without this DeviceProperty and am not sure I see a difference. Spoiler I am not sure if setting a mask for boot-arg igfxonln=1 matters (using boot-arg igfxonlnfbs=0x0102 to restrict igfx force-online to only UHD630 framebuffer connector indices 1 and 2). I am experimenting with and without boot-arg igfxonlnfbs=0x0102 and am not sure I see a difference. The only reason I thought to test igfxonlnfbs=0x0102 is that our UHD630 has only two connectors now that the RX560x is the 3rd connector. I have not yet tested a configuration where a UHD630-connected display is Main and the RX560x display is an Extended display. Maybe this resolves the multi-display issues? I have not yet thoroughly tested with SMBIOS models iMac19,1 and iMac19,2, so I'm not sure if somehow these SMBIOS models would have better multi-display behavior. Note that iMac19,2 offers an optional RX560x. I have not yet experimented with injection of EDID for the displays. My configuration for my multi-display testing is as follows: SMBIOS: macMini8,1 (using EFI attached to Post #1 with SSDT-GFX0 here). BIOS: boot display set to RX560x macOS: Main display set to RX560x-connected display macOS: Extended display(s) set to UHD630-connected display(s) DP->DVI adapters on all displays (my displays have DVI ports, so I must use the DP->DVI converters). The EFI attached to Post #1 includes the UHD630 DeviceProperties required for my DP->DVI adapters. The RX560x DeviceProperties do not appear to change regardless of whether a converter is used (e.g., same RX560x DeviceProperties for DP->DP, DP->HDMI and DP->DVI). If you are not using DP->DVI converter on your UHD630-connected displays (e.g., you are using DP->DP), you should use different UHD630 DeviceProperties as defined here. Edited 2 hours ago by deeveedee 2 Link to comment Share on other sites More sharing options...
deeveedee Posted 22 hours ago Author Share Posted 22 hours ago (edited) EDIT: It appears that the only configuration item that needs to be changed to resolve the multi-display issues is to set Integrated GPU as boot display in BIOS. I don't know if this is an HP BIOS issue, an Open Core issue or a macOS issue. With the following configuration, my hack appears to be trouble-free with multiple displays. Leaving the post below for history. I still welcome multi-display test results from others. Working configuration for two displays with HP EliteDesk 800 RX560x dGPU BIOS: boot display set to Integrated GPU (UHD630) - this appears to be the most important factor in resolving multi-display issues with the RX560x-equipped EliteDesk 800 Mini. SMBIOS: macMini8,1 (EFI attached to Post #1 with SSDT-GFX0 from here) DeviceProperties > dGPU ( PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) ) : connector-priority is NOT specified (this leaves pri=0000 in framebuffer connector) DeviceProperties > dGPU ( PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) ) : @0,AAPL,boot-display (cosmetic - sets Apple logo to appear on RX560x-connected display during second boot-stage before login). With iGPU set as boot display in BIOS, Apple logo will appear on iGPU-connected display during boot-stage 1 and then Apple logo will move to dGPU-connected display during boot-stage 2. Additional boot-args: igfxonlnfbs=0x0102 (not sure this is necessary, but it doesn't hurt) macOS: Main display set to the display on RX560x macOS: Extended display set to display on UHD630 connector index 1 With the configuration above (boot display set to Integrated GPU in BIOS), there is no need to power-off / power-on displays during boot / login and Firefox hardware acceleration can be enabled. About This Mac reports display as RX560x. EDIT2: Note that after setting dGPU DeviceProperty @0,AAPL,boot-display=<01000000>, the Apple Logo behavior during boot-stage 2 is as I described, but IORegistry still shows AAPL,boot-display=True for iGPU (and AAPL,boot-display=<01000000> for dGPU). This doesn't seem to matter. I tried forcing iGPU @0,AAPL,boot-display=False with a DeviceProperty, but it wouldn't change. Spoiler ============================================== Multi-display test results (in progress): I am currently testing two displays with the following configuration with initial observations suggesting that observed problems have been resolved: SMBIOS: macMini8,1 DeviceProperties > iGPU ( PciRoot(0x0)/Pci(0x2,0x0) : @0,AAPL,boot-display DeviceProperties > dGPU ( PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) ) : connector-priority is NOT specified BIOS: boot display set to UHD630 (Integrated GPU) macOS: Main display set to the display on UHD630 connector index 1 macOS: Extended display set to display on RX560x Additional boot-args: igfxonlnfbs=0x0102 Problems that are resolved with this configuration: No need to power off and on any displays for booting / login No need to disable hardware acceleration in Firefox browser Observations: GeekBench 6 metal benchmarks appear unchanged for RX560x Spoiler About This Mac reports graphics as UHD630 Spoiler Specifying property "@0,AAPL,boot-display" for the iGPU or dGPU does nothing more than determine where the second boot-stage Apple logo appears before login. No other observations / behaviors appear to change. Changing only the boot display in BIOS to Radeon dGPU without changing any other configuration settings results in multi-display anomalies. In other words, whenever boot display is set to RX560x in BIOS, previously mentioned multi-display anomalies are observed. Changing only the Main display in macOS System Settings > Displays to RX560x-connected display (leaving BIOS boot display as Integrated GPU) appears to allow macOS to boot without the previously mentioned multi-display issues and About This Mac reports the graphics as RX560x. It appears to me that all multi-display issues are resolved as long as the Integrated GPU is set to boot display in BIOS. Spoiler With dGPU DeviceProperty @0,AAPL,boot-display=<01000000>, the Apple logo appears on the dGPU-connected display during boot-stage 2 as I described earlier. What's interesting is that IORegistry Explorer shows that AAPL,boot-display=True for the iGPU Spoiler This doesn't seem to matter. I tried forcing iGPU @0,AAPL,boot-display=False in DeviceProperties, but AAPL,boot-display remains True for the iGPU in IORegistry. Edited 2 hours ago by deeveedee Added multi-display solution as EDIT to beginning of post 2 Link to comment Share on other sites More sharing options...
Recommended Posts