Hervé

Correct.

Hmm, I've made additional tests and, since my dGPU appears turned off at boot time, I tried to turn it on through SSDT or DSDT edits. I've not managed to reach success yet. However, this reminded me that, many moons ago, I had noticed that HWMonitor never displayed any info about GPU at startup, only after wake. Basically, I would get this: At startup and until sleep After wake Now, if you look at the DSDT code for the _WAK method, you'll notice the following section: If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON)) { \_SB.PCI0.PEG0.PEGP.EPON () } If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON)) { \_SB.PCI0.RP05.PEGP.EPON () } } ` To me this code is partially erroneous in the sense that there is no PEGP device under RP05 in any ACPI table, however the discrete GPU is definitely handled by PEGP under PEG0. Check what you get in HWMonitor at startup. If no GPU info appears, I believe your dGPU is off. If it appears, we'll have to find the right code to turn it off. If, like me, your dGPU appears turned on only after wake, apply the following DSDT patch: edit the SSDT table where method EPON is defined and create a new EPOF method (it did not exist in my SSDT-xx table). EPON method only sets ONOF parameter to 1 (true) so you can simply copy/paste the EPON code in a new EPOF method where you set ONOF parameter to 0 (false). in the above DSDT _WAK code, you can then replace the call to EPON by a call to EPOF instead. In the relevant SSDT table, you may notice that the ONOF parameter is used in SGON and SGOF methods that turn the dGPU on or off. although it would appear like the obvious thing to do, removing the above _WAK code is simply ineffective. In a nutshell: in your relevant SSDT-xx table, add this after EPON method: Method (EPOF, 0, Serialized) { Store (Zero, ONOF) Return (Zero) } in your DSDT, change the _WAK code to: If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04))) { If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPOF)) // Replace EPON by EPOF { \_SB.PCI0.PEG0.PEGP.EPOF () // Call to EPOF to turn off dGPU } // Comment out or remove those useless 4 lines below // ------------------------------------------------- // If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON)) // { // \_SB.PCI0.RP05.PEGP.EPON () // } } // <----- Don't remove or comment out that closing bracket! ` I think that should sort you out if dGPU is indeed turned off at startup and only activated after wake. Meantime, I'll keep trying to find the right code to really turn on or off the dGPU at system startup.

Where is your ApplePS2Controller kext? If in /L/E, make sure you repaired the permissions of that folder and rebuilt the cache. I've no issue with the kexts of the pack I published and my D630 runs 10.11.6 without any mods to kexts. If you get an error message at the end of cache rebuild process, just repeat the last 2 commands (touch + kextcache).

This Mavericks guide has the full pack for the E6430 with nVidia NVS 5200M. It also mentions disabling/re-enabling Optimus in BIOS. Additional info here too. The El Capitan installation process is detailed here.

Follow Jake's guide, it's more up to date than Pokenguyen's which was initially for Mavericks..

Audio will only work once you've patched the AppleHDA kext. Is it ALC3226 (ALC292) like on the E6x40? If so, I can give you patched kexts or, if you use Clover, apply the patch command you'll find in the packs posted by Jake in his El Capitan Clover guide for the Latitude / Inspiron laptops. Use Clover Configurator tool to examine Jake's posted config.plist for Clover. FaceTime/iMessage/AppStore require the Ethernet card to be activated and configured as 1st network interface en0. Check that out in Network PrefPane or through Terminal app with ifconfig command. I reckon the LAN card is the same in the E7x40 series as in the E6x40 but, again, Jake's guide offers packs will all the necessary drivers. Sleep should work OOB once you've got CPU power management fully working and eventual DSDT patches.

Your pictures shows a KP on AICPUPM so you need to use NullCPUPowerManagement kext until you activate the AsusAICPUPM patch in Clover config or patch the vanilla AICPUPM kext. If you want to use the nVidia GPU, you 1st need to enable Optimus in BIOS. Then I reckon you'd have to remove the Intel Capri kexts so that OS X makes no attempt to load drivers for the integrated HD4000 graphics. All should be indicated in Jake's guide.

