Hervé

Correct me if I'm wrong or aren't all your above ids incorrect? Desktop HD4600 is vendor 8086 (Intel) -not 8085- and device 0412. As such, I believe the IntelGFX parameter should have been set to 0x04128086. No Azul FB kext patching would normally be required to get QE/CI unless the default ports do not support/match your rig of course (but I'd be surprised).

Maybe an EDID issue then... What happens when you put laptop to sleep then wake it? Did you try HDMI output? Regarding the SNB FB, it's probably injected in the DSDT. Post a zipped version and I'll double check or open up your DSDT and look at the _DSM Method of IGPU device defined at address 0x00020000. What you're after is a little piece of code that specifies a 4byte layout-id and it should look like this: "AAPL,snb-platform-id", Buffer (0x04) { 0x00, 0x00, 0x01, 0x00 }, More details at: http://www.rampagedev.com/?page_id=200&page=3

You did not specify your exact CPU model (other than i5), so I assume it's a Sandy Bridge model (i.e. i5-2xxxx) since you mentionned Intel HD3000 graphics. Sandy/Ivy Bridge platforms do not require KernelPm parameter (but setting it won't do any harm). Only AsusAICPUPM is required to avoid KP at startup. Unless you have a discrete nVidia GPU fitted to that Samsung, you should remove the parameter nv_disable=1 (not required on systems with iGPU only) You should set GraphicsEnabler to Yes (to auto-detect the iGPU) Do you inject the SNB framebuffer layout-id through DSDT? If not, you can inject it via Clover. Be careful not to re-use, as is, files/bootpack from the NP 900X3C/4C (for instance the DSDT) as these are IvyBridge-based and therefore a later generation than yours (different CPU and chipset family, different iGPU, different audio codec, etc.). Only some hardware accessories may be identical (like SD card reader, LAN card, etc.) and kexts would indeed be re-usable, but you have to check first.

Please do, I'm sure that can be of interest to other people. Post your zipped EFI folder with patched DSDT, Clover Config.plist and add-on kexts.

'could also be a side effect of an incorrectly decompiled DSDT table. Rehabman's always recommends to decompile with iasl line command and recompile with MacIASL. Version RM-1.31 (RM252.2) preferred and works always perfectly. Post your file(s) so we can have a look.

What resolution is your screen. You may need to add DualLink to your boot loader config if LCD is Greater or Equal to 1600x900.

No problem running Sierra on that rig. Same installation & tuning process as for El Capitan.

Dell systems are not subject to whitelisting.

