WhatEverGreen Support Topic

[challou]

plz add support for ati mobility radeon 4570 1gb  it work great with high Sierra but in mojave I Kan only boot with no acceleration. I use this kext for high Sierra whith out inject ati it give mi full acceleration but in mojave when I use inject ati in clover it boot whith out acceleration but with ou inject ati in clove it stuuk in black screen.thks

AMD4600Controller.kext.zip

ATIRadeonX2000.kext.zip

ATY_Init.kext.zip

[hardcorehenry]

On 11/17/2019 at 12:46 PM, challou said:

plz add support for ati mobility radeon 4570 1gb  it work great with high Sierra but in mojave I Kan only boot with no acceleration. I use this kext for high Sierra whith out inject ati it give mi full acceleration but in mojave when I use inject ati in clover it boot whith out acceleration but with ou inject ati in clove it stuuk in black screen.thks

AMD4600Controller.kext.zip

ATIRadeonX2000.kext.zip

ATY_Init.kext.zip

install these kexts from High sierra into /System/Library/Extensions:

 

AMD4600Controller.kext

ATIRadeonX2000.kext

AMDLegacyFramebuffer.kext

AMDLegacySupport.kext

ATIRadeonX2000GLDriver.bundle

ATIRadeonX2000VADriver.bundle

ATIRadeonX2000GA.plugin

 

Not sure if you need ATY_Init.kext, I didn't (I have 4850). Rebuild kextcache repair permissions and reboot.

Now you have problem with black screen, this is expected. You have to enable acceleration patches. You can now only boot in safe mode -x. You can’t apply them from Mojave, if you have multiboot, boot into your working OSX and replace the frameworks from unzipped acceler.zip (credits to @dosdude @ASentientBot and @parrotgeek1).Boot into Mojave open terminal:

sudo chown -R 0:0 /System/Library/Frameworks

sudo chmod -R 755 /System/Library/Frameworks

sudo chown -R 0:0 /System/Library/PrivateFrameworks

sudo chmod -R 755 /System/Library/PrivateFrameworks

reboot

If you don’t have multiboot, unzip and put ACCELER folder into root. Boot into Mojave recovery, open terminal:

 

mount -uw /Volumes/Mojave

cd /Volumes/Mojave/ACCELER/Frameworks

cp -R OpenGL.framework CoreDisplay.framework /Volumes/Mojave/System/Library/Frameworks

cd /Volumes/Mojave/ACCELER/PrivateFrameworks

cp -R GPUSupport.framework /Volumes/Mojave/System/Library/PrivateFrameworks

cd /Volumes/Mojave

chown -R 0:0 /Volumes/Mojave/System/Library/Frameworks

chmod -R 755 /Volumes/Mojave/System/Library/Frameworks

chown -R 0:0 /Volumes/Mojave/System/Library/PrivateFrameworks

chmod -R 755 /Volumes/Mojave/System/Library/PrivateFrameworks

reboot

Mulitboot method 100% works, recovery method not tested, but you may also try boot with -s boot arg and do analogically.

Edited November 19, 2019 by hardcorehenry

[challou]

7 hours ago, hardcorehenry said:

install these kexts from High sierra into /System/Library/Extensions:

 

AMD4600Controller.kext

ATIRadeonX2000.kext

AMDLegacyFramebuffer.kext

AMDLegacySupport.kext

ATIRadeonX2000GLDriver.bundle

ATIRadeonX2000VADriver.bundle

ATIRadeonX2000GA.plugin

 

Not sure if you need ATY_Init.kext, I didn't (I have 4850). Rebuild kextcache repair permissions and reboot.

Now you have problem with black screen, this is expected. You have to enable acceleration patches. You can now only boot in safe mode -x. You can’t apply them from Mojave, if you have multiboot, boot into your working OSX and replace the frameworks from unzipped acceler.zip (credits to @dosdude @ASentientBot and @parrotgeek1).Boot into Mojave open terminal:

sudo chown -R 0:0 /System/Library/Frameworks

sudo chmod -R 755 /System/Library/Frameworks

sudo chown -R 0:0 /System/Library/PrivateFrameworks

sudo chmod -R 755 /System/Library/PrivateFrameworks

reboot

If you don’t have multiboot, unzip and put ACCELER folder into root. Boot into Mojave recovery, open terminal:

 

mount -uw /Volumes/Mojave

cd /Volumes/Mojave/ACCELER/Frameworks

