Hervé

I guess you can look into the thread about the 7480 with TB16 posted in this very section.

Are you sure your BT module has dev id 8158? Because in post #17, you stated dev id 8156? Why don't you double check in IOReg, hmm? Better, post a zipped saved output from IORegistryExplorer, I'll do it myself.

You still didn't manage to get it right, so here's a Clover config file that you work... config.plist.zip To be able to read hardware info such as T°, your need FakeSMC's PlugIns. FakeSMC is obviously already installed (notably in your kexts folder, doh!) or you would not even be able to boot your Hackintosh. If your card reader already worked, then I understand even less why you would have attempted to load VoodooSDHC kext. Anyway, never mind. The boot artefacts patch (for Sierra) is already installed in Clover config file. I guess you have to make sure you're properly rebuilt your cache (see FAQ section for details). Regarding the on-board Bluetooth, this is a new issue, so you'll have to post a zipped IOReg (saved output from IORegistryExplorer will do) for us to check what's installed. If it's Dell's own DW380, my E6230 guide states what's required to get it working: patch the Broadcom transport kext to inject DW380's id; you may also add Rehabman's firmware patching kexts but not mandatory. BT will have limited functionalities though; don't expect AirDrop or Handoff to work.

You probably need to look into the manner in which the extra USB ports of the TB15 are handled. Check that out with IORegistryExplorer and a USB key that you'll plug ins & out of each port. May be you'll have to use the patch that removes USB ports limitation (in number) or something like that. Are you using a USB injector?

Try MacBookPro11,1 SMBIOS instead of MBA6,2. VRAM is not an issue, never has been on Haswell iGPUs.

For what's it's worth, no actual audio output on my E6440 if I reboot into OS X/macOS from Windows; all looks Ok but just no audio at all. If I shutdown the laptop and perform a cold boot, all is Ok.

Well, may be it's not supported in modern versions of macOS.

Sorted with following SNB patch: 01 02 04 00 10 07 00 00 10 07 00 00 // vanilla: nb of connectors -> "04" 05 03 00 00 02 00 00 00 30 00 00 00 // vanilla: laptop's own LCD display 02 05 00 00 00 08 00 00 05 00 00 00 // patched: HDMI, display port #5 (built-in port) 03 04 00 00 00 04 00 00 06 00 00 00 // patched: DP, display port #6 (docking-station port) 04 06 00 00 00 04 00 00 07 00 00 00 // patched: DVI, display port #7 (docking-station port)

Further to additional tests with forum member MikeGiff, the following SNB framebuffer patch supports direct DP output (tested out of docking station to DP screen): 03 04 00 00 00 04 00 00 06 00 00 00 The tests were validated with combinations of dual-screens setups: built-in LCD + DP built-in LCD + DVI DVI + DP 01 02 04 00 10 07 00 00 10 07 00 00 // vanilla: nb of connectors -> "04" 05 03 00 00 02 00 00 00 30 00 00 00 // vanilla: laptop's own LCD display 02 05 00 00 00 08 00 00 05 00 00 00 // patched: HDMI, display port #5 (built-in port) 03 04 00 00 00 04 00 00 06 00 00 00 // patched: DP, display port #6 (docking-station port) 04 06 00 00 00 04 00 00 07 00 00 00 // patched: DVI, display port #7 (docking-station port)

You'll have to find the correct settings for the Radeon HD5450 then. At least, it's properly detected so it should work. Oh, I think I know where you got your stuff from... http://www.insanelymac.com/forum/topic/312656-guide-macos-sierra-1012-dell-optiplex-780-760-755-790/

Try this one instead: config.plist.zip If it does not work, use latest Clover Configurator v4.55 to edit the config file and try the various AMD5000Controller offered. Remember to save the config file after each change.

Try this DSDT. DSDT.aml.zip Basically, I've moved the GFX0 device that was injected/declared under PCI0.PEG0 (i.e. a PCIe slot) to PCI0.CPI4, i.e. the PCI slot under which the card registers in IOReg. Let me know how it goes. Try the different AMD5000Controller FBs as/if required. Don't hesitate to post a zipped/compressed copy of your EFI Clover folder too so that we can check the Clover config too.

I don't think you read anything past my initial questions on X3000 accelerator kext in my previous answer.

Your IOReg screenshot shows exactly what you had to look for; so the card is seen and that's good news. You said you tried all the framebuffer settings but what about the card id in the accelerator kext? Was it already there? It not, did you add it? The thing is your DSDT contains what appears to be a valid patch for an HD5450 card and the patch fakes dev id 1002:68E0, i.e is the default one supported by the accelerator kext as shown below (extract of 10.13's X3000 accelerator kext): <key>AMDCedarGraphicsAccelerator</key> <dict> <key>ATIEnableWideBlitSupport</key> <true/> <key>ATIUseTearingWideBlit</key> <false/> <key>CFBundleIdentifier</key> <string>com.apple.kext.AMDRadeonX3000</string> <key>GpuDebugPolicy</key> <integer>0</integer> <key>IOClass</key> <string>AMDCedarGraphicsAccelerator</string> <key>IODVDBundleName</key> <string>AMDRadeonVADriver</string> <key>IOKitDebug</key> <integer>0</integer> <key>IOMatchCategory</key> <string>IOAccelerator</string> <key>IOPCIMatch</key> <string>0x68E01002</string> <key>IOProbeScore</key> <integer>200</integer> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>IOSourceVersion</key> <string>0.0.0.0.0</string> <key>IOVARendererID</key> <integer>16908288</integer> </dict> ` However, the DSDT patch is inserted in device PCI0.PEG0.GFX0. This can only work if it matches your IOReg device and I've got a feeling it does not... Save the output of IORegistryExplorer, zip it and attach it here so that we can check things out and adjust the DSDT patch if necessary. By the way, which version of OS X/macOS are you running?

It's because you inject those through the Clover EFI folder, not cache them through /L/E (or /S/L/E) which is better... This being said, there's nothing to worry about.

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.