Hervé

HD3000 only supports 2 x concurrent displays, not 3. As such, you can get dual external displays if and only if the lid is closed. Once you've applied the appropriate SNB framebuffer patches, all will work. Check these posts: https://osxlatitude.com/index.php?/topic/7914-dell-latitude-e6220-with-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemiteel-capitansierra/&do=findComment&comment=52237 https://osxlatitude.com/index.php?/topic/7914-dell-latitude-e6220-with-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemiteel-capitansierra/&do=findComment&comment=57882 https://osxlatitude.com/index.php?/topic/7914-dell-latitude-e6220-with-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemiteel-capitansierra/&do=findComment&comment=58826 https://osxlatitude.com/index.php?/topic/1969-guide-for-enabling-vga-and-hdmi-in-intel-hd3000-gpu/ If you use this patch for port 0205: 02 05 00 00 00 08 00 00 06 00 00 00 // patched: HDMI/DP display port (built-in/docking port) I expect you'll be able to use the HDMI port or the DP port without further mod. I'll have to verify that, it's been a while since I last played with this...

APFS is very slow on mechanical HDD only. Ok on SSD...

RE: post #24, trying to declare device 413c:8158 compatible with device 413c:8143 through your envisaged code... <key>413c_8143</key> <dict> [....] <key>CFBundleIdentifier</key> <string>com.apple.iokit.BroadcomBluetooth20703USBTransport</string> <key>CFBundleIdentifier - 2</key> <string>com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport</string> <key>IOClass</key> <string>BroadcomBluetooth20703USBTransport</string> <key>IOClass - 2</key> <string>BroadcomBluetoothHostControllerUSBTransport</string> <key>IOProviderClass</key> <string>IOUSBHostDevice</string> <key>IOProviderClass - 2</key> <string>IOUSBHostInterface</string> [...] <key>idProduct</key> <integer>33091</integer> <key>idVendor</key> <integer>16700</integer> <key>Compatible-idProduct</key> <integer>16868</integer> <key>Compatible-idVendor</key> <integer>17201</integer> [...] </dict> ... well, hmm... would be quite exotic and -of course- completely, how to say this?, wacky! Did just simply make that up? Kexts and kexts patching are no cocktails in which you add/mix ingredients and then shake, you know. So, no that would not be the way to go. Why? Well, because: the way it's written, it would attempt to declare device 413c:8143 (i.e. DW1550 BT module) compatible with device 413c:8158, i.e. the other way around. it would try to refer to 2 x separate kexts (BroadcomBluetooth20703USBTransport + BroadcomBluetoothHostControllerUSBTransport) it would try to declare multiple same parameters in series (CFBundleIdentifier & -2, IOClass & -2, IOProviderClass & -2) it would try to declare invented parameters (Compatible-idVendor and Compatible-idProduct) What you need to do to inject your device was explained several years ago in post #4 of this thread or here in my E6220 guide. As it happens, you already have all the necessary information to do this. The patch does not even have to be made to the Bluetooth transport kext itself but can be injected in FakeSMC in the same fashion tat was described here for AGPM tuning for instance. If your module is a BCM2070x device, you may need to apply Rehabman's firmware patches too, though I did not see yours in there list. But it's quite an old device after all...

Your grep command filters for a kext containing "Fake" in its name... Is it the case for the names of the PlugIns? PlugIns are kexts just like any other driver. You should see them loaded (or not) in your SysProfiler->Software->Extensions section. But rest assured that they are loaded or HWMonitor would not show the info it currently does. If you see no GPU entry in the T° section of HWMonitor at any time, even after waking the laptop, it's pretty safe to say your nVidia dGPU is fully disabled; permanently.

First of all, check whether it's seen in IOReg with IORegistryExplorer. If it is, it should normally just be a matter of injecting the correct device id in the accelerator kext AMDRadeonX3000 kext ff it's missing there and calling on the correct ATI/AMD frame buffer (should be one of the AMD5000Controller family). Can all be done through Clover Configurator if you run Clover. You'll need to set "Inject ATI" of course.