cp -R OpenGL.framework CoreDisplay.framework /Volumes/Mojave/System/Library/Frameworks

cd /Volumes/Mojave/ACCELER/PrivateFrameworks

cp -R GPUSupport.framework /Volumes/Mojave/System/Library/PrivateFrameworks

cd /Volumes/Mojave

chown -R 0:0 /Volumes/Mojave/System/Library/Frameworks

chmod -R 755 /Volumes/Mojave/System/Library/Frameworks

chown -R 0:0 /Volumes/Mojave/System/Library/PrivateFrameworks

chmod -R 755 /Volumes/Mojave/System/Library/PrivateFrameworks

reboot

Mulitboot method 100% works, recovery method not tested, but you may also try boot with -s boot arg and do analogically.

thank you it work now

[Darkrai1012]

On 11/14/2019 at 1:40 AM, jinbingmao said:

10.15.2 Beta(19C39d)

support H264,does not support HEVC HW

iMac Pro (2017)

AMD Radeon RX 560 4 GB

I am facing similar issue with CoffeLake UHD630 I used to have HEVC on mojave and first public catalina release. I no longer have HEVC using the latest public catalina release.

[nean]

On 11/14/2019 at 8:52 AM, nean said:

 

@TheBloke

yes its the same mobo, v2 and bios on FH, that is kind, and I'd be more to than happy to test your bundle, we can exchange if you're interested in my approach.

thanks for the hint about the cpu, switching CPU could be an option, Xeon X5670 sounds a bit like it is a server cpu?

however, I already invested in vega to get to mojave, and if it comes to HW I'm almost thinking about switching the mobo/cpu/ram to a X99 or X299 architecture.

this particular X58 mobo was always a bit of a pain especially as the chipsets (other than the ICH9) was not really performing at all (not even under windows)

but other than that I have to admit it was/is rocket solid.

Lets find out what we can still get out of this grandfather hackintosh ;-)

 

would any of the 1366 cpus work? eg.: https://www.servershop24.de/en/components/cpu-heat-sink/intel/socket-1366/

 

thanks

 

 

@TheBloke and all other X58 & Vega 56/64 GPU owners suffering from this issue ->

 

I got it to work with:

• Macpro5,1 SMBIOS, means CPU speedstep of i7 950 (nehalem) working
• no black screen
• GPU hw acceleration enabled

 

It's a strange combination which leads me think that this is more WEG related than I originally thought.

here is what I came up with:

 

Boot arguments:

shikigva=96
shiki-id=Mac-7BA5B2D9E42DDD94
agdpmod=pikera

Essential switches are:

• agdpmod=pikera  -> (or vit9696 ) -> Blackscreen prevention: step 1 of 3 
• shikigva=96 shiki-id=Mac-7BA5B2D9E42DDD94   -> enabling HW acceleration by mimic iMacPro1,1 BoardID

 

Graphics:

• FB Name: Kamarang -> the working main displayport will be the 2nd one (not the outer one) -> (Blackscreen prevention: set  2 of 3)  

 

Kernel and Kext Patches: -> (Blackscreen prevention: set  3 of 3) 

• Name: "com.apple.driver.AppleGraphicsDevicePolicy", Find: "BA050000 00" ,Replace: "BA000000 00", Comment: "Prevent AGDP from loading"

 

I really hope this helps to demystify this particular issue, at least this it should be possible to use those "Workarounds" to get at least the best compromise from both SMBIOS profiles

 

However, it would be great if this can be realised eg. with 1 WEG switch, unless X58 support will be dropped?

There are 3 issues to be solved:

1. black screen dp port **
2. GPU HW acceleration (eg HW encode) **
3. CPU speedstep

** can be solved by using SMBIOS iMacPro1,1 but then x58 will not have CPU speedstep and end up with fixed x12 multiplier <2GHz and low CPU performance !!

 

 

 

 

thanks,

nean

 

 

Edited November 24, 2019 by nean

[123456789323]

Kext-dev-mode=1 is obsolute and has no function if you run a macOS Version newer then 10.10. - so absolutely useless. 

 

keepsyms=1 tells the OS to print the symbols on a kernel panic. That can give some more helpful insight as to what's causing the panic itself. It only makes sense if you use it with debug=0x100 in combination which prevents the reboot on a kernel panic.  - also useless if you don't have a kernel panic which you want to debug. 

 

