Dump Request: MacbookPro16,1 / MacbookPro16,4

[Fortitude]

Hello,

I was wondering if anyone here could we willing to please link or upload for me a full dump of at least one of the 16 inch 2019 MacBook Pros with AMD graphics? If I can get three separate dumps though for each of the available dGPUs (5300M, 5500M, 5600M) that would be awesome if anyone here owns one or more of these laptops. I’d also like to request that an attached IOreg file can be easily opened within Apple’s IOreg Explorer app.

Edit: Automatic Graphics Switching should be disabled BEFORE booting into the laptop and dumping the files.

 

If anyone’s curious about the context, I’m trying to troubleshoot FairPlay 4.0 DRM issues on my Alienware Area 51m-R2 laptop’s internal EDP display (you can read my past spiel regarding this). Currently, I’m running an iMac20,2 SMBIOS due to the similar specs on macOS Ventura 13.3. The MacBookPro16,1 and MacBookPro16,4 SMBIOSes unfortunately don't attach any of my displays for some reason. I’d like to get some insight into the MacBook Pros with Navi dGPUs in order to see why an actual Apple laptop makes DRM happy on its internal display, and research other potential optimizations for my system.

 

Maybe I can make the MacBook Pro SMBIOS attach my displays somehow? (I'm not sure how the framebuffers and SMBIOS are related.)
If anyone knows what I'd need to get working graphics with a MacBook SMBIOS, please let me know and/or link me to the relevant information.

Thanks in advance

Edited April 7, 2023 by Fortitude

[theroadw]

Will not help you much, but i just tried Ventura on my Zbook G5 with WX-4170 DGPU and UHD630 IGPU and DRM is broken, I believe it is SMBios related since the WX did work for DRM in Mojave, so maybe something related to IGPU is being called.

 

Will follow your research and help in any way I can.

 

I saw you posted these on github, I'll give them a try and see if Polaris DRM works on internal screen (which worked before) and then maybe figure out the display flag you may need.

 

 

Edit2:

Damn, those 2 flags actually made it work in my case I get 100% DRM back! wohoo! out of the 4 framebuffers, only 3 get DRM at one time, this may be a clue that could help you, maybe there's a way to disable one of the unused connectors?

 

Edited April 7, 2023 by theroadw

[Fortitude]

Hi @theroadw nice to hear from you again,

 

Interestingly enough, my iGPU can play FairPlay 4.0 content perfectly. Is this the case with you iGPU? Also, did you keep your injected connector flags for macOS Ventura? Along with patching my EDP connector with some sort of a "no-HDCP" flag, I'm starting to wonder if the backlight patch could have something to do with this like Ausdauersportler said for his/her iMac?

 

The second reason why I also want this dump is to see how Navi MacBooks inject PWM properties for their internal display whether this fixes DRM or not. The person who created the Navi backlight patch noted that the Navi-based iMacs utilize DDC in order to adjust the backlight brightness instead of PWM. While the patch was made for this computer, I don't have a DDC display... I have a PWM-based laptop display, and the iMac Darwin Dumps don't give me the EDP-based configuration info that's relevant for my computer.

 

I have a very surface-level understanding, but I'm making sense of this correctly, the current patch in a nutshell appears to work by modifying the AppleMCCSController kext in order to enable the DDC-based slider, and the backlight values get chucked into the PWM function. This kind of goes against the grain, but I don't believe that it's a great permanent solution to enable this feature. While it's a very clever solution and better than anything I could ever come up with, it's the equivalent of for example getting access to many different parts of a building by changing the locks to work with your own personal keys versus copying the owner's master key and unlocking all of the building doors that way.

 

I'm almost certain that there's a way to call the PWM slider through some combination of consistent device-properties that don't need to be patched for every new OS iteration. This is because my Qosmio X775, even though it has an Nvidia dGPU, is able to control the backlight through two simple device properties along with a PNLF SSDT. I don't even use WEG on that computer! It has perfectly working DRM on all of its connections, though idk if it uses hardware or software decoding and it has a very carefully calculated NVCAP value.

[theroadw]

4 hours ago, Fortitude said:

Hi @theroadw nice to hear from you again,

 

Interestingly enough, my iGPU can play FairPlay 4.0 content perfectly.

How exactly?

In my case if I use true Hybrid mode (IGPU-LCD, DGPU-External displays) then all external screens get DRM, but LCD does not. Which means hardware decoding is taking place.

But if I flip the LCD MUX switch on boot and make the DGPU draw the LCD, then I also get DRM on LCD. So hardware only and having the IGPU present breaks DRM, also of interest you see on one of the screenshots above, System Report says Metal3 is supported by the WX-4170 which is Polaris Gen and should not be Metal3 compatible according to apple itself. Only Navi+ or the UHD630 get Metal3, which means something is getting crosswired in my hack and some properties are read from IGPU and others from DGPU in my "pseudo-hybrid" setup. If I use the disable-gpu flag above, I don't get that Metal 3 support in System Report.

4 hours ago, Fortitude said:

did you keep your injected connector flags for macOS Ventura?

Yes, same connector and flags and brightness mod.

4 hours ago, Fortitude said:

This is because my Qosmio X775, even though it has an Nvidia dGPU, is able to control the backlight through two simple device properties along with a PNLF SSDT. I don't even use WEG on that computer! It has perfectly working DRM on all of its connections, though idk if it uses hardware or software decoding and it has a very carefully calculated NVCAP value.

That would most likely be hardware decoding by nvidia card.

[Fortitude]

Hi @theroadw

For the iGPU,  beats the **** out of me why it works... I use Platform ID 0x3E9B0007 for it.

(AAPL,ig-platform-id = 07009B3E)

It's incredibly unstable though and often freezes/crashes my computer (might need to fix the patch somehow) therefore I've disabled the iGPU in my primary config.

 

Well, the only thing that I can think of doing is having you screw up your DRM for me if possible since you now have macOS Ventura:

If it doesn't crash your computer, please do me a favor and change your LVDS connector flag back to its default to see if DRM breaks.

If it breaks, the dGPU connector patching is very likely my solution that I need to implement for macOS Ventura.

If DRM doesn't break, disable your brightness patch to see if something happens.

Finally, if you really want to try something insane, you could try the iMac20,2 or a similar desktop SMBIOS to see if the internal display's DRM breaks then lol.

[theroadw]

3 hours ago, Fortitude said:

Hi @theroadw

For the iGPU,  beats the **** out of me why it works... I use Platform ID 0x3E9B0007 for it.

(AAPL,ig-platform-id = 07009B3E)

It's incredibly unstable though and often freezes/crashes my computer (might need to fix the patch somehow) therefore I've disabled the iGPU in my primary config.

I doubt IGPU is doing the DRM in this case, more likely hardware DRM via AMD DGPU but broken like mine if 2 GPUS are active.

3 hours ago, Fortitude said:

 

Well, the only thing that I can think of doing is having you screw up your DRM for me if possible since you now have macOS Ventura:

If it doesn't crash your computer, please do me a favor and change your LVDS connector flag back to its default to see if DRM breaks.

If I do that, the display doesn't do a proper hdcp handshake and I get color snow

 

3 hours ago, Fortitude said:

Finally, if you really want to try something insane, you could try the iMac20,2 or a similar desktop SMBIOS to see if the internal display's DRM breaks then lol.

The flag unfairgva = 4 basically changes the platform ID to IMACPro1,1  for DRM purposes, so it's basically the same as changing SMBIOS. I'll try to fake IMac20,2 to see if we have a similar outcome.

[theroadw]

Ok so I finally had some time to test, I changed the SMBIOS to iMac20,2 and removed the disable-gpu flag from UHD630 and to my surprise DRM works and I get both GPU's working, LCD has DRM and normal brightness control, but this is with my switched MUX config, so the WX-4170 is drawing that screen.

The only odd behaviour is that on boot the screen is drawn by IGPU (Bios default), and then after OC selection, the apple logo starts and progress bar begins to move for a second, then the MUX switches to the DGPU and the LCD goes black (as expected and normal for this setup), but the odd thing is that with this SMBIOS it remains black for about a minute and then switches over to DGPU and continues loading, I'll have to look at the boot logs to find out why or where it stalls. But my guess is that the OS want's to draw the main screen using the IGPU, but fails to find a display, times out, then switches over to DGPU and continues booting.

 

So in the end, it is interesting that maybe I can create a new unfairgva setting using iMac20,2 BoardID and still use the MacBookPro15,2 SMBIOS since that one doesn't stall on boot, but the iMac unfairgva would provide DRM while keeping both GPU's...

 

-EDIT

Never mind, it works perfectly as is, it's the weirdest thing, DRM is handled correctly by the DGPU, and the LCD muxed to the IGPU has DRM. (This never worked before) So unfairgva=4 and iMac20,2 solves that, all external displays also work nicely drawn by DGPU.

 

Last, are you 100% sure the LCD is drawn by the DGPU and not the IGPU? I still need to test not flipping the LCD MUX on boot and see if everything is the same, with the LCD not having DRM obviously.

Can you provide a copy of your ioreg?

 

If it's the DGPU, then it's just a matter of finding/decoding the connector flags and comparing them to Polaris connectors and changing your LCD connector in the ROM

 

 

Edited April 12, 2023 by theroadw

[Fortitude]

Hey @theroadw

Congratulations on your new energy-efficient portable binge watching sessions haha.

Awesome to see that the SMBIOS change made your iGPU work for you too!

Hoping that we can figure out what setting toggles this behavior and exploit it for other SMBIOSes.

 

Regarding decoding my connector flags, to be honest, the writing is on the wall…

I need to see what WEG’s auto-connector code is doing to my computer before we can proceed.

The program is obviously using my VBIOS in order to come up with the connector info. I’m just trying to work out where to add in some print statements in order to make sense of what it’s doing. Unless I’m doing something wrong, I grabbed the debug versions of weg/lilu and added -wegdbg and -liludbgall. Using Hackintool to check the system log, nothing regarding my connector information appears to be printed!

 

This is not just to fix the DRM, but also because I’ve discovered this week that WEG is the reason why I’ve been dealing with another particular issue on my computer. Heck, maybe it’s causing the DRM issue as well?

Edit: WEG isn't the culprit, it's related to PowerPlay.

 

I’ve been dealing with a crashing black screen problem that only occurs when using the computer on battery after booting up on battery power, and I just discovered that it happens when WEG chooses the framebuffer no framebuffer is specified in my device properties. When I choose the framebuffer, the problem goes away but then I can’t wake my computer up after sleep without throwing a kernel panic.

 

What the heck even is RadeonFramebuffer?

By the way, I switched to ATY,Python because it runs way smoother than ATY,Adder and whatever RadeonFramebuffer is.

(Python and Adder are the only two framebuffers that will load for my computer.)

 

In fact, I’d like to do what you said months ago and try to bypass WEG entirely to see what happens.

I just need to work out which device properties to inject in order for the framebuffer to cooperate.

(This is something that the Dortania guide should eventually include a writeup on.)

 

Regarding your stalling issue with the iMac20,2 SMBIOS, try adding agdpmod=pikera into your boot-args.

I’m 1000% sure that the dGPU is the only thing that draws the LCD because I’ve torn this laptop plenty of times down to the motherboard. There’s no mux, just a single EDP connector on the dGPU that goes to the LCD. As I said earlier, the iGPU only connects to the Thunderbolt 3 Port.

 

Finally, I’ll try to make some time this weekend to generate and upload a full dump of my system.

Edit: I'm going to try and solve the crashing black screen problem before sending a full dump.

Thanks again for trying to help me out! I’m feeling very optimistic about the future of my Hackintosh once the GPU issues are fully resolved.

Edited April 17, 2023 by Fortitude

[theroadw]

Ohh BTW https://github.com/khronokernel/DarwinDumped/tree/master/MacBookPro