You can use HWMonitor app (calls on FakeSMC Plugins) to verify if nVidia GPU remains turned off after wake from sleep. In SSDT-12, it's most definitely turned off at startup through the _INI method of device SB.PCI0.RP05.PEGP: Method (_INI, 0, NotSerialized) // _INI: Initialize { Store (Zero, \_SB.PCI0.RP05.PEGP._ADR) _OFF () } I've not seen calls to turn it On or Off after wake in the DSDT.

Check the IOGraphicsFamily patch in Clover's config file with CloverConfigurator tool, section Kernel & Kext Patches. It should be: Find: 01007525 Replace by: 010000EB25 and your config file may have the patch details of a previous OS X version in place.

There's a good chance your system returned to default hibernation mode #3. Check this with pmset -g Terminal command, then follow the FAQ tuto on disabling hibernation. Unless you set laptop to support hibernation with Clover, you need to revert to plain old sleep mode. https://osxlatitude.com/index.php?/forum/161-faqs-tutorials/

Either you remove the patch you made or you re-install a backup you took.

It's disabled, so you can clearly remove it... But that will not make any difference.

HD4000 ??? You're very mistaken. That's Ivy Bridge integrated graphics... You stated it yourself: you have HD4400 graphics, i.e. one of Intel's Haswell iGPU. You're meant to use Azul Layout #12 (layout-id 0x0a260006) and fake desktop HD4600 is 0412.

Those issues and limitations are already clearly posted on Chunnann's original thread at InsanelyMac (see from post #21); let's not unnecessarily duplicate info here, it's best to report issues to Chunnann directly in at IM. The above facility is a mere adaptation of Chunnann's work posted here. For the record, only AR946x cards appear to run at decent speeds to date. NB: Re: macOS versions, you obviously meant 10.13 and 10.12 (not 10.3 and 10.2)

No fix to date.

You should look at the E6540_Optimus pack in that case. The pack posted for the E5440 is for Intel graphics only.

Check the FAQ section re: supported wireless cards.

Waterwolf, it's be useful (for you) if you would read the existing guides for that laptop model, where absolutely everything is detailed and available. Really everything. Your Clover configuration is a bit messy: You have no compiled SSDT table for your CPU in the ACPI/patched folder, only a source text file... As such, do not expect to have any proper CPU power management at all. If you read Pike R Alpha's blog, you should be able to generate the table properly, especially as the script does ask you all the right questions... Your Clover config.plist points specifically to several ssdt files that do not exist! ssdt.aml + ssdt-0.aml + ssdt-1.aml + ssdt2.aml. Your Clover config.plist has unnecessary options selected in its Boot section, but never mind, they don't do any harm. In the Kernel & Kext Patches section, you can remove the KernelPm patch, it's useless on Sandy/IvyBridge; you only need the AppleIntelCPUPM patch. You can keep the AppleRTC patch if you want of course. You have the correct IDT 92HD93 AppleHDA patches in the Kernel & Kext Patches (as confirmed by JakeLo); consequently, I cannot understand your post #24; late night mistake probably... Your kexts folder is quite wrong; for instance, you've copied the FakePCIID_XHCIMux kext but missed the parent kext FakePCIID without which the former will simply not work. For some obscure reasons, you've posted that you've installed VoodooSDHC kext. This is a big mistake for at least 2 reasons: it causes issues with sleep & wake your DSDT already has the patch to make the O2 card reader work OOB (though the injected info differs a bit from the patch we usually apply) So, if you want your E6230 to work well, the 1st thing to do is to generate the compiled SSDT table for CPU Power Management and adjust your Clover config.plist accordingly (Drop DMAR + SSDT CPUPm + SSDT CPU01st and remove those useless SSDT entries in Sorted Order). Wrong: Correct: If the SD card reader does not work OOB, adjust the patch in the DSDT from this: Return (Package (0x08) { "compatible", Buffer (0x0D) { "pci14e4,16bc" }, "name", Buffer (0x0D) { "pci14e4,16bc" }, "model", Buffer (0x18) { "O2 Micro SD Card Reader" }, "IOName", "pci14e4,16bc" }) to this: Return (Package () { "compatible", Buffer (0x0D) { "pci14e4,16bc" }, "model", Buffer (0x18) { "O2 Micro SD Card Reader" } }) as described in the reference thread on the matter posted here. If you wish to follow proper and validated E6230 guides, please refer to one of these 2: https://osxlatitude.com/index.php?/topic/8883-dell-latitude-e6230-with-i5-3340m-hd4000-and-1366x768-lcd-mavericksyosemiteel-capitansierra/&do=findComment&comment=64491 https://osxlatitude.com/index.php?/topic/8506-dell-latitude-inspiron-precision-clover-guide/