Arf, I forgot one stupid thing! Assuming you already have a file SSDT.aml (for CPU power management settings), the revised SSDT table needs to be renamed SSDT-1.aml for it to be loaded by the bootloader. At least, that's how it works with Chameleon/Enoch: tables are read in the order SSDT / SSDT-1 / SSDT-2 / SSDT-3, etc. I've verified this in verbose mode. If keeping original SSDT-n.aml name (like SSDT-8.aml or SSDT-9.aml): E6440:~ admin$ bdmesg Enoch (2839) ... ... ... [ ACPI PATCHER ] Table /Extra/DSDT.aml read and stored at: 2f57000 ... Table /Extra/SSDT.aml read and stored at: 2f69000 ACPI Table not found: SSDT-1.aml ... DSDT: Old @c8fd31b0,50304943, New @2f57000,50304943 ... TABLE APIC, TABLE FPDT, TABLE LPIT, TABLE SSDT, OEM SSDT tables was dropped TABLE SSDT, OEM SSDT tables was dropped TABLE SSDT, OEM SSDT tables was dropped TABLE SSDT, OEM SSDT tables was dropped TABLE HPET, TABLE SSDT, OEM SSDT tables was dropped TABLE MCFG, TABLE SSDT, OEM SSDT tables was dropped TABLE ASF!, TABLE SSDT, OEM SSDT tables was dropped RSDT: Added 1 SSDT table(s) RSDT: Original checksum 180, New checksum 62 at 2f6c000 ... Added 1 SSDT table(s) into XSDT ... ACPI version 2 patching finished If renaming the revised table to SSDT-1.aml: E6440:~ admin$ bdmesg Enoch (2839) ... ... ... [ ACPI PATCHER ] Table /Extra/DSDT.aml read and stored at: 2f57000 ... Table /Extra/SSDT.aml read and stored at: 2f69000 Table /Extra/SSDT-1.aml read and stored at: 2f6a000 ACPI Table not found: SSDT-2.aml ... DSDT: Old @c8fd31b0,33373330, New @2f57000,33373330 ... TABLE APIC, TABLE FPDT, TABLE LPIT, TABLE SSDT, OEM SSDT tables was dropped TABLE SSDT, OEM SSDT tables was dropped TABLE SSDT, OEM SSDT tables was dropped TABLE SSDT, OEM SSDT tables was dropped TABLE HPET, TABLE SSDT, OEM SSDT tables was dropped TABLE MCFG, TABLE SSDT, OEM SSDT tables was dropped TABLE ASF!, TABLE SSDT, OEM SSDT tables was dropped RSDT: Added 2 SSDT table(s) RSDT: Original checksum 180, New checksum 130 at 2f6e000 ... Added 2 SSDT table(s) into XSDT ... ACPI version 2 patching finished

You can swap OPT and CMD keys through your keyboard PrefPane. It's as simple as that. For Sierra, it's a general issue affecting all systems, not just the E6430 or Dell laptops. It's obviously the result of changes by Apple but Sierra still is in Beta version... There are plenty of posts on keyboard mappings and tuning, please refer to them.

Support capability for OS X simply depends on the specs but I gather that the new V5 version is not based on the same hardware generation as the V2 which was Haswell-based. But I really much doubt that the OP really obtained "dual graphics with acceleration" as he'd be the 1st in the world to have achieved it. He got either or. For OS X installation, refer to existing guides, they all follow the same process, only drivers linked to specific hardware will differ; and ACPI (BIOS) tables of course! Post the hardware specs and you'll get a better answer. As for the battery duration under OS X, well... how long is a piece of string?

SSDT generation is for CPU power management; nothing to do with FaceTime which requires an Ethernet card/interface declared as 1st interface en0. Sometimes the wireless card gets in there 1st and Ethernet is en1. In that case, you need to delete all network interfaces from your Network PrefPane and all plist files from /Library/Preferences/SystemConfiguration. If your CPU is not recognised by the script (because it may not be present in the default tool database), just can try adding the characteristics of your CPU manually with the script optional parameters. All are indicated at Pike R Alpha's repo linked above.

I've done some further testing on my E6440 and I just cannot reproduce your issue at all. I can't even boot OS X if I revert to standard BIOS table and boot without cache and without proper HD4600 injection. I can clearly see that attempts to load Radeon graphics are made but system then hangs and does not complete boot. It does not really matter whether I add _ON or _OFF to the _INI method for SSDT scope SB.PCI0.PEG0.PEGP... Can you make sure that you inject your HD4600 properly? With Mavericks, you simply need to inject Intel Azul FB #12 or Intel-ig 0x0a260006 (with Chameleon/Enoch, this translate into IntelAzulFB=12 and InjectIntel-ig=0600260a). From Yosemite onwards, you need to load Rehabman's FakePCIID + FakePCIID_Intel_HD_Graphics, inject Intel-ig 0x0a260006 and fake desktop HD4600 id 0x0412. Thereafter for me, there is simply no visibility of the Radeon dGPU and not a single mention of it in the boot/system log or in SysProfiler.

