Hervé

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.

You can look at my research on the matter in the R&D->Graphics section. It was done for my Haswell laptop but the principles remain the same. You need to identify your DP port through an IOReg browser (IORegistryExplorer, IOJones), then experiment with binary modifications of your relevant layout-id section in the BDW framebuffer.

For the HDMI audio patch, all that's required is to modify the HDMI output connector-type from its default value of 00 04 00 00 to 00 08 00 00. This patch is applicable to all systems whatever the frameBuffer (SNB, Capri, Azul, BDW, etc.) and for all versions of OS X. So, you need to identify the HDMI port line in your particular layout-id of the Broadwell framebuffer (kext BDW FB) and then apply the binary patch; this can be done "on-the-fly" through Clover or through direct binmod of the FB binary file itself.

HDMI audio is handled through AppleHDA (patched for your own codec) + Intel framebuffer (patched BDW FB in your case).

By 2016, everyone who's done a minimum research should know that no Intel wireless card is supported under OS X. It's even mentioned in the FAQ section: https://osxlatitude.com/index.php?/topic/8696-is-my-wireless-card-compatible-with-os-x/ Please use the forum Search facility before posting.

A change to the SMBIOS profile may help, like a little jiggle of the production week n° or year to generate a different serial n°. Assuming the SMBIOS chosen model is right...

The only 10.11.3 you could download would be the Combo update. And that would only install on an earlier 10.11-10.11.2 build. Apple only provides the latest version for installation package download. Oh and, no, 10.11.3 would not work better than 10.11.4+ on that system. Maybe you should make a new installation...

Does it boot if you limit your CPU to 1 core (eg: option cpus=1 in Chameleon/Enoch)?

Means the cache was not rebuilt. Re-type the last 2 commands or use the following alternative command for kextcache: sudo kextcache system-prelinked-kernel