Hervé

That's perfectly normal since you no longer have graphics acceleration. Go back to your original config.plist; you uploaded a copy in post #3... If I were you, I would: remove all HDMI/Azul FB patches fake iGPU id 0x04128086 (Desktop HD 4600) inject IntelVideo inject Azul layout-id 0x0a260006 install latest Rehabman's FakePCIID + FakePCIID_Intel_HD_Graphics (the kexts you use are older and deprecated versions). Once you're back in business, patch the AppleIntelFramebufferAzul kext as follows to support HDMI output: Find: 01050900 00040000 87000000 Replace by: 01051200 00080000 87000000 ​That's all you should need in terms of HDMI patch afaik, nothing else. That's all I use for my HD4600-based E6440 and I've no problem whatsoever once the patch is installed. I do experience system freeze on HDMI cable plugging otherwise. What version of OS X are you running by the way? You kind of omitted that sort of critical details... For audio, you should also choose between EAPDFix or CodecCommander kexts but not use both... But that's a detail compared to your HDMI issue. You'll also need Rehabman's FakePCIID_Intel_HDMI_Audio kext for HDMI audio. Use the attached revised config.plist if you can't do any of the above: Herve_revised_config.plist.zip NB: you don't need the AsusAICPUPM patch on a Haswell platform, only the kernelPm patch. The former is for Sandy Bridge and Ivy Bridge platforms.

Older Chameleon version look for the older form of Mac OS X kernel as "mach_kernel" at partition root. You can either use Chameleon Wizard to specify the newer location in a much easier way than writing it manually in o.c.B. Alternatively, switch to a more recent version of Chameleon or to Enoch, these will have no issue with the new kernel location and naming convention as "kernel" in /S/L/K.

Clover injects kexts placed in EFI/Clover/kexts/10.xx or EFI/Clover/kexts/Other at startup. It's good for testing. Ideally, once you're happy with your set of add-on kexts, you should move them to /L/E (or eventually /S/L/E if necessary), repair permissions and rebuild your cache, leaving the Clover kexts folder empty. This improves startup time. Deleting kexts randomly is plainly... stupid. If you kept a copy, put the kexts back where they were, then repair permissions and rebuild your cache. Best to avoid Kext Wizard and proceed with kexts installation (or removal) manually. If there are errors (which happens frequently), you won't see them with the old tool. Now I say this, I say nothing...

To get rid of VoodooHDA, simply delete the VoodooHDA + AppleHDADisabler kexts from /S/L/E or /L/E or Clover kexts folder then rebuild your cache and reboot. sudo touch -f /S*/L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U /

Make sure you only have ONE copy of the ALC283 kext, either in /S/L/E or in /L/E (ideally the latter). You've obviously not repaired permissions properly, so use the following Terminal commands: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /S*/L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / If you get an error at the end, retype the touch + kextcache commands. Bear in mind that Clover can only patch kexts that are in the cache, so if AppleHDA has not been cached yet, you'll get no sound. I therefore advise you 1st boot without cache, then repair your permissions and rebuild your cache. You can then expect to have audio working at next reboot.

RTL8111F Ethernet will work with Mieze's Realtek RTL8111 driver; look it up. DW1506 is based on Atheros AR9485; it's unsupported under OS X. You'll have to replace it by a compatible model. Check our non-exhaustive list. Same for Intel HD 2500 graphics: no (full) support under Mavericks and beyond, only in ML apparently. You may obtain Core Image (CI) but you'll never get Quartz Extreme (QE), so it's very similar to the issue of 1st Gen intel HD graphics on laptops with eDP connectors. In other words, it's not worth pursuing unless you opt for one of 2 solutions to this problem: 1) change your CPU for a model with built-in HD4000 (that iGPU is fully supported) 2) insert a supported discrete graphics card (nVidia or AMD); much better solution

For audio, you may try VoodooHDA v2.8.9 or patched AppleHDA for ALC283 codec. For the latter, it's very easy: copy to /L/E the CodecCommander + AppleHDA_ALC283 kexts provided in JakeLo's zipped archive of post #4 copy the on-the-fly AppleHDA patches provided by JakeLo in the Clover config.plist of his zipped archive to your Config.plist repair permissions and rebuild your cache On reboot, you'll have audio.

Do you actually have full graphics acceleration? Or doesn't Skylake graphics require layout-id injection?

You may also check that: 1) USB wake is disabled in BIOS 2) no wake on network access in your Power Savings Pref Pane But most importantly, ensure you have a driver package compatible with OS X El Capitan. Realtek's web site does not list much drivers beyond OS X Mountain Lion 10.8 for 802.11a/b/g/n single-chip devices, so check the dongle's manufacturer's web site. The best solution is to opt for a compatible mini-PCIe or 1/2 mini-PCIe card as suggested by Jake. DW1510 or DW1550 are indeed great hi-speed 802.11n cards. https://osxlatitude.com/index.php?/topic/2120-inventory-of-supported-and-unsupported-wireless-cards/