Gave it another shot from your raw table... I just: 1) in SSDT-8: added a call to _OFF in Method _INI of \SB.PCI0.PEG0.PEGP 2) in DSDT: removed incorrect external method _SB.PCI0.RP05.PEGP.EPON in definition block at beginning of table (no such method exists) removed calls to _SB.PCI0.PEG0.PEGP.EPON and _SB.PCI0.RP05.PEGP.EPON in method _WAK added a call to _SB.PCI0.PEG0.PEGP._OFF in method _WAK to disable the discrete GPU on Wake added a call to _SB.PCI0.PEG0.PEGP._ON in method _PTS to enable the discrete GPU on Sleep fixed a few classical issues generating errors at compilation (e.g.: rename device "*pnp0c14" to "PNP0C14") No renaming of devices this time, just to do quick tests. Give that a try and let us know. DSDT.aml.zip SSDT-8.aml.zip

What I did was: 1) rename integrated GPU device GFX0 (@0x00020000) to IGPU in DSDT + SSDT-8 + SSDT-9 as per Apple MacBooPro11.x ACPI tables 2) rename discrete GPU device PEG0.PEGP (@00010000) to P0P2.GFX0 in DSDT + SSDT-8 + SSDT-9 as per Apple MacBooPro11.x ACPI tables 3) add external methods declarations for SB.PCI0.P0P2.GFX0._ON and SB.PCI0.P0P2.GFX0._OFF at beginning of DSDT 4) add a Scope SB.PCI0.P0P2.GFX0 in DSDT with an _INI Method that just calls _OFF Method (declared in external table SSDT-9) 5) add calls to SB.PCI0.P0P2.GFX0._OFF in _WAK Method

There's a full pack posted in the guide referenced above by JakeLo. You should be able to re-use most if not all of it. If the EDP bootpack remains missing to date, please refer to post #4.

Output of an "lspci -nn" would be much better...

You should be able to do without EDP if you use the packs posted by JakeLo in the Inspiron / Latitude El Capitan guide.

My last shot at it. Place attached patched tables in your ACPI/patched folder (keep a backup of your existing files of course). Patched_tables.zip

VGA is unsupported on those Haswell HD4600 Hackintoshes. You can only use HDMI, DVI or DP. The thread does stipulate that the patches are my own findings and experimentation. You may have patched the kext incorrectly (it's easy to make a mistake) or your system requires a different patch.

That's because you probably don't have graphics acceleration yet. Try to boot with Chameleon parameter GraphicsEnabler=Yes. In all likelihood, you'll need to inject the nVidia settings through DSDT patching. But we'll need an IOReg extract for that.

HDMI output requires patching of the Azul FB; we've mentioned that several times before. Look up the patch in my E6440 guide or my Haswell graphics experimentation thread for full details. https://osxlatitude.com/index.php?/topic/7387-dell-latitude-e6440-with-i5-4300m-hd4600-and-1600x900-lcd-mavericksyosemite/page-2&do=findComment&comment=48816 https://osxlatitude.com/index.php?/topic/8723-enabling-dvidphdmi-with-intel-hd4200440046005000-and-iris-51005200-gpu/

Try the revised bootpack: added NullCPUPM kext (just in case) added missing flag 32bit kernel mode (oups!) disabled GraphicsEnabler (just in case it causes issues like on the D620/D820 nVidia) To use it, run myHack->create Extra on your USB installer and point to this pack. XPS-M1710-Provisional-Lion-Pack_#3.zip And, for reference, here's your recompiled extracted/raw DSDT table: XPS-M1710_raw_DSDT.zip

Is this a myHack USB installer? If so, please use the following flags when booting: -f -v

'never had any Arrandale laptop...

So you're getting there. Tried vBios patch set to No and Inject Intel set to Yes? Experiment! It's all in the guide. There's even Giofrida's tool for you to test various settings.