Contribute
Register

An iDiot's Guide To Lilu and its Plug-ins

I am using Radeon VII ---> DP to DP cable ---> Display ---> Active DP to VGA adapter ---> Extra monitor

This setup works fine if I have only 4 displays connected, in this instance, using the 3 DP ports of the VII (including the Extra monitor above)

If I plug a 5th display in to the HDMI, that 5th display will not work until I unplug the Extra monitor described in the setup above. This was not an issue with my RX 580.


@narbatucker,

Hummmm thats a pretty unique configuration. I thought DP daisy chaining was a Windows only feature ?
When i tried it a few years ago i could never get it to work. When i searched on the Apple forums many genuine Mac owners where also reporting that the feature is not supported in MacSO.

I think the issue is that MacOS does not support multiplexing virtual displays, in your case you have four physical frame buffers for each of the four ports on the GPU. In order for you to use a 5th monitor via daisy chaining would require MacOS to create a virtual 5th frame buffer and then multiplex it down the DP line that is daisy chained.

My understanding is that multiplexing virtual frame buffers is a Microsoft/Windows technology and not supported by MacOS. However, thing's may have chained since i looked into it ... might be worth posting on the Mac forums and asking if DP daisy chaining is now officially supported by MacOS.

I think adding a second GPU such as RX 580 would be the way to go .... (if you really need that many monitors) .

Good Luck with it
Cheers
Jay
 
Last edited:
Hummmm thats a pretty unique configuration. I thought DP daisy chaining was a Windows only feature ?
When i tried it a few years ago i could never get it to work. When i searched on the Apple forums many genuine Mac owners where also reporting that the feature is not supported in MacSO.
I used it previously with my 580, it seems to be a relatively new thing and only seemed to work with AMD cards. Absolutely 0 support for NVidia or Intel GPUs.

I think the issue is that MacOS does not support multiplexing virtual displays, in your case you have four physical frame buffers for each of the four ports on the GPU. In order for you to use a 5th monitor via daisy chaining would require MacOS to create a virtual frame buffer and then multiplex it down the DP line that is daisy chained.

Interesting, this would explain why it does not work. Thank you for that explanation.

I'll not waste money on a DP hub either then, as I now know it absolutely will not work.

Thank you and @pastrychef for your help with this.
 
Also, quick note: in WEG 1.3.5 + Lilu 1.4.0, shikigva flag 16 has been repurposed (as above github link shows). If you have it on in conjunction with flag 8 or 32 on a system with only Intel iGPU, you will KP with the error:
Hardware DRM decoder cannot be used with custom board (= 32) or whitelist ( = 8)
It looks like there is no hope for iGPU DRM, at least not for Haswell using this method. At minimum OP should be modified so that people aren't told to try shikigva=57 or 60, which are guaranteed KPs now (this has been happening to me for the last hour and a half, did not quite understand the log until I read the linked part of the header in the source.)
 
vit9696 says that iGPU DRM is not something they're gonna attempt to fix or work on, and will require flashing and provisioning Apple's ME.

Any idea what this entails? If it's what it sounds like then it's probably more trouble than it's worth but I wanted to make sure.


@bilditup1,

Yes unfortunately getting DRM to work on MacOS on Haswell and later systems that only have a IGPU is now next to impossible due to changes that Apple implemented late last year. Your not the first person to ask me this question so over the weekend I updated the DRM section of the guide with the following info on this subject :-

All Intel PC chipsets from 2008 onwards have a ME (Management Engine) which can be thought of as a master controller for the CPU. One of the many things the ME can do is add and update extensions to the CPU's micro code.

Intel push out ME updates to PC manufacturers when there is a need to address vulnerabilities or to implement optimisations as well as updating the ME itself. PC Motherboard manufacturers support updating the Intel ME by including it in a BIOS/UEFI update or via a separate BIOS/UEFI utility.

The BIOS/UEFI then applies the ME update when the PC is booting.

Unfortunately Apple customise the Intel ME Updates on Macs with extensions that are used for DRM authentication.

Theoretically one could patch a PC's ME to include Apple's ME customisations and thus enable native MacOS DRM authentication on IGPU only systems. However such a process would be complex for most users and runs a high risk of bricking your motherboard if you muck up the ME patching code.

It has been suggested that it may be possible for a boot loader to perform such a process .... the official response from the developers of the Open Core and Clover boot loaders is that they currently have no plans to investigate this approach, possibly to avoid DRM licensing infringement and/or investigation by Apples legal department.

DRM is a touchy subject and modification of DRM firmware tends to be prosecuted swiftly and harshly.


in WEG 1.3.5 + Lilu 1.4.0, shikigva flag 16 has been repurposed


Yes i've been following the latest DRM updates in the current WhatEverGreen development builds for a while now and looks like a promising solution for getting DRM working on Hackintosh systems that have AMD GPU.

Prior to these new WEG updates the best way to get DRM working on Coffee Lake CPU with a AMD GPU installed is to use the iMacPro1,1 SMBIOS. As the iMac Pro uses a Xeon CPU that has no IGPU it uses the AMD GPU for DRM authentication and decode and a T2 chip for IQS equivalent encode/decode.