You only have to use agdpmod=pikera which is by the way also absolute if you use an WEG version older then WEG 1.3.4

 

The blackscreen patches mentioned further don't do anything on 10.15 and can also be removed. 

 

But even if you would run 10.14.6 it's useless since you use WEG or the patches but not bought at one time. 

 

SpeedStep: Just enable PluginType=1 in the config.plist or create an ssdt.aml with ssdtprgen : https://github.com/Piker-Alpha/ssdtPRGen.sh

Edited November 23, 2019 by DSM2

[nean]

On 11/23/2019 at 3:35 PM, DSM2 said:

Kext-dev-mode=1 is obsolute and has no function if you run a macOS Version newer then 10.10. - so absolutely useless. 

  

keepsyms=1 tells the OS to print the symbols on a kernel panic. That can give some more helpful insight as to what's causing the panic itself. It only makes sense if you use it with debug=0x100 in combination which prevents the reboot on a kernel panic.  - also useless if you don't have a kernel panic which you want to debug. 

 

You only have to use agdpmod=pikera which is by the way also absolute if you use an WEG version older then WEG 1.3.4

 

The blackscreen patches mentioned further don't do anything on 10.15 and can also be removed. 

 

But even if you would run 10.14.6 it's useless since you use WEG or the patches but not bought at one time. 

 

SpeedStep: Just enable PluginType=1 in the config.plist or create an ssdt.aml with ssdtprgen : https://github.com/Piker-Alpha/ssdtPRGen.sh

 

 

@DSM2 have you had hands on such a specific system ? -> this is about X56, nehalem CPU, vega 56 and mojave 10.14.6

 

regarding boot switches, yes not all are relevant, I highlighted the important ones, the other ones are not required to this blackscreen&cpu speedstep topic !

agdpmod=pikera or vit9696 -> this is essential, without this, I get black screen, I'm on WEG 1.3.4

 

The black screen patch is indeed obsolete, but the other one is needed.

 

regarding ssdtprgen, nope, you are not aware that the i7-950 CPU's (nehalem) are not supported by this script, ssdtprgen is focused on newer cpu models, however, I considered this path as well, and as i7-950 is not supported by this script right away, I patched this script ( and ~/Library/ssdtPRGen/Data/User\ Defined.cfg) to be capable of i7-950, got it to run, and created SSD, this did not work (also considered to drop OEM and specific tables) -> I had a closer look at this and did debugging, turned out, thats not required at all and made things even worse, clover detects it already properly even on overclocking.

 

 

 

However, I have a working setup now (on smbios macpro5,1), but:

If someone came up with a proofed configuration for GA-X58A-UDR3 fh & i7-950 & Sapphire nitro+ vega 56 & smbios iMacPro1,1 and a working CPU speedstepping and without dirty hacks like sleep and awake -> a box of craft beer will be yours ;-)

 

 

Edited November 24, 2019 by nean

[CMMChris]

Looks like shikigva=32 + shiki-id=<board-id> boot args don't work anymore. Did something change about the necessary boot-args?

[nean]

46 minutes ago, CMMChris said:

Looks like shikigva=32 + shiki-id=<board-id> boot args don't work anymore. Did something change about the necessary boot-args?

 

What impact does this have?

I used to test this with VideoProc to see if HW acceleration is working, if board-id replacement wouldn't work, I wouldn't have HW acceleration, but thats just how this affect my system, it might have completely different impact for your setup/case.

 

To which version are you referring too? 1.3.5?

looking at the github repository it seems there are some changes around shiki coming up with 1.3.5, but doesn't look like shikigva=<id> shiki-id=<board-id> is affected

 

https://github.com/acidanthera/WhateverGreen/blob/055773e6094f7e1d40c4e07a690a7eb7b55f4d45/Changelog.md

WhateverGreen Changelog
v1.3.5
Dropped legacy boot arguments (-shikigva, -shikifps)
Fixed handling agdpmod GPU property (in IGPUs and in conjunction with boot-arg)
Added -wegtree boot argument to force device renaming
Fixed FairPlay DRM playback patches on 10.15
Added shikigva and shiki-id aliases in IORegistry
Added applbkl aliases to IORegistry (data, 32-bit)

 

vit9696 was active over the last days:

https://github.com/acidanthera/WhateverGreen/commits/master/WhateverGreen/kern_shiki.hpp

 

And reading carefully the comments of the PR , -shikigva and shikigva=N are two different args, which will be definitely misinterpreted.  

