Jump to content
WarDoc

WhatEverGreen Support Topic

977 posts in this topic

Recommended Posts

There you see my problem... :)

It's either one or the other....

It would be great to have both up and running.

 

Thank you both for your time and explanations

Share this post


Link to post
Share on other sites
Advertisement
9 minutes ago, al6042 said:

the screenshot comes from the skylake without discrete graphics... ;)

 

I see on a screenshot that the discrete GPU is available.
Without the discrete GPU, output another.

Edited by Andrey1970

Share this post


Link to post
Share on other sites
4 minutes ago, al6042 said:

There you see my problem... :)

It's either one or the other....

It would be great to have both up and running.

 

Thank you both for your time and explanations

I think that is the way it works, either you get QuickSync+ or you get DRM playback, I don't think you can have both unless there is someway that hasn't been discovered yet for switchable graphics on a hack. 

Share this post


Link to post
Share on other sites
16 minutes ago, Pavo said:

I think that is the way it works, either you get QuickSync+ or you get DRM playback, I don't think you can have both unless there is someway that hasn't been discovered yet for switchable graphics on a hack. 

DRM without IQSV is not possible on CPU with IGPU.
Switch-off IGPU does not do a CPU to another.

Share this post


Link to post
Share on other sites
11 hours ago, jsl2000 said:

Thanks for this advice which worked for WEG 1.2.x now without broken HDMI audio of R9 290X GPU anymore !

BTW have you tried edit CFG_FB_LiMIT data in aty-config of AMD7000Controller.kext ? It should be the number of total display ports ( in yours 6) instead of default 0.

Great!  Glad to hear that helped.

 

I have not tried editing CFG_FB_LIMIT, however I can see in Ioreg that it is set correctly on GFX0 (to 6).  At least it is with WEG installed - without WEG, 'display@0' shows CFG_FB_LIMIT=0.  But booting with WEG doesn't change my problem, so I think it's unrelated.

 

In any case I am pretty sure I do not have any problem with connector detection.  I used to think that was the problem, and I spent a long time testing every possible FB choice (with InjectATI) and I tried patching every available AMD7000 FB using Clover kext patches. I thought if I could get a FB patch working, it might solve my problem.  I finally managed to find a FB I could patch correctly (Ramen - which required I also set boot argument agdpmod in order to use it), and found the problem still existed, no change at all.

 

After that I realised that connector detection must surely be working fine - all my displays appear in Display Preferences, and show up in About This Mac with the correct details.  The problem is something else, something that can be fixed by a sleep and wake.  I guess there must be some re-initialisation of the GPU done during wake, something done differently to boot.

 

The last thing I can think of to try is to compare Ioreg taken straight after boot - when only two monitors have picture - with Ioreg taken after sleep&wake.  See if I can spot anything obviously changed, that maybe can be injected with an SSDT.  But I don't have much hope any more, especially now that I learned that someone else had the problem and fixed it with an EFI-related BIOS change, something I cannot do on a Legacy BIOS.

Edited by TheBloke

Share this post


Link to post
Share on other sites
23 hours ago, TheBloke said:

The last thing I can think of to try is to compare Ioreg taken straight after boot - when only two monitors have picture - with Ioreg taken after sleep&wake.  See if I can spot anything obviously changed, that maybe can be injected with an SSDT.  But I don't have much hope any more, especially now that I learned that someone else had the problem and fixed it with an EFI-related BIOS change, something I cannot do on a Legacy BIOS. 

 

I've done this comparison, and found a few properties that differ before and after sleep&wake - and therefore before and after I get a picture on all monitors.

 

These are the differences I found in Ioreg:

GFX0 -> PP_BootupDisplayState

After boot, before sleep:  <01000000> |  After wake =  <02000000>

 

GFX0 -> RadeonFramebuffer@0,1,2, etc -> AMDFrameBufferSI -> IOScreenRestoreState 

After boot, before sleep = not there |  After wake = <02000000>

 

GFX0 -> RadeonFramebuffer@0,1,2,etc -> AMDFrameBufferSI  -> display0 -> AppleDisplay -> IOPowerMAnagement -> DevicePowerState

After boot, before sleep = not there |  After wake = 0x3

 

PP_BootupDisplayState looks the most promising, as it's set on GFX0 itself.  But I don't know if this is a symptom, or a cause.  Ie, would changing PP_BootupDisplayState to 02,00,00,00 fix the problem?  Or is it set automatically when the problem is fixed, by some other means.

 

The question is, is there any way I can set PP_BootupDisplayState myself?  Is it possible to set this via an SSDT?  It's not an aty_config, aty_properties or cail_properties setting, which are the three mentioned on the WEG Github page.  But can any setting of GFX0 be changed by SSDT?

 

I have already tried a couple of SSDTs already but I'm not sure if I'm doing it right for my mobo, and I don't want to keep experimenting if it's not even possible. 

 

I'd be grateful if anyone knows for sure if I can set any property on GFX0 via SSDT - or any other method? 

Edited by TheBloke

Share this post


Link to post
Share on other sites
1 hour ago, TheBloke said:

 

I've done this comparison, and found a few properties that differ before and after sleep&wake - and therefore before and after I get a picture on all monitors.

 

These are the differences I found in Ioreg:

GFX0 -> PP_BootupDisplayState

After boot, before sleep:  <01000000> |  After wake =  <02000000>

 

