HP EliteDesk 800 G4 / G5 Mini with RX560x dGPU (hackintosh)

[deeveedee]

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

[deeveedee]

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

[hardcorehenry]

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.

[deeveedee]

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

[deeveedee]

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

[deeveedee]

************************************************************************************************************************

*** 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

1. WEG-20-working-4.log: Working display.  Connectors patch declared in SSDT-GFX0 as an empty, 20-byte Buffer.
2. 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.
3. WEG-none-nonworking-1.log: Black screen. No connectors Buffer defined in SSDT-GFX0.
4. 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).
5. 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.
6. 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
7. 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.
8. 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

[joevt]

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

[hardcorehenry]

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

 

[deeveedee]

@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 yesterday at 12:10 PM by deeveedee

[deeveedee]

@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 21 hours ago by deeveedee

[deeveedee]

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.

Edited 7 minutes ago by deeveedee

[joevt]

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?

 

[deeveedee]

@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 49 minutes ago by deeveedee

[joevt]

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).

 

[deeveedee]

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 10 hours ago by deeveedee