https://github.com/acidanthera/WhateverGreen/commit/9f44c130fe51a8ff7e4874769c6381e42d48e55f#comments

 

[CMMChris]

I am personally not affected since I run my Hackintosh on iMacPro1,1. But I have heard of numerous people where these boot-args have no effect anymore on Catalina and different Whatevergreen Versions up until the recent release.

 

They want to use Sidecar which on a Hackintosh is only possible with Quick Sync enabled SMBIOSes. On iMacPro1,1 the T2 is used for Sidecar and thus doesn't work on a Hackintosh.

 

By setting up Quick Sync and using Shiki Board ID spoof (iMacPro1,1 Board-ID) for AppleGVA it should be possible to use both AMD Encoding / Decoding and Sidecar at the same time. However, for those guys I am supporting those boot-args don't show any effect. If IGPU is disabled, VideoProc gives red light which shouldn't happen if they'd work. Also Safari DRM (Netflix) doesn't work but it should work if the boot-args would show any effect.

 

Boot-args already stopped working before the latest changes, so I assume something in Catalina is responsible for that.

Regarding the latest release: How are we supposed to use the board-id spoof without the shikigva boot-arg?

Edited November 24, 2019 by CMMChris

[iCanaro]

WhateverGreen Changelog

v1.3.5

• Added Lilu 1.4.0 support, which is now the minimum supported version
• Dropped legacy boot arguments (-shikigva, -shikifps)
• Fixed handling agdpmod GPU property (in IGPUs and in conjunction with boot-arg)
• Added -wegtree boot argument to force device renaming
• Fixed FairPlay DRM playback patches on 10.15
• Added shikigva and shiki-id aliases in IORegistry
• Added applbkl aliases to IORegistry (data, 32-bit)
• Added applbkl-name and applbkl-data IORegistry data keys to provide custom backlight data
• Fixed applying CoreFP patches on Apple firmware, when they are not needed
• Added shikigva=16 (repurposed) property to use AMD hardware DRM decoder in select apps
• Added shikigva=128 (repurposed) property to use hardware decoder for FairPlay 1.0 (can be used as shikigva=144)
• Do not disable DRM patches when shikigva is used even on Apple hardware for MacPro5,1 support

[nean]

9 minutes ago, CMMChris said:

I am personally not affected since I run my Hackintosh on iMacPro1,1. But I have heard of numerous people where these boot-args have no effect anymore on Catalina and different Whatevergreen Versions up until the recent release.

 

They want to use Sidecar which on a Hackintosh is only possible with Quick Sync enabled SMBIOSes. On iMacPro1,1 the T2 is used for Sidecar and thus doesn't work on a Hackintosh.

 

By setting up Quick Sync and using Shiki Board ID spoof (iMacPro1,1 Board-ID) for AppleGVA it should be possible to use both AMD Encoding / Decoding and Sidecar at the same time. However, for those guys I am supporting those boot-args don't show any effect. If IGPU is disabled, VideoProc gives red light which shouldn't happen if they'd work. Also Safari DRM (Netflix) doesn't work but it should work if the boot-args would show any effect.

 

Boot-args already stopped working before the latest changes, so I assume something in Catalina is responsible for that.

Regarding the latest release: How are we supposed to use the board-id spoof without the shikigva boot-arg?

 

I understand.

 

Looking at the commits it looks like there are some updates coming in regards to DRM, WHDRM and the likes.

https://github.com/acidanthera/WhateverGreen/commits/master

 

Let's hope this will solve some problems, but if there are some particular issues that are not yet considered I'd recommend to debug this and create an issue at the weg github including as specific and accurate technical description as possible, so that the guys are able to patch it or find a way around it.

 

 

Regarding T2 chip, in case someone do not find a creative way around it, and apple is involving the T2 even on many if not all operation it will cause an impact on the hackintosh scene. Lois Rossman also has some strong opinion on the T2 topic and the hardware side of things when it comes to right to repair.

My own opinion on that is, that Apple is going to move to ARM within one of the next upcoming iterations. Dropping 32bit in Catalina is one of the necessary consequence, with more to come,...

 

12 minutes ago, iCanaro said:

WhateverGreen Changelog

v1.3.5