The WEG development team have analysed exactly what using the iMacPro1,1 SMBIOS makes to DRM in MacOS and have implemented those changes as a series of new dynamic patches that can be triggered with the "shikigva=16" boot flag. The process patches MacOS and certain Apple Apps effectively forcing them to use the AMD GPU for DRM authentication and decode.

The Apps that are patched in the current development version of WEG are :-
  • iTunes
  • QuickTime Player
  • Apple TV
  • Apple Music
  • MacOS Frameworks used for Web Content and general Video Playback
You can see the new code changes and patches by examining the latest commit's to WhatEverGreen's source code :-


At minimum OP should be modified so that people aren't told to try shikigva=57 or 60.


For now I have removed the info on the legacy use of the Shiki Module in WhatEverGreen from the guide.

I will update the DRM section of the guide with the new Shiki options once the new DRM fixes are fully tested and WEG 1.3.5 is officially released which at the moment is scheduled for the first or second week in December.

Cheers
Jay
 
Last edited:
Unfortunately Apple being Apple customise the Intel ME updates with some low level IGPU micro code that is used for DRM authentication and decode on certain Apple Mac systems (Haswell and later).

Theoretically it would be possible to take a PC's latest Intel ME update and patch it to include Apple's ME CPU/IGPU customisations and then flash it to the BIOS/UEFI which could (theoretically) result in enabling native MacOS DRM on IGPU only systems. However such a process would be complex and run a high risk of bricking your motherboard if you muck up the ME patching code, to my knowledge this approach has only be discussed on one of the non english speaking forums.

This is basically what I understood was happening--thanks for confirming! It may be something to bring up at bios-mods or win-raid, but they, too, may not want to touch this. Any case, at least for reference--win-raid has a bunch of ME-related resources that are kept continuously up-to-date here. I have more questions, but I think it would be more proper to create a separate thread now.

For now I have removed the info on the legacy use of the Shiki Module in WhatEverGreen from the guide.

I will update the DRM section of the guide with the new Shiki options once the new DRM fixes are fully tested and WEG 1.3.5 is officially released which at the moment is scheduled for the first or second week in December.

Cheers
Jay

Aight brilliant!
 
I'm having a trouble with this step "IGPU Device Properties" no match between "Selected Framebuffer Info" and "Current Framebuffer Info" result "???" (check pic. attached), following the steps of the guide, but I don't know what I'm doing wrong, maybe is this the problem of my "black screen" right?

Thanks in advance!
 

Attachments

  • error2.png
    error2.png
    70.8 KB · Views: 79
I'm having a trouble with this step "IGPU Device Properties" no match between "Selected Framebuffer Info" and "Current Framebuffer Info" result "???" (check pic. attached), following the steps of the guide, but I don't know what I'm doing wrong


@Maesito,

The only time i've ever seen Hackintool not report the current FB info like in your screen shot is when Lilu + WhatEverGreen is either not installed correctly or not loading correctly which can some times be cause by not removing all IGPU injections, FakeID's & settings from your config.plist as it causes a conflict with WEG.

As per the guide make sure to remove all of them, then try Lilu + WEG with no Device Properties set which should trigger WEG's auto detect/auto configure ... if that fails then configure IGPU by means of device properties.

Cheers
Jay
 
Thanks @jaymonkey I will check one more time then.

- Last release version of Lilu + WhateverGreen Installed with Hackintool to Library > Extensions.
- Lilu + WhateverGreen included in "Clover > kexts > others" folder too.
- Deleted all IFPU injections, Fake ID`s & seetings (Anyway I will check one more time)

And now I will try:

- try Lilu + WEG with no Device Properties set which should trigger WEG's auto detect/auto configure.
___________

When you say "...if that fails then configure IGPU by means of device properties." that means this config?:

Devices --> Fake ID --> IntelGFX --> 0x12345678
Graphics --> Inject Intel --> Check this ON.
Graphics --> ig-platform-id --> 0x19120000

If is yes, that works for me, but i get glitch on top menu bar and blank app. when I open some app.
___________

BTW I attach my Debug.zip from the [TOOL TO GENERATE REPORTS AND DEBUGS], maybe it helps.

Thanks Jay :)
 

Attachments

  • debug_3795.zip
    1.5 MB · Views: 88
Last edited:
BTW I attach my Debug.zip from the [TOOL TO GENERATE REPORTS AND DEBUGS], maybe it helps.


@Maesito,

I cant see much wrong with your config.plist ... the only thing i would question is that you have null strings for IMIE and Intel GFX in the FakeID section :-

Code:
        <key>FakeID</key>
        <dict>
            <key>ATI</key>
            <string>0x0</string>
            <key>IMEI</key>
            <string></string>
            <key>IntelGFX</key>
            <string></string>
            <key>LAN</key>
            <string>0x0</string>
            <key>NVidia</key>
            <string>0x0</string>
            <key>SATA</key>
            <string>0x0</string>
            <key>WIFI</key>
            <string>0x0</string>
            <key>XHCI</key>
            <string>0x0</string>
        </dict>


Clover expects to see 0x0 if no value is specified ....
I'm not sure what passing a null string would do so i would set those two back to 0x0.
Other than that i can't see much wrong with your config.plist.

Kextcache log file shows that Lilu + WhatEverGreen are installed correctly in /L/E.

Cheers
Jay
 
Back
Top