GFX0 -> RadeonFramebuffer@0,1,2, etc -> AMDFrameBufferSI -> IOScreenRestoreState 

After boot, before sleep = not there |  After wake = <02000000>

 

GFX0 -> RadeonFramebuffer@0,1,2,etc -> AMDFrameBufferSI  -> display0 -> AppleDisplay -> IOPowerMAnagement -> DevicePowerState

After boot, before sleep = not there |  After wake = 0x3

 

PP_BootupDisplayState looks the most promising, as it's set on GFX0 itself.  But I don't know if this is a symptom, or a cause.  Ie, would changing PP_BootupDisplayState to 02,00,00,00 fix the problem?  Or is it set automatically when the problem is fixed, by some other means.

 

The question is, is there any way I can set PP_BootupDisplayState myself?  Is it possible to set this via an SSDT?  It's not an aty_config, aty_properties or cail_properties setting, which are the three mentioned on the WEG Github page.  But can any setting of GFX0 be changed by SSDT?

 

I have already tried a couple of SSDTs already but I'm not sure if I'm doing it right for my mobo, and I don't want to keep experimenting if it's not even possible. 

 

I'd be grateful if anyone knows for sure if I can set any property on GFX0 via SSDT - or any other method? 

You sure can https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.Radeon.en.md

Share this post


Link to post
Share on other sites
On 11/6/2018 at 12:12 AM, Pavo said:

 

Thanks for the confirmation, Pavo.

 

I still haven't managed to get an SSDT working for my GPU. I am not sure how to address the GPU, as in Ioreg it appears (without WEG) as pci-bridge@7 -> IOPP -> display@0:

NptmvOJ.png

 

With WEG, 'display@0' is renamed GFX0.  But all SSDT guides I have read describe referring to the GPU under an entry like NPE3 or PEG0, eg _SB.PCI0.NPE3 or _SB.PCI0.PEG0.  But I have no such intermediate entry visible, it just goes pci-bridge > display0, so I don't know how to select the GPU in an SSDT.  I saw one post that suggested that the missing intermediate entry might be caused by 'Drop OEM Tables' in Clover, but I don't have that set.  So I got stuck there.  I am going to keep researching on this to see what's needed to use an SSDT for GPU on my system.

 

In the meantime I tried directly hacking the WEG code.  The good news is that I found it's pretty easy to set properties on the GPU from WEG.  The bad news is that I cannot set PP_BootupDisplayState.  Or at least, any changes I make do not stick - every time I check it in ioreg it is <01,00,00,00>.  So either my setting fails, or it is set back again by something else.


I did it by modifying kern_rad.cpp, changing the end of void RAD::mergeProperty:

Spoiler



if (!strcmp(name, "PP_BootupDisplayState")) {
  DBGLOG("rad", "PP_BootupDisplayState - changing value to 02,00,00,00");
  uint8_t PPData[] = { 0x02, 0x00, 0x00, 0x00 };
  auto newval = OSData::withBytes(PPData, sizeof(PPData));
  props->setObject(name, newval);

  DBGLOG("rad", "Setting PP_BootupDisplayState2 to 02,00,00,00");
  const char *newname = "PP_BootupDisplayState2";
  props->setObject(newname, newval); 
}
else {
  // Default merge as is
  props->setObject(name, value);
  DBGLOG("rad", "prop %s was merged", name);
}


 

 

I also set a new property called PP_BootupDisplayState2.  This was to test that I could set a property and that I had the format correct.  I could set the new one fine, but not the original property:

$ ioreg -fl | grep BootupDisplayState
    | |   |   | |   "PP_BootupDisplayState2" = <02000000>
    | |   |   | |   "PP_BootupDisplayState" = <01000000>

No matter how I set PP_BootupDisplayState, its value always shows as 01,00,00,00.  I also tried changing it in a couple of other places, for example in the same way that CFG_FB_LIMIT is set (in applyPropertyFixes: service->setProperty("PP_BootupDisplayState", ...) ), but I can never get a changed value to apply to this property.  So maybe I am setting it too early, and something else is changing it back later.   Or maybe it's a read-only property, or can only be set at boot/wake.   I don't know.

 

Anyway, even if I could change it it was always a long-shot that changing this property would fix my problem.  I thought I'd try and maybe I'd get lucky.  I didn't :)

 

Oh well, at least now I understand a little bit of how WEG works, and it was fun to read through the code and experiment with some edits. Even if I mostly felt like this guy:

SgiYlVTm.jpg

 

 

Share this post


Link to post
Share on other sites
14 minutes ago, TheBloke said:

 

Thanks for the confirmation, Pavo.

 

I still haven't managed to get an SSDT working for my GPU. I am not sure how to address the GPU, as in Ioreg it appears (without WEG) as pci-bridge@7 -> IOPP -> display@0:

NptmvOJ.png

 

With WEG, 'display@0' is renamed GFX0.  But all SSDT guides I have read describe referring to the GPU under an entry like NPE3 or PEG0, eg _SB.PCI0.NPE3 or _SB.PCI0.PEG0.  But I have no such intermediate entry visible, it just goes pci-bridge > display0, so I don't know how to select the GPU in an SSDT.  I saw one post that suggested that the missing intermediate entry might be caused by 'Drop OEM Tables' in Clover, but I don't have that set.  So I got stuck there.  I am going to keep researching on this to see what's needed to use an SSDT for GPU on my system.

 

