HDCP Compliant Laptop Display Survey

[Fortitude]

Greetings, and happy New Years everyone!

I'm starting off this year strong with my Alienware Area 51m-R2 laptop which is pretty much a perfect Hackintosh at this point. However, I'm having a hard time binge watching some AppleTV+ on my internal display. The hilarious thing is that it plays on my external monitor perfectly, but not internally at all!

 

 

It seems that my internal display isn’t HDCP compliant and sometimes gives me this error message when both displays are plugged in.

 

 

Therefore, I strongly suspect that changing out the panel for a compatible one could potentially solve my problems.

(Just like how everything in HackintoshLand is a pain in the *** regarding compatible hardware.)

 

I haven’t found any mention on the internet of people doing this to their laptops to fix hardware DRM (I only speak English though), and I’m trying to determine what could be the best compatible panel for my computer.

 

Does anyone here on this forum have AppleTV+ working on their Hackintosh laptop’s internal monitor running macOS 11 or higher? If so, what brand/model is your internal display?

Edited January 3, 2023 by Fortitude

[aben]

DRM content does indeed require an HDCP-compliant display, and If the panel is ,,actually'' non-compliant, then shouldn't Windows be throwing that error as well when attempting to play DRM content?

As far as I know: Playback of DRM content on iGPU-only hacks (especially mobile/laptops) is not natively supported; this is due to a hardware-level limitation with Apple's GuC firmware not being fully compatible with iGPUs shipped by vendors that are not Apple (HDCP/PAVP are non-provisional/locked).

Apple's GuC firmware can be successfully loaded (with boot-arg: igfxfw=2) on systems with 14nm chipsets (and on some laptops with 9th generation mobile chipsets), and although it does help with drastically improving iPGU performance/power-management, DRM support is still known to be broken (stuttering and lags during playback) unless there is a supported AMD dGPU to handle the DRM decoder (which is not possible with laptops as macOS has zero support for mobile dGPUs).

[theroadw]

If your laptop is using the RX 5700M dgpu (likely as you have drm on external screens) you will need to find out if the lcd is drawn by the igpu or the dgpu and/or if it is muxed and if so can you switch the mux in bios/acpi.

If the lcd is drawn by the dgpu and you still have hdcp issues, it is probably due to a display flag that whatevergreen doesn't set right, you may have to inject it manually, but this is an if within an if scenario, so need to find out the other ones before this one.

[Fortitude]

Hey everyone,

 

It’s been a while, and yes, the internal display is only drawn by the dGPU.

(The iGPU is only connected to my laptop’s thunderbolt port.)

Over the past few weeks, I’ve learned enough now about this problem to possibly prove @theroadw right.

I’ve discovered that this HDCP problem is specifically linked to the EDP connection type which is only used by my internal display.

Modifying my vBIOS to change this connection type from EDP to DP fixes DRM, but breaks sleep/wake.

(I injected the edited vBIOS through the ATY,bin_image device property.)

 

I’d like to keep the connection type EDP because an iMac20,2 (the SMBIOS that I’m using) also uses EDP for its internal display.

Is there a way to use WEG or another method in order to make the darn EDP get along with DRM?

 

And before you ask, yes, I’ve tried the iMacPro1,1 SMBIOS without any luck.

The MacPro7,1 SMBIOS won’t even attach to my internal display.

 

In order to illustrate this problem further, in this video, I've flipped the EDP and DP connections within my vBIOS.

Now the external monitor isn't HDCP compliant.

 

 

Edited April 2, 2023 by Fortitude

[theroadw]

Possible things to try, in my case with the Zbook G5 and WX-4170 dgpu, I found that to get the lcd to work correctly I had to patch the connectors to what the palena framebuffer showed, especially the 3905 and 08 in green, as they must be some sort of an internal display no hdcp needed flag.
 

 

Note the 3905 flag for LVDS connector (original was 0109) and also the 08 added after the connector number.

Maybe there's something similar in a framebuffer that would be native to your card and you can insert those values in your OC.devices config.

 

 

Another thing I can think of is changing your SMBIOS as different Macs have different display arrangements and therefore some may allow your particular configuration?

[Fortitude]

Hi @theroadw

 

Thank you for replying so quickly after all of this time!

I like your suggestion and want to try it, but I know absolutely nothing about how to extract framebuffer/connector information for AMD dGPUs.

 

How would I go about this on macOS Ventura?

And/or is there a guide/resource that you can provide me regarding this?

 

My configuration uses the Adder framebuffer within AMDRadeonX6000Framebuffer.kext

The iMac20,2 that I’m emulating uses the Ikaheka framebuffer, but if I try to boot with this framebuffer I get a kernel panic for some reason.

 

On another note, I see that you use three device properties relating to the backlight.

I’ve never heard of them, and am curious where/how you got them?

Edited April 2, 2023 by Fortitude

[theroadw]

Did you try this?

 

I would also not use SMBIOS from imac if your machine is a laptop, why not use a macbook pro SMBIOS? you have igpu for quicksync and jpeg preview, etc... and the dgpu for everything else, like a real MBP.

That in itself may fix your hdcp issue.

 

I don't remember where I got the Palena connector information and the WEG debug version gave me my detected connectors, it may very likely be different in Navi cards. I seem to remember a conversation with Ausdauersportler about connector injection having changed from polaris, so maybe rom is the only way to change that info. Could still work if you find the right flag though.

The backlight stuff was working on my machine but the range was not correct, so with those 3 patches I change the backlight config and range to a better matched one, I believe I got that from going over the source code of WEG kext. IGPU injects a couple of different backlight defaults depending on your IGPU, so I used the same idea for my dgpu and it worked.

 

This last 1% to getting your hack perfect is the trickiest but also where you end up learning the most, keep it up!

edit- it may be a good idea to analyze the WEG code related to applbkl=3 to find out what it does for Radeon RX 5000 series and see if it helps in your case.

Edited April 2, 2023 by theroadw

[Fortitude]

The MacBook Pro SMBIOSes for the most part can't attach any ports from the dGPU, or attach them and miss the EDP connection entirely.

My laptop has an Intel Core i9-10900K, a desktop CPU.

The specs of this machine are nearly identical to an iMac20,2, and this SMBIOS appears to work the best.

 

Regarding the backlight patch, I’m literally working with the person currently who made that patch (it was made for this laptop), but I don’t know them personally so it might take some time to get a response. I’ve got C++ experience (none with assembly), I’m confused though on where to start reading kext code…

(Is there a main.cpp main() function? I’ve never developed kernel extensions before. Looks like init and deinit are your constructors and deconstructors?)

 

While I try to figure out how to dump the framebuffers/connectors, the best that I can do for now is give you my vBIOS and the first 64K of the iMac20,2 vBIOS taken from the ATY,bin_image device property of a Darwin Dump. Using atomdis, I can dump the connector info for the Hackintosh, and for an iMac20,2.

Maybe there's something that I can try with this information? I'm not sure how to use it.

 

a51m.orig.rom imacvbios.rom

Edited April 2, 2023 by Fortitude