ALC3246 indeed according to Dell's 3470 specs. Should be ven/dev ids 10ec:0256, i.e. ALC256 codec. For El Capitan, try the following Clover on-the-fly AppleHDA patches + attached kexts: Find: 6102EC10 Replace by: 00000000 Find: 6202EC10 Replace by: 00000000 Find: 8508EC10 Replace by: 00000000 Find: 8319D411 Replace by: 00000000 Find: 8419D411 Replace by: 5602EC10 AppleHDA_ALC256.kext.zip CodecCommander.kext.zip Patch your DSDT HDEF device to inject audio layout 3.

Pike R Alpha's generator script creates a CPU-specific SSDT file to obtain ful native CPU power management and Turbo boost. If you've not done that critical part yet, you've got no proper CPU power management. Hence my questions of August 27th. Furthermore, you may still be using NullCPUPM, in which case, you definitely have no CPU power management at all and that usually prevents Sleep. So, make sure you've: set your SMBIOS profile to MBA5,1 or MBP9,2 generated your CPU-specific SSDT removed NullCPUPowerManagement kext Proceed in that order as the SSDT generator script looks at SMBIOS profile...

You should stick to patching the Yosemite vanilla AppleHDA. I'd never use kexts of a version n+1 on a version n; it's usually the opposite... If using Clover, apply the on-the-fly patch alongside the complementary IDT audio kext which can be placed in /L/E (or /S/L/E) followed by usual permissions repair + cache rebuild. You may also inject it through the EFI/Clover/kexts/10.10 folder but that's obviously not cached and therefore slower. The Latitude E5430 is using same IDT 92HD93 codec as the E6x30 series. As such, you can use the following on-the-fly patch in Clover, alongside the attached IDT kext: Find: 8B19D411 Replace by: 00000000 Find: 8419D411 Replace by: DF761D11 There are 2 x occurences of each binary replacement if you ever wanted to do it manually in the actual vanilla AppleHDA kext binary file. AppleHDA_IDT_92HD93.kext.zip And, if required: Vanilla_AppleHDA_10.10.5.kext.zip The exact same on-the-fly/binary patch and IDT kext are re-usable with EC 10.11 and Sierra 10.12.

Where are you at? You simply copy the Extra folder to the root of your OS X partition...

You need to activate KernelPm in Clover CPU options. CPU power management is managed at kernel level for Haswell CPUs and this requires a patch on Hackintoshes.

With 14years of experience (knowing that hackintoshing began 10years ago when Apple switched to Intel), you should have no problem installing OS X on this Asus and identifying the obvious.

Please make the effort to read the threads I linked above.

Audio codec of E6x30 is IDT 92HD93 (Codec 76DF). It's shown in BIOS info if you want to check.

Try and reset BIOS to default settings, then set HDD mode to AHCI and BIOS mode to Legacy.

For info, the "regular" (if I may call it this way) AppleHDA for E6230 consists of: injection of layout 12 in DSDT loading of IDT codec definition kext (xml.zlib files) binary patching of AppleHDA kext to inject IDT codec id 76DF: find 8B19D411 and replace by 00000000 find 8419D411 and replace by DF761D11

You should asked Wern what his patch consists of... There are mixed reports about his patches.

The best method is based on the Terminal commands. Why? Because, sometimes (often?), cache rebuild fails and returns error messages. You cannot see those outside Terminal mode.