In the meantime I tried directly hacking the WEG code.  The good news is that I found it's pretty easy to set properties on the GPU from WEG.  The bad news is that I cannot set PP_BootupDisplayState.  Or at least, any changes I make do not stick - every time I check it in ioreg it is <01,00,00,00>.  So either my setting fails, or it is set back again by something else.


I did it by modifying kern_rad.cpp, changing the end of void RAD::mergeProperty:

  Reveal hidden contents

 



if (!strcmp(name, "PP_BootupDisplayState")) {
  DBGLOG("rad", "PP_BootupDisplayState - changing value to 02,00,00,00");
  uint8_t PPData[] = { 0x02, 0x00, 0x00, 0x00 };
  auto newval = OSData::withBytes(PPData, sizeof(PPData));
  props->setObject(name, newval);

  DBGLOG("rad", "Setting PP_BootupDisplayState2 to 02,00,00,00");
  const char *newname = "PP_BootupDisplayState2";
  props->setObject(newname, newval); 
}
else {
  // Default merge as is
  props->setObject(name, value);
  DBGLOG("rad", "prop %s was merged", name);
}

 

 

 

 

 

I also set a new property called PP_BootupDisplayState2.  This was to test that I could set a property and that I had the format correct.  I could set the new one fine, but not the original property:


$ ioreg -fl | grep BootupDisplayState
    | |   |   | |   "PP_BootupDisplayState2" = <02000000>
    | |   |   | |   "PP_BootupDisplayState" = <01000000>

No matter how I set PP_BootupDisplayState, its value always shows as 01,00,00,00.  I also tried changing it in a couple of other places, for example in the same way that CFG_FB_LIMIT is set (in applyPropertyFixes: service->setProperty("PP_BootupDisplayState", ...) ), but I can never get a changed value to apply to this property.  So maybe I am setting it too early, and something else is changing it back later.   Or maybe it's a read-only property, or can only be set at boot/wake.   I don't know.

 

Anyway, even if I could change it it was always a long-shot that changing this property would fix my problem.  I thought I'd try and maybe I'd get lucky.  I didn't :)

 

Oh well, at least now I understand a little bit of how WEG works, and it was fun to read through the code and experiment with some edits. Even if I mostly felt like this guy:

SgiYlVTm.jpg

 

 

What exact are you trying to add or patch with using a SSDT? You can always add, patch or remove entries with device properties in Clover config.

Share this post


Link to post
Share on other sites
1 minute ago, Pavo said:

What exact are you trying to add or patch with using a SSDT? You can always add, patch or remove entries with device properties in Clover config.

 

Ahhh I forgot all about Clover Device Properties!   I never used them before so I forgot that was an option.  That would have been a much simpler way to do it :) Thank you.  I am going to try setting PP_BootupDisplayState with Clover Device Properties, just to confirm it gets the same result as when I did it with WEG.

 

If you are interested, here is the full story of what I am trying to fix:

 

I am trying to resolve a problem with my X58 system with legacy boot, and AMD 7970 Ghz (R280X) GPU.  This GPU has 6 x connectors and 6 x monitors.    The problem: on boot, all monitors have signal and show in Display Preferences, but only two have a picture.  Other four are black.    But if I sleep and then wake, all 6 monitors get a picture and work fine.  This is the same both with and without WEG, and with/without all available Clover GFX options (InjectATI/RadeonDeInit, etc). 

 

I compared ioreg from straight after boot with ioreg after sleep&wake to see which properties changed on GFX0 (list in this post).   One property that was different was PP_BootupDisplayState:  after boot/before sleep, it is <01,00,00,00>.  After sleep & wake, it is <02,00,00,00>

 

So I thought: maybe if I can change PP_BootupDisplayState to <02,00,00,00>, that might fix something.   I first tried with SSDT, but I couldn't find a way to make an SSDT to reference my GPU on my motherboard (as described in previous post).   So then instead I did it with direct code changes to WEG.  But I can't get any change to apply to PP_BootupDisplayState, it always reads <01,00,00,00) until a sleep&wake is done.  So I think this solution cannot work - probably PP_BootupDisplayState is read-only, or set by something else.  It was always a long shot anyway.  But now I will try setting PP_BootupDisplayState with Clover Device Properties, just to be sure.
 

The final thing I am going to investigate is VBIOS registers for my GPU, like Mieze did with her SSDT fix for wake-up issues.  I am going to compare VBIOS before sleep and after sleep/wake, to see if I can spot any difference in registers that maybe I can change with SSDT or Clover Device Properties, like Mieze did.  The issue Mieze fixed sounded rather similar to my issue - she says: "When OS X boots up the framebuffer controller kext will find the AMD GPU in vanilla state, initialize it properly and wakeup will work as expected...   Using UEFI VBIOS the AMD GPU will be initialized too ... but unfortunately macOS's framebuffer controller kext will notice that the GPU has already been initialized and skips the basic setup ..."  This sounds a bit similar to my problem: it is like my GPU is not being properly initialised by the framebuffer kext, until a sleep & wake is done.  In my case, I am using Legacy BIOS, not UEFI.  But maybe I have a similar problem, but the other way around.  I don't know, but I want to investigate this too.

 

Share this post


Link to post
Share on other sites

I used to use hex editor patching of the AppleIntelFramebufferAzul but I can no longer be bothered doing this. I try to use whatvergree etc, and I have the enabled working but I cannot get the stolen and frame buffer sizes to work using whatevergreen.

