Hervé

Unless you have a DSDT that was repatched off BIOS A22, expect to experience garbled graphics on screen. To avoid this, maximum BIOS version is A12. To revert to that BIOS version, 1st downgrade to tjhe lowest possible version available on Dell's web site, then upgrade to A12. You'll find full installation details in this guide: The HD4000 Capri layout to use depends on your built-in LCD resolution. Inject layout-id 0x01660004 for resolution GTE 1600x900, otherwise use 0x01660003 for lower resolutions such as 1366x768. All your USB ports will workj as long as you: 1) rename EHCx devices to EH0x 2) inject/install a USB injector kext (Rehabman's USBInjectAll highly recommended) 3) use the appropriate SMBIOS (MBP9,x)

Core2Duo CPU is not an issue in itself as long as it's a Penryn model. The issues at hand are: SMBIOS profiles such as MBP7,1 (anything older than a 2012 model is natively unsupported) Vanilla telemetry plugin triggers KP on C2D platforms GPU support (no native support for non-Metal GPUs) Dosdude1's patcher normally takes car of this: it patched the PlatformSupport plist to inject some of those natively unsupported models (eg: MBP7,1, MBP8,x, etc.) it replace the telemetry plugin by a previous version from High Sierra As for GPU support, older nVidia GPUs can be supported by installing nVidia kexts from a previous macOS version such as High Sierra 10.13.6 See details re: D630 in my Mojave beta thread here.

Look at the HD4600 guide available in R&D->Graphics forum sub-section

Irrelevant.

Boot in verbose mode to see when the delay is.

Try it; you won't break anything.

No, it's because Mojave installation app is different than that of previous macOS versions. Use the createinstallmedia command.

Added TP-Link Archer T9E (600/1300Mbps) 802.11a/b/g/n/ac 2.4/5GHz desktop PCIe x1 card.

Support for Atheros cards was indeed dropped in Mojave and the Atheros40 PlugIn kext is no longer provided inside IO80211Family kext. If installing a copy of the Atheros kext from a previous macOS version such as High Sierra does provide support under Mojave, note that the simple DSDT patch provided in our inventory will also bring native support for AR9285-based wireless cards without additional kexts.

There's been very little to no support for VGA since Ivy Bridge generation. You can look up the various patching guides posted in the Graphics R&D section for guidance on how to patch your particular SKL framebuffer layout. The principles remain the same since 4th gen Haswell graphics.

Mojave is installed using the same process used for High Sierra.

@Amoxitine, I'd go back to your initial settings and discuss with @jpz4085 the DSDT debugging patches you need to apply in order to identify the codes associated to your Fn-UP/Fn-DOWN keystrokes.

Yes, that part of getting XCPM to work...

I can't see how battery charging time would be OS related. More likely BIOs settings or low-wattage charger, hence long charging time. Re: microphone, what does your audio PrefPane show? Do you see movement in the input level bar if you make some noise around the mike?

You either need to generate your CPU specific power management SSDT or try XCPM. No Turbo boost on that i3 CPU, but you should see frequency fluctuate between 800MHz and 3.4GHz, without necessarily getting all intermediate frequencies of course.

You don't need to recompile any other table, no. Those ACPI tables will beloaded at boot time without any further action.

None whatsoever.

For those who need an extracted copy of Mojave kernels, here are copies of the various kernels that have come out so far. I also include copies of the patched AppleIntelCPUPowerManagement kexts that are necessary on SandyBridge/IvyBridge CPUs. Patches courtesy of Pimentel and his tools as published at IM. Vanilla kernels for Core2Duo/Core2Quad, Arrandale and Sandy/Ivy Bridge CPUs: Vanilla_kernel_10.14.zip (18.0.0) Patched kernels for Haswell, Broadwell, Skylake CPUs: N/A (Clover and Enoch can patch the vanilla kernel on the fly) Patched AppleIntelCPUPowerManagement kexts for Sandy/Ivy Bridge CPUs: Patched_AICPUPM_10.14.zip NB: kernels go to /System/Library/Kernels as kernel; patched AICPUPM kext goes to /System/Library/Extensions

I guess that the key codes probably differ from one laptop to another. You'd need to apply Rehabman's debugging patch in order to identify the codes returned by Fn-UP/Fn-DOWN keystrokes and amend jpz4085's BRT6 patch accordingly. Not done it yet on my E6220/E6440 to verify.

If you read our forum rules, you'll notice that references to those tools and their originating place are not desired, hence filtered out. We do not support those tools either, they have their own web site and forum.

The IO addresses for laptops' GPUs are actually standard across the board; it's not just a Dell thing, it's the same for all computers, including Apple's own MacBooks iGPU -> @0x00020000 dGPU -> @0x00010000

I've been playing a little more on the multiple external displays arrangement and modified the Azul FB patch for dual DVI outputs: I can then hook 2 x DVI screens off an E-Port Plus/PRO2X docking station (the wide model with 2 x DVI + 2 x DP ports): However, initially, I reproduced the DVI black screen issue I experienced at home when attaching DVI + HDMI displays to my E6440: The screen that went black was the 19" Dell 1908WFP attached to DVI output #1. @1440x900, it's got a lower max. resolution than the 21,5" Full HD Dell P2211H @1920x1080 attached to DVI output #2. So I thought the issue could be related to resolution. After various adjustments, I found that, in order to obtain video output on both external displays, the larger screen must not be set to a resolution higher than the highest of the smaller screen. Otherwise the screen with lowest capacity goes black or displays snow. But I cannot select just any lower res, some remain incompatible with the smaller screen! I could therefore settle for resolutions both screens had in common such as @1360x768/@1280x960/@1024x768 or set the smaller screen to its max. res. @1440x900 and the larger screen @1360x768: It would also appear that combinations and/or ratios of resolutions applied to the screens may impact video output. For instance, if both screens are set to 1360x768 which is 16:9, I can set the small screen to 1440x900 which is 16:10 and retain full video outputs. I can then set the large screen to 1280x960 which is 4:3 without any impact. If I further reduce the large screen to 1024x768 which is still 4:3, small screen goes black. If I then set the large screen to 1280x1024, I get snow on the small screen. This snow will remain when I return the large screen to resolutions that previously work. If I then set both screens to 1360x768, video output resumes on both screens and I can then set the large one to 1280x1024 without any loss of video! Can't make that one out but it could be matter of adjusting DVMT pre-allocated memory in BIOS (default=32MB)... NB: If I swap DVI outputs and place the large screen on DVI #1 and the small screen on DVI #2, it's the large screen that goes black.

Vanilla AppleHDA + AppleALC + correct layout injection either in DSDT or in Clover config. Install AppleALC kext in /L/E to cache it.

Rebuild the cache.

Post your debug info for people to have a look at your issue. You should also add your system's specs in your signature like most people do.