Ouh… lots to cover! Bootloader and kexts: Are you using Enoch or Clover? With Enoch, add-on kexts should go to /L/E/, followed by permissions repair + cache rebuild. That's the preferred folder for best ideal performance and efficiency. Kexts placed in /E/E will be injected at boot time if and only if Enoch boot option KernelBooter_kexts=Yes is used. Clover works in a simile way where it injects kexts placed in EFI/Clover/kexts/10.x or EFI/Clover/kexts/Other I don't know where the kexts you pictured above are placed (I assume /L/E or /E/E) but a few things appear incorrect. Patched (or vanilla) AppleHDA usually only loads from /S/L/E. You list an ApplePS2Controller alongside VoodooPS2Controller + VoodooPS2Mouse. You can only have one or the other, Apple or Voodoo, not both... USB ports: USB ports injection is done through the following summarized methodology: selecting the appropriate SMBIOS profile (should be MacBookpro5,1 for the E6500) renaming of all EHC1/EHC2 references in DSDT table to EH01/EH02 identification of all USB ports in IOReg by plugging a USB key in each individual port and taking a note of it editing the Info.plist file of provided USBInjector kext, where USB ports are defined according to IOReg findings under Mac model EH01/EH02 controllers (Mac mode being set to MacBookPro5,1 here) This has been explained at great length on Rehabman's repo and at InsanelyMac, it's a simple matter of applying what experts on the matter have written some time ago. mergesoft never bothered to reply or return to the thread so we don't know where he/she got after our suggestions and kexts supply… For your info, I recently worked on a Latitude E6400 that I set in close config to my D630: tuned FakeSMC (SMC+AGPM), MBP5,1 profile, USBinjector of D630. All worked perfectly. No reason why the same would not work on E6500... CPU performance: Poor performance with a Core2Duo CPU on Intel 45 Express chipset may result from: Dynamic Acceleration (IDA) being set in BIOS on a laptop fitted with a Merom CPU. It should only be set with a Penryn CPU. Which do you have? incorrect use or tune of FakeSMC kext/SMBIOS profile, resulting in lack of native CPU power management unnecessary use of NullCPUPowerManagement next Absence of P States + C States generation (selectable at boot loader level) This has been explained at great length in exiting articles and threads on this web site/forum. Audio: The Latitude E6500 is fitted with IDT 92HD71B codec. That's what you need to seek in terms of AppleHDA patch. The patched AppleHDA kext must go to /S/L/E and the codec-specific IDT next can go to /S/L/E or /L/E. Failing that, try VoodooHDA (you may need to experience several versions from say v2.7.1 to 2.8.9). Remember to repair permissions and rebuild cache after all kexts handling. Display outputs: With regards to display ports, you may have not noticed it but the DSDT I patched was mergesoft's initial table of E6400 origin. Griftopia's DSDT appears to be of Dell Precision (Mx400?) mobile workstation origin. I had not paid any attention to the GPU part of mergesoft's DSDT. If you compare the 2 files and examine the dGPU definitions under device AGP @00010000, you'll notice 2 things: E6400's table uses name IGPU for both iGPU and dGPU; this is not ideal at all but is not causing trouble and I can easily upload a revised DSDT that will rename the dGPU to GFX0. E6400's table uses different NVCAP settings than the Precision Mxx00's. This is the key to obtain both VGA and DP ports working as NVCAP defines the nVidia GPU output display ports arrangements. You basically need to look up for the correct NVCAP settings that fit to your E6500 system (LCD/LVDS + DP + VGA ?). Refer to the info provided here. If you can' find anything that works, try and remove the NVCAP part of your patched DSDT, reboot and see what's provided in IOReg. Hopefully, IOReg may show the correct values to inject (or not). E6400 NVCAP: "NVCAP", Buffer (0x18) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, /* 0008 */ 0x0E, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, Mxx00 NVCAP: "NVCAP", Buffer (0x14) { /* 0000 */ 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, /* 0008 */ 0x2A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0E, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, ` I'll try and dig out the copy of the E6400 pack I recently helped finalize, hopefully, this can sort you out with your E6500. Note that my work did not include anything related to VGA and DP outputs.

https://en.wikipedia.org/wiki/Extended_Display_Identification_Data http://www.extron.com/company/article.aspx?id=uedid http://www.osx86.net/forums/topic/20664-guide-edid-injection/ https://sourceforge.net/p/cloverefiboot (chameleon, stolen and rebranded)/discussion/1726372/thread/f895ad29/ http://www.hackurmac.com/2014/03/guide-add-your-custom-retina-hidpi.html and so on...

If your laptop is fitted with HD3000 iGPU only and no discrete GPU, try the attached patched table. To test it, keep your existing patched table in place, copy this new patched table to your EFI/Clover/ACPI/patched folder (i.e. next to the existing DSDT) and call this new "DSDT2.aml" table manually at Clover boot time through the menu. DSDT2.aml.zip Modifications done: Renamed integrated GPU device "VID" @00020000 to "IGPU" Injected Capri layout 0x01660003 into device IGPU through _DSM method Removed all _PRW methods declared under Scope (_SB.PCI0.EHC1), Scope (_SB.PCI0.EHC2) and Scope (_SB.PCI0.XHC) Injected new _PRW methods directly under Device (EHC1), Device (EHC2) and Device (XHC) Set _PRW methods of devices GLAN, EHC1, EHC2 and XHC to return (0x0D, Zero) Injected current (power) settings into devices EHC1, EHC2 and XHC through _DSM methods You may also post your existing patched DSDT table for comparison. Can you also advise on your current CPU power management settings, i.e. did you: set your SMBIOS to MacBookPro9,2 or MacBookAir5,2? apply AsusAICPUPM patch in Clover config or patch AICPUPM kext in /S/L/E? generate your CPU-specific power management SSDT with Pike R Alpha's SSDT generator?

Means you probably need to collect your built-in LCD EDID info from, say, Windows and then inject this back into OS X. You can look it up on the Web, there are lots of posts and threads about it. Can't give you a link at the moment, sorry, but I'm sure you'll find something quickly.