• Added Lilu 1.4.0 support, which is now the minimum supported version
• Dropped legacy boot arguments (-shikigva, -shikifps)
• Fixed handling agdpmod GPU property (in IGPUs and in conjunction with boot-arg)
• Added -wegtree boot argument to force device renaming
• Fixed FairPlay DRM playback patches on 10.15
• Added shikigva and shiki-id aliases in IORegistry
• Added applbkl aliases to IORegistry (data, 32-bit)
• Added applbkl-name and applbkl-data IORegistry data keys to provide custom backlight data
• Fixed applying CoreFP patches on Apple firmware, when they are not needed
• Added shikigva=16 (repurposed) property to use AMD hardware DRM decoder in select apps
• Added shikigva=128 (repurposed) property to use hardware decoder for FairPlay 1.0 (can be used as shikigva=144)
• Do not disable DRM patches when shikigva is used even on Apple hardware for MacPro5,1 support

 

pls. note:  -shikigva and shikigva=N are two completely different args, which will be definitely misinterpreted.  

 

-shikigva -> is going to be dropped

-shikigva=N -> is not dropped

[eSaF]

For some strange reason I'm unable to build latest WhateverGreen v1.35, previous versions were no problem. Would very much appreciate an upload by some kind person to preserve the few strands of hair left on my head - Thanks.

[AkimoA]

Quote

Regarding the latest release: How are we supposed to use the board-id spoof without the shikigva boot-arg?

 

`shikigva=160 shiki-id=Mac-7BA5B2D9E42DDD94`

 

 

 

[CMMChris]

Thanks, I forwarded this to some guys and will report if it works for them.

[AkimoA]

Well only if you or they compiled the not yet released Lilu 1.4.0. and WEG 1.3.5 offcourse.

[CMMChris]

@AkimoA Got feedback from a couple cMP users that it still doesn't work. Still waiting for feedback of Hackintosh users.

[AkimoA]

@CMMChris

 

Again are they using the latest Version Lilu 1.4.0. and WEG 1.3.5 ?  

 

U havent answered or reacted  to my above statement on the same topic maybe u missed it  , no point of testing  with old Lilu 1.3.9 and WEG 1.3.4 since the changes arent implemented yet .

[CMMChris]

Yes of course. It doesn't work. See here: https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/page-15?post=28013675#post-28013675

 

Edit: just got feedback from a Hackintosh user who tried shikigva=160 and shiki-id=Mac-7BA5B2D9E42DDD94 with latest Lilu and Whatevergreen builds on Clover with iMac18,3 SMBIOS and Catalina. Same result as reported by the cMP users. Boot-args don't show any effect, AMD GPU not used for H.264 / H.265, DRM not working.

Edited November 26, 2019 by CMMChris

[Tecnicaso Rico]

On 11/26/2019 at 3:17 PM, CMMChris said:

Yes of course. It doesn't work. See here: https://forums.macrumors.com/threads/opencore-on-the-mac-pro.2207814/page-15?post=28013675#post-28013675

 

Edit: just got feedback from a Hackintosh user who tried shikigva=160 and shiki-id=Mac-7BA5B2D9E42DDD94 with latest Lilu and WhateverGreen builds on Clover with iMac18,3 SMBIOS and Catalina. Same result as reported by the cMP users. Boot-args don't show any effect, AMD GPU not used for H.264 / H.265, DRM not working.

It does work. I'm using iMac 17,1 Platform ID: 19120001 (headless mode) with HD530/Vega 64.

Also the boot arguments that I used and, works in my case are:

shikigva=160

shiki-id=shiki-id=Mac-7BA5B2D9E42DDD94

 

I follow the FAQ.shiki.en.md document located at the WhateverGreen Github page.

 

I'm still testing and trying to find a boot argument or combination of boot arguments to make it work without spoofing the iMacPro 1,1 board-id (Mac=7BA5B2D9E42DDD94). If iMac 17,1 is present in the Info.plist of AppleGVA, then it's suppose to work with a boot argument and without spoofing iMacPro1,1. Spoofing iMacPro 1,1 is done to force the use of the dedicated graphics instead of the IGPU. But there are boot arguments to achieve the same, and if the SMBIOS (iMac 17,1) it's supported, then it's suppose to work without the need of spoofing.

That's why I need to keep testing... But right now it's working perfectly fine with the combination of the boot arguments: shikigva=160 shiki-id=Mac-7BA5B2D9E42DDD94

Something I notice the first time I tried with the right argument it didn't work. But then I reset warnings, cache and clear play history in the TV+ settings, and after closing and opening the app again then it work.