I got hold of that old PC again so took another chance at sorting out the graphics. Radeon HD 5430 is handled through the following ATI/AMD controller and accelerator kexts under Mavericks: AMD5000Controller AMDRadeonX3000 The controller kext already contains the PCI id for the Radeon HD 5430 (1002:68e1) but not the accelerator. In order for the latter to load for the card, it is necessary to patch its Info.plist file to replace PCI id 1002:68e0 by 1002:68e1 under the AMDCedarGraphicsAccelerator personality, i.e. Before: <key>AMDCedarGraphicsAccelerator</key><dict> [...] <key>IOPCIMatch</key> <string>0x68E01002</string> [...] </dict> After: <key>AMDCedarGraphicsAccelerator</key><dict> [...] <key>IOPCIMatch</key> <string>0x68E11002</string> [...] </dict> ` Thereafter, one of the AMD5000Controller personalities can be called to try and reach full graphics acceleration. These are: Douc / Langur / Uakari / Zonalis / Alouatta / Hoolock / Vervet / Baboon / Eulemur / Galago / Colobus / Mangabey /Nomascus / Orangutan I won't go into explaining how ATI/AMD graphics works (because I don't master this) but AMD controller personalities basically define various models or profiles of graphics arrangements in terms of connector-type. I guess it's somehow similar to layout-ids of Intel HD iGPUs. There are excellent threads on the matter at InsanelyMac. These personalities contains a variable number of connector-type and the connector-type settings vary according to the personality. This HP G72 is fitted with 3 video outputs: built-in LCD (LVDS), VGA and HDMI. The target is therefore a personality with 3 x connectors. Decoding the AMD5000Controller kext using bcc9 tools reveals 4 x personalities with 3 x connectors: Personality: Baboon ConnectorInfo count in decimal: 3 Disk offset in decimal 1447248 0000000 04 00 00 00 14 00 00 00 00 01 00 00 01 02 01 03 0000010 00 08 00 00 00 02 00 00 00 71 00 00 22 05 02 01 0000020 10 00 00 00 10 00 00 00 00 01 00 00 00 10 00 02 0000030 Personality: Eulemur ConnectorInfo count in decimal: 3 Disk offset in decimal 1447296 0000000 04 00 00 00 14 00 00 00 00 01 00 00 01 02 01 04 0000010 00 08 00 00 00 02 00 00 00 71 00 00 12 04 04 02 0000020 10 00 00 00 10 00 00 00 00 00 00 00 00 10 00 01 0000030 Personality: Hoolock ConnectorInfo count in decimal: 3 Disk offset in decimal 1447136 0000000 00 04 00 00 04 06 00 00 00 01 00 00 21 03 05 01 0000010 00 04 00 00 04 06 00 00 00 01 00 00 11 02 04 02 0000020 04 00 00 00 14 02 00 00 00 01 00 00 02 04 01 03 0000030 Personality: Langur ConnectorInfo count in decimal: 3 Disk offset in decimal 1446864 0000000 00 04 00 00 04 06 00 00 00 01 00 00 21 03 04 02 0000010 00 04 00 00 04 06 00 00 00 01 00 00 11 02 01 01 0000020 04 00 00 00 14 02 00 00 00 01 00 00 02 04 05 03 0000030 ` Calling on any of those personalities and injecting LCD screen EDID does not bring life to the built-in LCD, nor graphics acceleration and access via ScreenSharing remained the only way to access the system. However, I noticed that if I plugged a screen to the HDMI port, I obtained graphics acceleration within ScreenSharing (despite a black screen too on HDMI display) I therefore started to look at patching one of the AMD5000Controller personalities. I picked up Eulemur and, using the IM threads/guides here and/or here as a reference, I extracted the AMD ROM, decoded the video ports info (LVDS: 10 00 01 07, HDMI: 21 03 02 01, VGA: 00 10 03 08) and patched the personality as follows: Before: 04 00 00 00 14 00 00 00 00 01 00 00 01 02 01 04 -> DVI 00 08 00 00 00 02 00 00 00 71 00 00 12 04 04 02 -> HDMI 10 00 00 00 10 00 00 00 00 00 00 00 00 10 00 01 -> VGA After: 02 00 00 00 40 00 00 00 08 01 00 00 10 00 01 07 -> LVDS or 02 00 00 00 40 00 00 00 09 00 00 00 10 00 01 07 -> LVDS 00 08 00 00 00 02 00 00 00 01 00 00 21 03 02 01 -> HDMI 10 00 00 00 10 00 00 00 00 01 00 00 00 10 03 08 -> VGA All I managed to obtained was good video output off the HDMI port (no black screen) with full graphics acceleration. Nothing on built-in LCD and nothing on VGA, both remaining dark with undetected display. Could try patching the other 3-port personalities but this remains an unfinished business...

I do not trust kext utility to rebuild the cache. Sometimes, rebuilding the cache fails and I doubt kext utility reports it. USB may not be fully functional because you need to tune your system for that under El Capitan... You gotta do things to the full and properly... How did you complete the CPU & GPU tuning? -> PM...

Neither mein General! It's long been recommended to keep /S/L/E as vanilla as possible. Kexts place in your Clover EFI/CLOVER/kexts/10.xx folder are not cached, only injected. That means slower boot time. I recommend you copy your add-on kexts to /L/E then repair permissions and rebuild cache. That's the optimal setup. From Terminal, enter the following line commands to repair perm + rebuild cache: sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / -

I you have not done so, apply the FakeSMC & AGPM performance tuning. https://osxlatitude.com/index.php?/topic/2673-performance-tuning-with-fakesmc/ https://osxlatitude.com/index.php?/topic/7807-nvidia-gpu-performance-tuning-with-agpm/

Copy the package (~47Mo) found inside the mounted dmg on your desktop before you run it. Then ONLY select the IDT 79B2 patched AppleHDA, nothing else and make sure to have the vanilla AppleHDA in /S/L/E to begin with.

Well the poster of the kexts indicated that he did not test the kexts of his update! You should tell him it's not working... This being said, Yosemite and El Capitan will have audio perfectly working with an earlier patched AppleHDA. Look up the various E6400/E6500 threads of the forum for a copy or look for details of the patch and apply to your vanilla kext. What codec does BIOS or DCPIManager show? PokenGuyen's HVT tool has a patch for E6400's IDT codec 76B2. It's a simple matter of applying the patch (and only that). It'll patch your vanilla AppleHDA placed in /S/L/E (keep a backup somewhere safe beforehand). It works fine with Yosemite and should still work fine with EC. If not, you should be safe to re-use the patched Yosemite AppleHDA kext in EC.

According to Dell, audio controller is Realtek ALC3246 4ch HDA, i.e. codec ALC256. http://www.dell.com/support/manuals/us/en/19/latitude-13-7370-laptop/Latitude7370_OM/Audio-specifications?guid=GUID-86CA96C0-DE85-4BC6-81D0-424907F9A6D3&lang=en-us

Can you post your specs? Is this the model with nVidia GPU or integrated Intel graphics? What do you mean by "newest AppleHDA"? You should only use a patched kext of same or lower version than the vanilla kext of your installed OS X version. Don't go install the kext from El Capitan in Yosemite for instance. 1st ensure you run the latest Yosemite or El Capitan versions (with all version updates, including Security ones), then patch the AppleHDA kext or replace your vanilla kext by a pre-patched one.

Please READ my previous answer.

Integrated graphics of Optiplex 745 is GMA3000 and that's totally unsupported under OS X. With a 10s Google search, you'd get this: https://www.dell.com/downloads/global/products/optix/en/opti_745techspecs.pdf You have no choice but add a supported PCIe x16 graphics card if you want to run OS X on that type of desktop computer. That rules out Ultra Small Form Factor model. The Yosemite pack should be the same as the Mavericks one. If it runs Mavericks, it'll also run Yosemite and El Capitan. Sierra will not run on that E6400 CPU, it needs a SSE4-capable model. There are plenty of threads related to the Optiplex 745 in the Dell->Desktop section of the forum.

So you're talking about CPU utilisation, not CPU speed, right? What does your Activity Monitor show? did you install something that could always run in the background and grab CPU ? Which OS X version are you running by the way?

What is it you're after exactly? If you don't want your CPU to run without Turbo modes (i.e. slower) when laptop is on battery, remove the Turbo disabler kext, then rebuild your cache. For the rest, I assume that you've generated your own CPU-specific SSDT using the well-known SSDT generator from Pike R Alpha and that your system runs with proper CPU power management/speedstep.

Make sure you disable SIP and use this PS2 controller or this one.

Finally got round to implement the HPET fix in DSDT to avoid loss of USB functionality rather than systematically remove the HPET kext. It's a simple matter of removing the IRQs as detailed by Slice (and others) for instance: Before: Device (HPET) { [...] Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0F) }) [...] After: Device (HPET) { [...] Name (BUF0, ResourceTemplate () { IRQNoFlags () // Excludes IRQs 0, 8 and 11 to prevent loss of USB ports {0,8,11} Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0F) }) [...]

Are you running with the Turbo disabler kext?

Seems you're booting the recovery partition... Maybe you need to rebuild your USB installer.

There never was any fix to the black screen issue, if waking the screen from screen sleep. The only workaround is to put the laptop to sleep and wake it. As such, it's best to configure the same timing for Display Sleep and Computer Sleep in the Energy Savings PrefPane. The system password was a requirement for GMA950 systems and does not apply to nVidia models. The D620 NV does not normally have an issue of KP on wake. Mine certainly does not.