I have the following binary patch working:

< 009f6e0 0003 0d22 0300 0303 0000 0200 0000 0130
< 009f6f0 0000 0000 0000 6000 1499 0000 1499 0000
---
> 009f6e0 0003 0d22 0300 0303 0000 0800 0000 0200
> 009f6f0 0000 0000 0000 8000 1499 0000 1499 0000

Which means I need to specify 3 settings (from: https://pikeralpha.wordpress.com/2013/06/27/appleintelframebufferazul-kext/) they are
AAPL,ig-platform-id -> AwAiDQ== (ieecho -n AwAiDQ | base64 -d | hexdump) gives 0003 0d22
framebuffer-patch-enable -> AQAAAA== -> 0001 0000
framebuffer-unifiedmem -> AACAAA== 0000 0080 (this is working, tested independently and is in the example)
framebuffer-stolenmem -> AAAAAg== (this is not working as it causes crashing)
framebuffer-fbmem -> I don't know what to use but I know that if it is not large I cannot run 4K display.

I have tried a few endian formats, but I have not looked at the source yet. Does anyone see anything wrong or have tips for the endianess?
 

Share this post


Link to post
Share on other sites

@Roger Smith I have no personal experience of Intel FB patching, but there is another thread with detailed instructions for it and which has examples for all those things you're trying to patch.

 

I'd check this out, and perhaps ask further questions there:

 

 

Edited by TheBloke

Share this post


Link to post
Share on other sites
2 hours ago, vit9696 said:

@TheBloke, you need PP,PP_BootupDisplayState to override the value. Check the FAQ more carefully. I doubt it will help unfortunatly though.

Thanks for replying, @vit9696.  Yes I have tried PP,PP_BootupDisplayState in an SSDT.   Also PP_BootupDisplayState and PP,PP_BootupDisplayState in Clover Device Properties.  Also a direct set of PP_BootupDisplayState from modifying WEG code.  None of them can even change the value - it seems GFX0->PP_BootupDisplayState cannot be overridden, it always retains its default value of <01,00,00,00> no matter how I try to set it.  Only sleep & wake changes it to <02,00,00,00>.  

 

And even if I could change it, I doubt it would fix my problem.  It's probably a symptom, not a cause.

 

Last night I tried Mieze's SSDT method for resetting all Radeon registers to default values, and that made no difference either.  I think I am going to give up on my problem.  It seems possibly related to EFI vs Legacy BIOS, and as I am on X58 with only Legacy boot as an option, maybe there is no solution.  At least none that I can work out after spending literally 10s of hours on this problem.

Edited by TheBloke

Share this post


Link to post
Share on other sites

Hi @Andrey1970

A couple of users recognised that in Mojave 10.14.1 the H.264 support seem to be lost, while using a connectorless IGPU together with an RX or Vega card.

VP-10_14.1-KBL-dual-1.png.59137e2b2c7f064eff848249d9afcc57.png

VP-10_14.1-KBL-dual-2.png.f1c880128eb70cbd32a23349037941f3.png

 

That happens also, if the guys are using the AppleGraphicsPowerManagement (AGPD)-KextsToPatch entry instead of WEG (WhateverGreen).

Do you know about this issue and would you might be able to help mitigate the situation?

 

 

Share this post


Link to post
Share on other sites
3 minutes ago, al6042 said:

Hi @Andrey1970

A couple of users recognised that in Mojave 10.14.1 the H.264 support seem to be lost, while using a connectorless IGPU together with an RX or Vega card.

VP-10_14.1-KBL-dual-1.png.59137e2b2c7f064eff848249d9afcc57.png

VP-10_14.1-KBL-dual-2.png.f1c880128eb70cbd32a23349037941f3.png

 

That happens also, if the guys are using the AppleGraphicsPowerManagement (AGPD)-KextsToPatch entry instead of WEG (WhateverGreen).

Do you know about this issue and would you might be able to help mitigate the situation?

 

 

 

What's app did you use?? I need to check with mine. I use Intel HD 530 + RX 580.

Share this post


Link to post
Share on other sites

On my AMD 7970 Ghz (R9 280X), VideoProc says I don't support any HW encode/decode at all:

 

Rrq4eGu.png

 

 

Is this expected?  My googling seems to suggest that the R9 280X should have some sort of HW decode, at least for H264 (VCE version 1.0).   But maybe VideoProc doesn't support this on macOS - the WinXDVD info page mostly mentions NVidia and Intel QuickSync.

 

Does anyone know if this is an expected result with AMD R9 280X?

Edited by TheBloke

Share this post


Link to post
Share on other sites
2 minutes ago, al6042 said:

Since your CPU doesn't contain an IPGU and the AMD R9 280X only supports VCE1.0, I guess this is to be expected.

 

 

Yeah, but VCE 1.0 allows H264, which is an option in VideoProc - so shouldn't it at least support H264?   Or do you think I have the same issue you mentioned - no H264 support in macOS 10.14.1 ?

Share this post


Link to post
Share on other sites
3 hours ago, al6042 said:

Hi @Andrey1970

A couple of users recognised that in Mojave 10.14.1 the H.264 support seem to be lost, while using a connectorless IGPU together with an RX or Vega card.

VP-10_14.1-KBL-dual-1.png.59137e2b2c7f064eff848249d9afcc57.png

VP-10_14.1-KBL-dual-2.png.f1c880128eb70cbd32a23349037941f3.png

 

That happens also, if the guys are using the AppleGraphicsPowerManagement (AGPD)-KextsToPatch entry instead of WEG (WhateverGreen).

Do you know about this issue and would you might be able to help mitigate the situation?

 

 

1409286946_ScreenShot2018-11-11at00_04_56.png.6c7857834662ee754cae12d465e9254b.png1777306401_ScreenShot2018-11-11at00_05_23.png.371ce2f40af111b7077d68ea7b28345b.png

 

 

Still working good here,, IGPU = Intel HD 530 and AMD RX580 with latest Lilu.kexts and WhateverGreen.kext. But my system is Mojave 10.14.2 Public Beta

 

 

Edited by Andres ZeroCross

Share this post


Link to post
Share on other sites

Interesting...

could be that the issue will be resolved with the official Version of 10.14.2.

Let's see...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By glasgood
      CLOVER DUAL BOOT MOJAVE & WINDOWS 10 GUIDE 
       

       
       
      INCLUDES  MBR / LEGACY BIOS  TO  GPT / EFI CONVERSION
      USING MBR2GPT TOOL
       
       
      PREREQUISITE: Two physical discs ( SSD’s or HDD’s )
       
       
       
       
       
      STEP 1 - Clover dual boot configuration 
       
      Open config.plist with Clover Configurator
       
      Boot
       Legacy = PBR Timeout = True ( will remove the Timeout countdown, from Clover boot menu)  

       
      GUI 
      Scan / Custom
       Entries = True  Tool = True  Legacy = False ( removes extra Windows 10 entries )  
      Hide Volume
      - Preboot ( macOS Preboot )
      - Recovery ( macOS Recovery )
       

       
      So at boot you will have two options: boot macOS Mojave or Windows 10 
       
       
       
       
       
       
       
      ————————————————————
       
       
      STEP 2 - Using a drive without Windows 10 installed
       
      Disconnect system drive that contains your macOS Mojave install from computer ( This is so that Windows does not overwrite existing macOS Mojave boot loader )
       
      Proceed with a Windows 10 UEFI install.  
      After installation reconnect macOS Mojave Drive, the Windows installation should now be detected and usable in Clover. 
      If Windows 10 is not detected or able to boot,  then verify you installed Windows 10 as UEFI and not MBR ---->  ( Read step 2 - For a drive with Windows 10 installed )
       
       
      OR
       
       
       
      STEP 2 - Using a drive with Windows 10 already installed
       
      Verify your Windows install is  GPT / UEFI or MBR / Legacy BIOS.   
      If Windows install is GPT UEFI then Windows 10 install is ready to use at Clover boot menu, you should be able to boot into Windows directly from Clover boot screen. 
       

       
       
      But if  Windows drive is detected at Clover boot screen, but when booting Windows you get a black screen with a cursor on the top left,
      then this is most likely because Windows drive is MBR ( Legacy BIOS ).  You can easily convert MBR to GPT using  Windows MBR2GPT tool ( this saves hours work having to reinstall Windows 10 and setting up all your applications again  ) 
       
      If Windows 10 install is MBR / Legacy BIOS  then simply convert to GPT / UEFI  following instructions below ( read video summary and view video )
       
       
      ** To use Windows 10  MBR2GPT tool  you must have Windows 10 version 1703 ( creators update  ) or later and less than 3 partitions on 
      the Windows 10 drive **
       
      Video summary:
       
      Confirm Windows 10 drive is MBR Legacy BIOS ( in Windows Disk Management ) Reboot into Windows PE ( Advanced Startup ) Convert from MBR Legacy BIOS to GPT UEFI ( using commands below ) mbr2gpt /validate mbr2gpt /convert Restart Verify Windows 10 drive has changed to GPT UEFI ( in Windows Disk Management )  
       
       
       
      After conversion Windows 10 is ready to use at the Clover boot menu 
       
       
       
      STEP 3 - Stop Windows Boot manager from overriding Clover boot manager
       
      How to stop Windows boot manager from overriding your Hackintosh Clover boot manager when using dual booting between macOS and Windows
       
       
       
       
       
       
    • By headkaze
      Framebuffer patching in Mojave
      Binary patching framebuffers using KextsToPatch in Clover is no longer a viable method in Mojave for Skylake and above. Now you need to use Lilu + WhateverGreen.
       
      Not just for Mojave
      This method of framebuffer patching is not only required for Mojave we recommend it for all previous and future releases of macOS.
       
      Coffee Lake Users
      Please note that the new WhateverGreen will not work with fake Kaby Lake platform-id's. You will need to have either macOS 10.14 Beta 4 (18A336e) or macOS High Sierra 10.13.6 (17G2112). The latter is a special build only available to MacBookPro15,1 or MacBookPro15,2 board id's. You can create a macOS High Sierra 10.13.6 (17G2112) installer by running installinstallmacos.py. (Update: vit9696 added back ability to fake Kaby Lake platform-id's)
       
      Lilu + WhateverGreen
      WhateverGreen is going to replace all the other video patching plugins for Lilu (it currently has merged WhateverGreen, IntelGraphicsFixup, NvidiaGraphicsFixup, Shiki and CoreDisplayFixup). Others will likely follow (such as AppleALC, HibernationFixup and IntelGraphicsDVMTFixup). This is aiming to be the all-in-one solution for video.
       
      Preliminary
      1. Remove:
      - FakePCIID_Intel_HD_Graphics
      - IntelGraphicsFixup
      - NvidiaGraphicsFixup
      - CoreDisplayFixup
      - Shiki
      2. Turn off all graphics injections in Clover:
      - config.plist/Graphics/Inject/ATI=NO
      - config.plist/Graphics/Inject/Intel=NO
      - config.plist/Graphics/Inject/NVidia=NO
      - config.plist/Graphics/ig-platform-id=
      - config.plist/Devices/FakeID/IntelGFX=

      3. Disable DSDT Clover fixes:
      - AddHDMI
      - FixDisplay
      - FixIntelGfx
      - AddIMEI
      4. Disable UseIntelHDMI
      5. Remove boot argument: -disablegfxfirmware
      6. Remove any IGPU and HDMI entries from:
      - config.plist/Devices/Arbitrary
      - config.plist/Devices/Properties
      - config.plist/Devices/AddProperties
      7. Remove any IGPU and HDMI related SSDT and DSDT from:
      - CLOVER/ACPI/patched
      8. Renaming GFX0 -> IGPU
      - WhateverGreen will do this automatically (see caveat below)
      - Be aware that WhateverGreen does not rename all instances of GFX0 -> IGPU but should be okay in most cases
      - You may need to include Clover GFX0 -> IGPU rename for other kexts or ACPI patching that require it
       
      Compile Lilu + WhateverGreen
      Download WhateverGreen. Make sure you place the debug version of Lilu into the root of WhateverGreen before you compile. Install Lilu and WhateverGreen kext's into the usual place. Compile WhateverGreen as debug if you want to view debug output.
       
      Having trouble compiling?
      If you're having trouble compiling you can download the official release binaries or download my (unsupported) build_lilu.sh shell script and run it in a folder to download and build Lilu + WhateverGreen using Xcode automatically. I recommend you try the debug versions first (place them into Clover's EFI/Clover/kexts/Other folder).
       
      Get the device path of your IGPU:
      Download and use the gfxutil tool like so:
      $ ./gfxutil -f IGPU DevicePath = PciRoot(0x0)/Pci(0x2,0x0) ig-platform-id
      For the AAPL,ig-platform-id (AAPL,snb-platform-id for Sandy Bridge) entry Clover requires this value to be in Data format so you need to reverse the bytes. So if you want your platform-id to be 0x3EA50009 first reverse the bytes (0900A53E) then use Xcode's plist editor to add the values to Clover's config.plist.

       
      What ig-platform-id should I use for my system?
      You should choose one that is the closest match to your system. I recommend you do some research on this before choosing one. See post #2 for available options. More info can be found here.
       
      You can determine the generation of your CPU by the first digit after the hyphen.
      Examples:
      - Intel(R) Core(TM) i5-2760QM (Gen 2)
      - Intel(R) Core(TM) i7-5257U CPU @ 2.70GHz (Gen 5)
      - Intel(R) Core(TM) m3-6Y30 (Gen 6)
      - Intel(R) Core(TM) i5-8350U (Gen 8)
       
      Spoofing Intel CPU Gen
      If you need to spoof a different Intel CPU generation you can use the lilucpu=N boot flag. The N refers to the following Intel generations:
      4    SandyBridge 5    IvyBridge 6    Haswell 7    Broadwell 8    Skylake 9    KabyLake 10   CoffeeLake To spoof a CPU you will need to set a valid device-id in your GPU entry in Devices/Properties for the appropriate Intel generation.
       
      Eg. Spoofing Skylake (lilucpu=8 boot flag with device-id=0x16190000), Kaby Lake (lilucpu=9 boot flag with device-id=0x12590000).
       
      Here are some recommended frames:
       
      Gen 2: Sandy Bridge (Intel HD Graphics 2000/3000)
      - S/L/E/AppleIntelSNBGraphicsFB.kext
      - Support started with OS X 10.7.x and ended with macOS 10.13.6
      - Metal support is not available
      - device-id: 0x0102 0x0106 0x010A 0x0112 0x0116 0x0122 0x0126
      - AAPL,snb-platform-id (desktop): 0x00030010 (default)
      - AAPL,snb-platform-id (laptop): 0x00010000 (default)
       
      Gen 3: Ivy Bridge (Intel HD Graphics 2500/4000)
      - S/L/E/AppleIntelFramebufferCapri.kext
      - Support started with OS X 10.8.x
      - device-id: 0x0152 0x0156 0x0162 0x0166
      - AAPL,ig-platform-id (desktop): 0x0166000A (default), 0x01620005
      - AAPL,ig-platform-id (laptop): 0x01660003 (default), 0x01660009, 0x01660004
       
      Gen 4: Haswell (Intel HD Graphics 4200-5200)
      - S/L/E/AppleIntelFramebufferAzul.kext
      - Support started with OS X 10.9.x
      - device-id: 0x0D26 0x0A26 0x0A2E 0x0D22 0x0412
      - AAPL,ig-platform-id (desktop): 0x0D220003 (default)
      - AAPL,ig-platform-id (laptop): 0x0A160000 (default), 0x0A260005 (recommended)
       
      Gen 5: Broadwell (Intel HD Graphics 5300-6300)
      - S/L/E/AppleIntelBDWGraphicsFramebuffer.kext
      - Support started with OS X 10.10.2
      - device-id: 0x0BD1 0x0BD2 0x0BD3 0x1606 0x160E 0x1616 0x161E 0x1626 0x1622 0x1612 0x162B
      - AAPL,ig-platform-id (desktop): 0x16220007 (default)
      - AAPL,ig-platform-id (laptop): 0x16260006 (default)
       
      Gen 6: Skylake (Intel HD Graphics 510-580)
      - S/L/E/AppleIntelSKLGraphicsFramebuffer.kext
      - Support started with OS X 10.11.4
      - device-id: 0x1916 0x191E 0x1926 0x1927 0x1912 0x1932 0x1902 0x1917 0x193B 0x191B
      - AAPL,ig-platform-id (desktop): 0x19120000 (default)
      - AAPL,ig-platform-id (laptop): 0x19160000 (default)
       
      Gen 7: Kaby Lake (Intel HD Graphics 610-650)
      - S/L/E/AppleIntelKBLGraphicsFramebuffer.kext
      - Support started with macOS 10.12.6
      - device-id: 0x5912 0x5916 0x591B 0x591C 0x591E 0x5926 0x5927 0x5923 0x87C0
      - AAPL,ig-platform-id (desktop): 0x59160000 (default)
      - AAPL,ig-platform-id (laptop): 0x591B0000 (default)
       
      Gen 8: Coffee Lake (Intel UHD Graphics 630)
      - S/L/E/AppleIntelCFLGraphicsFramebuffer.kext
      - Support started with macOS 10.13.6 (17G2112) / 10.14 beta 4 (18A336e)
      - device-id: 0x3E9B 0x3EA5 0x3EA6 0x3E92 0x3E91 0x3E98
      - AAPL,ig-platform-id (desktop): 0x3EA50000 (default), 0x3E9B0007 (recommended)
      - AAPL,ig-platform-id (laptop): 0x3EA50009 (default)
       
      Framebuffer Patching
      WhateverGreen does most of the work automatically for you and in most cases you do not need any extra Framebuffer Patching. At the minimum though you should choose an ig-platform-id suitable for your system and place it in config.plist/Devices/Properties like this:

      Here are some reasons why you might need extra Framebuffer Patching:
      - Setting DVMT for those who can't set it above 32 MB in BIOS (framebuffer-stolenmem / framebuffer-fbmem)
      - Setting higher VRAM for 4K users who experience graphical glitches (framebuffer-unifiedmem)
      - Disabling eGPU (disable-external-gpu)
      - Enable pixel clock patch for 4K support (enable-hdmi20)
      - Disabling connectors to enable sleep (framebuffer-pipecount / framebuffer-portcount / framebuffer-conX-type=-1)
      - Removing CNConnectorAlwaysConnected flag for eDP laptop screens on < 10.13.6 (framebuffer-con0-flags=0x00000090)
      - Changing connector types to match your systems ports (framebuffer-conX-type)
       
      Framebuffer Patching Types
      We have three different types of patches:
       
      1. Arbitrary (Recommended)
      framebuffer-patch-enable (required to enable below) framebuffer-framebufferid (optional; defaults to current platform-id) (all below are optional) framebuffer-mobile framebuffer-pipecount framebuffer-portcount framebuffer-memorycount framebuffer-stolenmem framebuffer-fbmem framebuffer-unifiedmem framebuffer-cursormem (Haswell only) framebuffer-camellia framebuffer-flags framebuffer-conX-enable (required to enable below) framebuffer-conX-index framebuffer-conX-busid framebuffer-conX-pipe framebuffer-conX-type framebuffer-conX-flags 2. All Data
      framebuffer-conX-enable (required to enable below) framebuffer-conX-alldata 3. Find / Replace
      framebuffer-patchX-enable (required to enable below) framebuffer-patchX-framebufferid (optional; defaults to current platform-id) framebuffer-patchX-find framebuffer-patchX-replace framebuffer-patchX-count (optional; defaults to 1) You should place your patches in config.plist/Devices/Properties in Clover config.plist.
       
      Here are some example patches:
      - 32MB BIOS, 19MB stolen (framebuffer) 9MB fbmem (cursor) 2048MB unifiedmem (vram)

       
      - Pipe / Port Count 3 to 2
      - Connector 1 DP to HDMI
      - Connector 2 Disable

       
      Here is an example of the All Data method:

       
      Here is an example of the Find / Replace method:

       
      Framebuffer Dumps
      There are two ways to dump your framebuffer data (both require WhateverGreen + Lilu debug versions):
       
      1. Using -igfxdump boot flag to dump IGPU framebuffer kext to /AppleIntelFramebuffer_X_Y (root of your boot drive)
       
      There are several ways of reading this dump:
      - Using 010 Editor along with the IntelFramebuffer.bt template
      - Using Hackintool File->Open menu
       
      2. Using -igfxfbdump boot flag to dump native and patched framebuffer table to ioreg at IOService:/IOResources/WhateverGreen
       
      There are several ways of reading this dump:
      - Using dump_platformlist.sh shell script
      - Using Hackintool File->Import->IOReg Dump menu
       
      3. Using Hackintool Framebuffer->macOS 10.14 menu
       
      Debug Output
      To get debug output from Lilu use the -liludbgall liludump=60 boot flags. You will need to compile Lilu and WhateverGreen as debug for both of these flags to work. Log files should be located at /var/log/Lilu_*.
       
      To view debug paste the following into Terminal (weglog.txt will output to your home directory):
      log show --predicate 'process == "kernel" AND (eventMessage CONTAINS "WhateverGreen" OR eventMessage CONTAINS "Lilu")' --style syslog --source --last boot >weglog.txt Getting Help

      To help the users of this forum diagnose issues with your configuration please generate a Lilu debug log and then run gen_debug.sh to generate a folder of debug files you can attach to a forum post requesting help.

      Credits
      - vit9696 and lvs1974 for WhateverGreen (Full Credits) and Lilu (Full Credits)
      - Andrey1970 for his guide on applelife.ru
      - RehabMan for all data patching method, ioreg framebuffer dump and other contributions
       


    • By fantomas1
      Hi InsanelyMacaholics   

      Use this thread to link / talk about of the future Nvidia Web Driver updates for macOS Sierra.
       
      10.12.6
      Nvidia Web Driver - 378.05.05.25f16 --> build 16G2016 (thanks to Cyberdevs) New!
      Nvidia Web Driver - 378.05.05.25f15 --> build 16G1918 (thanks to BreBo)
      Nvidia Web Driver - 378.05.05.25f14 --> build 16G1917 (thanks to BreBo)
      Nvidia Web Driver - 378.05.05.25f13 --> build 16G1815 (thanks to flowrider)
      Nvidia Web Driver - 378.05.05.25f12 --> build 16G1710 (thanks to BreBo)
      Nvidia Web Driver - 378.05.05.25f11 --> build 16G1618 (thanks to Frank Nitty)
      Nvidia Web Driver - 378.05.05.25f10 --> build 16G1510 (thanks to BreBo) 
      Nvidia Web Driver - 378.05.05.25f09 --> build 16G1408 (thanks to BreBo)
      Nvidia Web Driver - 378.05.05.25f08 --> build 16G1314 (thanks to BreBo)
      Nvidia Web Driver - 378.05.05.25f07 --> build 16G1314 (thanks to haring)
      Nvidia Web Driver - 378.05.05.25f06 --> build 16G1212 (thanks to WeBeRiO)
      Nvidia Web Driver - 378.05.05.25f04 --> build 16G1114 (thanks to lukazm)
      Nvidia Web Driver - 378.05.05.25f03 --> build 16G1036 (thanks to Gradou)
      Nvidia Web Driver - 378.05.05.25f01 --> build 16G29 (thanks to Badruzeus)
       
       
      10.12.5
      Nvidia Web Driver - 378.05.05.15f01 --> build 16F73 (see this post)
       
       
      10.12.4
      Nvidia Web Driver - 378.05.05.05f02 --> build 16E195(thanks to crachmaster4999)
      Nvidia Web Driver - 378.05.05.05f01 --> build 16E195 (thanks to Moviemakergr)  Pascal support!!!
      Nvidia Web Driver - 367.15.10.45f01 --> build 16E195 (thanks to Lanc)
       
       
      10.12.3

      Nvidia Web Driver - 367.15.10.35f01 --> build 16D32 (thanks to shatterhenner)
       
       
      10.12.2
      Nvidia Web Driver - 367.15.10.25f02 --> build 16C68 (see this post)
      Nvidia Web Driver - 367.15.10.25f01 --> build 16C67 (see this post)
      Nvidia Web Driver - 367.15.10.25b06 --> build 16C60b/16C63a (see this post)
       
       
      10.12.1
      Nvidia Web Driver - 367.15.10.15f03 --> build 16B2657/16B2659 (thanks to Moviemakergr).
      Nvidia Web Driver - 367.15.10.15f01 --> build 16B2555 (thanks to Moviemakergr)
       
       
      10.12.0
      Nvidia Web Driver - 367.15.10.05f01 --> build 16A323 (thanks to phi777)
       
       
      GM
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A323 (same driver since DP4/PB3)
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A322 (see this post)
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A320 (see this post)
       
       
      DP/PB
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A313a (DP8 & PB7) (see this post)
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A304a (DP7 & PB6) (see this post)
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A294a (DP6 & PB5) (see this post)
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A286a (DP5 & PB4) (see this post)
      Nvidia Web Driver - 367.10.10.05b01 --> build 16A270f (DP4 & PB3) (thanks to TheRacerMaster)
      Nvidia Web Driver - 367.05.10.05b07 --> build 16A254g (DP3 & PB2) (see this post)
      Nvidia Web Driver - 367.05.10.05b07 --> build 16A238m (PB1) (thanks to Faun) 
      Nvidia Web Driver - 367.05.10.05b07 --> build 16A239j (DP2) (thanks to Faun)
      Nvidia Web Driver - 367.05.10.05b03 --> build 16A201w (DP1) (thanks to Xmedik)
       
    • By fantomas1
      macOS Mojave 10.14.6 beta (18G29g)
    • By fantomas1
      This update:
      • Adds AirPlay 2 support for sharing videos, photos, music and more from your Mac directly to your AirPlay 2-enabled smart TV
      • Adds the ability to follow a magazine from the Apple News+ catalog browsing view
      • Includes support for the Reiwa (令和) era of the Japanese calendar
      • Improves audio latency on MacBook Pro models introduced in 2018
      • Fixes an issue that prevented certain very large OmniOutliner and OmniPlan documents from rendering properly
       
      Update
      Combo

      View full article
×