Hervé

Did you adjust the settings through the TouchPad PrefPane?

Both my Captain! 1) you fake the iGPU id to one natively supported by OS X/macOS 2) you inject the appropriate Capri frambuffer/layout through ig-platform-id + tick "Inject Intel "box

If you use SMBIOS of MBP9,2, you probably need to fake iGPU id of mobile HD4000 8086:0166 too. Desktop Mac models with Ivy Bridge HD4000 graphics are: iMac13,1 (i3 "education" model only, the others have nVidia graphics) mini6,1 mini6,2 Other laptop with HD4000 graphics are; MBA5,1 MBA5,2 MBP10,2 You can obtain a detailed list as everymac.com where you can conduct all sorts of searches and filtering. I suggest you download the IOReg of those model and check the reported PCI ids of the iGPU, then fake it. We've posted a link to a repository of Mac technical dumps here.

Your code remains incorrect; change it as follows: If (LEqual (PM6H, One)) { CreateBitField (BUF0, \_SB.PCI0._Y0C._RW, ECRW) // _RW_: Read-Write Status Store (Zero, ECRW) } If (PM0H) { CreateDWordField (BUF0, \_SB.PCI0._Y0D._LEN, F0LN) // _LEN: Length Store (Zero, F0LN) }

Screen sleep and computer sleep are 2 x different things and are usually displayed as separate elements in the Energy Savings PrefPane. I've no laptops newer than Haswell but can confirm that Apple had merged the 2 x for Haswell systems. This can however be reverted. All details available here.

If you read the existing topics for these QMI models, you'll find that you need to set them to the correct QMI mode if Direct IP (DIP) is not readily available. You may find this too difficult to your liking. Example here:

http://myhack.sojugarden.com/ Conti stopped development at Mavericks but it's a complete tool that offers: USB installer creation managed installation of OS X, from SL to Mavericks All you need is the M6800 bootpack. You can search the forum on myHack, years ago, I wrote some general summary of what it does and how.

With regards to cancelling the default APFS conversion of the target High Sierra partition, one can also reboot the HiSie USB installer after the installation process has created the temporary "macOS install from ..." partition and initiates a 1st reboot. Then, the idea is to modify the minstallconfig.xml file located on the macOS Install Data folder of the target partition/volume and change: <key>ConvertToAPFS</key> <true/> to: <key>ConvertToAPFS</key> <false/> with a basic text editor like vi. Once the mod is done, the "macOS install from ..." partition can be booted to complete the High Sierra installation in HFS+ mode (or whatever scheme the partition was originally made with). https://hackintosher.com/guides/how-to-opt-out-of-apfs-in-high-sierra/

Ouh, there's quite a lot in there that's not applicable to Mavericks! In your Clover config, you can remove: the USB controller renaming the AICPUPM patch the faking of desktop HD4600 (at least if you want to use nVidia GPU) the Azul layout-id injection most of the on-the fly patches (you can keep the Azul FB + Apple patches; maybe the Brcm4360 too) then, why do you drop all those SSDT tables? One usually only drops SSDTs CpuPm+ Cpu0Ist In the list of "sortedOrder" SSDTs, you have SSDT + SSDT-8 + SSDT-PNLF, yet your ACPI/patched folder has no SSDT.aml file, only the other too. You want to correct this, either by generating your own CPU-specific SSDT or by removing the entry from the Clover list Your IOReg does show the nVidia GPU but I noticed the _DSM method in SSDT-8 has no NVDA,Parent statement. you may want to add that just in case. Not thought of giving myHack a try instead of Clover? How did you make the Mavericks USB installer?

I see, sorry that was not clear to me. Post your own DSDT and we'll look into it in order to tell you what might be wrong or missing or needing adjustment.

Erm... do you or do you not have HDMI audio working? Because you say you do, then that you would like to get audio over HDMI working, so... Anyway, to get HDMI audio working you need: ALC292 audio working (whether with patched AppleHDA + dummy ALC292 kext + HDEF layout injection in DSDT/Clover or with AppleALC kext and HDEF layout injection in DSDT/Clover) patching of B0D3 device in DSDT (renaming to HDAU + injection of "hda-gfx" property) Patching of Azul FB layout so that you set your relevant output port to HDMI connector-type 0008 0000 You can consult my E6440 guide where all is explained in details.

For WWAN, head over to WWAN forum section where you can open a dedicated thread if needed. Of course, you'll have to indicate the model and specs of the device because "the WWAN module" just won't do...

Head over to our Wireless forum section, you'll find your answers there. https://osxlatitude.com/forum/104-wireless-and-bluetooth/

OS X/macOS kernels, patched for Haswell PM, will in no way be incompatible with any graphics drivers or otherwise. You can always look for older Mavericks-time Web drivers. Failing that, why not consider disabling the nVidia dGPU and operate solely on the HD4600 iGPU? Anyway, if you want more support, please post the usual stuff: Clover EFI folder or Chameleon Extra folder Clover or Chameleon version Version of Mavericks you run Copy of IOReg extraction indication of what you may have done with add-on kexts (eg: injection from Clover or installation to /L/E, etc.)

I confirm: windows server not initialising on output display. This is typically what happens when running on an unsupported dGPU or output port.

DW1540 is NOT supported. Please consult our wireless card inventory for a list of supported devices.

My last post was obviously not clear enough and some people keep pestering about updates so this thread is temporarily locked. We got the message, we know you're all disappointed and desperate for an update but nagging on and on will not change anything. Dinesh is not available for his own private reasons and that's the end of it for the time being.

You can consult/search our Wireless forum section re: DW1820A.

DW1550 is based on Broadcom BCM4352; that'll work with DSDT patch or AirportBrcm4360 patch of installation of Rehabman's FakePCIID + FakePCIID_Broadcom_Wifi kexts or Clover id faking. You can look that up in our Wireless forum section. nVidia K3100M should work OOB as far as I know.

Perfectly normal if you were using a patched Atheros40 kext in /S/L/E. It would have been replaced by a vanilla version during the update. Please refer to our wireless card inventory and apply the DSDT patch instead; that'll sort you out once and for all!

I've not searched the binary file of the kext for MB8,1 board-id, but I guess you can always try the patch then; you'll quickly see if it works or not.

Erm... no! That would effectively replace MacBookPro13,1 board-id ("Mac-473D31EABEB93F9B") by MacBook8,1 board-id ("Mac-BE0E8AC46FE800CC"), i.e. the opposite of what you probably desire. Before you even consider patching the AirPortBrcm4360 kext, please verify that the DW1820A works using MacBook8,1 SMBIOS. Did you do that ? If you did not, don't bother with the patch. However, if you've confirmed the card does work OOB after switching SMBIOS and you want to return to MBP13,1 SMBIOS (assuming this is what you normally use), you'll want to replace the MacBook8,1 board-id by MacBookPro13,1 board-id. You'll therefore have to swap your above Find/Replace hex strings because you got them the wrong way round. Find = original data to replace Replace = replacement/target data You'll also want to replace the patch description to this, although this is prurely cosmetic but accuracy would avoid much confusion: <string>DW1820A whitelist Patch (MBP13,1)</string>

AR9565 is not a reliable card in a Hackintosh. Better to opt for a better supported model...

Try and opt for MacBook8,1 SMBIOS to bypass potential whitelisting. Wikidevi states these were fitted with a Broadcom BCM94350 wireless card (Ven/Dev id=14e4:43a3, SubVen:SubDev id=106b:0131) If whitelisting were in place, the MB8,1 board-id to target for replacement in AirPortBrcm4360 binary patch would be "Mac-BE0E8AC46FE800CC". You would follow the exact same principles as detailed here for getting DW1520 cards working.