Not much to expect from those cards. They still only operate at very limited speeds under OS X/macOS and the drivers do not seem to work well under High Sierra so far... It's all reported in Chunnann's thread at InsanelyMac: http://www.insanelymac.com/forum/topic/312045-atheros-wireless-driver-os-x-101112-for-unsupported-cards/ http://www.insanelymac.com/forum/topic/312045-atheros-wireless-driver-os-x-101112-for-unsupported-cards/page-21?do=findComment&comment=2509900 It's best to replace them with other cards that are fully supported.

In the end, I never managed to sort out the graphics issue with Chameleon or Enoch. Instead, Clover does support full graphics with the following options: Inject EDID Load VBIOS Inject ATI ATI framebuffer Orangutan The ATI AMDRadeonX3000 accelerator kext must also be patched as detailed above in post #2 in order to inject Radeon HD 5430 id 1002:68E1. config.plist.zip

20s is about the best one can get. If you want to enable trim, please note that there is no real need for a patch since Apple introduced a command to enable it as of Yosemite 10.10.4: sudo trimforce enable

Why don't you post a zipped copy of your EFI folder? Things to look at: list of injected kexts SMBIOS and FF/FFM in Config.plist ACPI patches in Config.plist

Ok, these are good. So if you look into your IOREG, we see that your AR5B195 card (168c,2b) is attached to PCIe device PXSX, itself under RP04. This is the device to look for in the DSDT for patching. To patch the device, simply insert the DSM method into the device as follows: Device (PXSX) { Name (_ADR, Zero) // _ADR: Address Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake { Return (GPRW (0x69, 0x04)) } Method (_DSM, 4, NotSerialized) // Device Specific Method for the wireless card { Store (Package () { "model", Buffer (0x1E) { "Atheros AR5B195 b/g/n Wireless" }, "device_type", Buffer (0x08) { "AirPort" }, "built-in", Buffer (One) { 0x00 }, "name", Buffer (0x10) { "AirPort Extreme" }, "AAPL,slot-name", Buffer (0x09) { "Internal" }, "compatible", // Declares compatibility with a device Buffer (0x0B) { "pci168c,30" // PCI id of device supported OOB } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } Recompile the DSDT and save the resulting DSDT.aml file for re-use. Please note that the "compatible" statement is what's really required here, the rest is purely cosmetic for the SysProfiler information. I attach the patched table where I also renamed RP04.PXSX to RP04.ARPT. Remember to re-instate the vanilla Atheros kext! Repatched_DSDT.aml.zip

I don't know about that app. If you want me to patch your DSDT, post: a zipped copy of your DSDT a zipped output of IORegistryExplorer

Just how do you patch the Atheros kext? As posted and detailed here, the AR5B95/AR9285 DSDT patch is much simpler and will not require any subsequent kext patching, whether at new OS installation or after updates. If you prefer, the Info.plist kext patch can also be implemented through Clover. Personally, I prefer the DSDT one.

Everytime you update High Sierra, you need to reboot the "install macOS HighSierra from..." partition to complete the update. I've seen this across the board.

Sinetek's driver is worth trying apparently: http://www.insanelymac.com/forum/topic/321080-sineteks-driver-for-realtek-rtsx-sdhc-card-readers/page-1