There is also some terminal commands useful for resetting the DRM configuration after making a mess with all the testing... Just follow carefully the Shiki/WhateverGreen FAQ and remember to install the latest kexts (if necessary compile the kexts because sometimes the latest ones are not available for download yet).

Edited November 28, 2019 by Tecnicaso Rico

[telepati]

 

What about Netflix on Safari? TV+ already working with current Lilu 1.3.9. and WEG 1.3.4 shikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94.

Edited November 28, 2019 by telepati

[CMMChris]

@Tecnicaso Rico Thanks for your input but I know what I am doing and there clearly is something wrong. In the past (pre catalina) there have been no issues spoofing the board-id for AppleGVA / AppleVPA. Now it definitely doesn't work even with the latest Lilu and WEG builds + the new boot args.

As mentioned earlier, I personally am not affected by it since I run my machine on iMacPro1,1 natively and I don't need Sidecar to work. However I am supporting the machines of a couple guys that have been set-up using different SMBIOSes which have been (successfully!) using the board-id spoof in the past and it just stopped working at some point. Same thing applies to some cMP users I know of (I linked a discussion on MacRumors a couple posts above). The new boot-args and Lilu / WEG build also don't fix anything.

Sure, none of them tested it with iMac17,1 but with quiet a couple different SMBIOSes and it doesn't work for any of them. I also don't see why it should specifically work for iMac17,1 and none of the other SMBIOSes. Makes no sense to me.

 

Could you please provide some kind of proof for your words and tell me how you verified that your board-id spoof is working?

Edited November 27, 2019 by CMMChris

[AkimoA]

And one of the guys testing on macrumors didnt inject them as recommended  in  the Wiki with a bootloader but in /L/E ,since it needs to be loaded in an early state of  boot, that could also be the cause of failure .

 

 

[Tecnicaso Rico]

Apple TV+ only works when I use the boot argument to spoof iMacPro 1,1, this is how I know it works. Also, there are tools to verify that the VDA decoder is fully supported. Following the FAQ of Shiki/WhateverGreen document is important because different SMBIOS's/hardware configurations requires different boot arguments. I have the IGPU (HD530) enable in the UEFI/BIOS settings with video priority set to DGPU (Vega 64). I'm using iMac 17,1 in headless mode ( Platform-ID: 19000001). If your friends didn't had issues before spoofing iMacPro 1,1 then they can try resetting the DRM configuration.

Another issue they could have is a corrupt user database which causes sync problems with some of the Apple Online Services (Music, TV and Podcasts). This could happen after upgrading from Mojave to Catalina. Some of the symptoms are errors when trying to download content from online services like Apple TV+

If this is the case I recommend trying this:

 

1. Sign out of iCloud on your Mac
2. Open Terminal & use the following commands:

sudo -v
Enter Your Mac Password
killall -9 accountsd com.apple.iCloudHelper
rm -rf ~/Library/Accounts
killall -9 accountsd com.apple.iCloudHelper

3. Restart your Mac
4. Open Music App & sign in to your account (You should sign in to your account)
5. Check your TV & Podcast Apps (You should sign in to your account)
6. Open System Preferences & go to iCloud (You should sign in to your account) just activate iCloud Drive

 

In the FAQ of Shiki/WhateverGreen document there is also some terminal commands you can try to reset the DRM configuration (can get mess when testing different configs):

defaults delete com.apple.coremedia 
defaults delete com.apple.AppleGVA 
sudo rm -rf /Users/Shared/SC\ Info 
sudo defaults delete com.apple.coremedia 
sudo defaults delete com.apple.AppleGVA

Good luck, I hope this can give you some ideas and can help you.

 

[CMMChris]

No DRM issues. Non working spoof clearly is the issue. Just tried it on my machine on iMac18,3. It doesn't work, period. And just saying: I know about everything you wrote. I am not a noob anymore.

 

For my test I kept the IGPU disabled so I can simply check by VideoProc if the AMD is encoding / decoding. Red light. Also no Netflix playback. IGPU turned on and boom, H.264 / H.265 green but of course no DRM due to the IGPU decoding. Switched IGPU back off again and edited AppleGVA's info.plist manually - boom! H.264 / H.265 green, DRM working.

 

Of 16 guys (excluding me) where it clearly isn't working, you are the first one I see who claims it does. Interesting and strange. Wonder what the issue is.

Edited November 27, 2019 by CMMChris