Hervé

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.

I don't know if it'll help but I remember that Howoarang got his M4800black screen issue in Sierra resolved by switching SMBIOS from MBP11,1 to iMac14,2: You could try that and if it works, opt for a bastardized MPB11,2 SMBIOS where you'll keep the MBP11,2 parameters except the board-id that you'll replace with that of iMac14,2.

No (official) support for VGA since Ivy Bridge HD4000. Last Intel iGPU that supported VGA with framebuffer patching was Sandy Bridge HD3000. There is no patch that brings VGA support on Haswell iGPUs. This being said, I've heard of laptops that had VGA working OOB with Haswell HD4400 (and only HD4400) but these always an add-on discrete GPU too. If you don't have VGA output working OOB, you won't have it at all I'm afraid.

MyHack is not a tool to be used on a real Mac. This being said, if you're on a Hackintosh, myHack requires the active account's password (whicvh needs to be admin) to proceed. If you never set a password, do so (you can still login in without entering it) and make sure your account has all admin rights. This would be the account setup and the OS was installed on the computer.

@Smart Tek Peru, you made a typo in your SDXC device patch: you've injected a "device-type" property instead of "device_type"... Seems it invalidates then entire patch since your IOReg clearly show no "compatible" entry set to "pci14e4,16bc"; it should! Re: USB ports, you've kept your initial Darwin check in PCI0 _INI method. Why don't you get rid of it since you've got the check added alongside Windows 2006? I would also recommend you modify your HPET device from this: IRQNoFlags () {0} IRQNoFlags (_Y10) {8} to this: IRQNoFlags () {0,8,11,15}

Ok, I understand better now. Indeed with the additional Darwin checks under _SB->OSID method, the patch is effective on the E6230. I only had the Darwin check under _SB.PCI0->_INI method which is required for USB3 recognition. Adding the Darwin checks to _SB->OSID does the trick! Well done, thanks for that detailed and very useful contribution. I'll try it on my E6220 and E6440 but I guess the Fn-UP/Fn-DOWN key strokes may return different values that I'll have to identify. NB: I noticed a 4th Darwin check under _SB->PCI0_> _OSC method in the DSDT you posted. It seems to be USB3 (XHC) related but can you explain what this actually does or is meant to do? Here, it kills the 2 x USB ports on the right side after wake so I'm keeping that check out...

Usually, one needs to identify the ACPI Embedded Controller sequence associated with the key strokes or the PS2 values returned by the key strokes (See Rehabman's repo on the matter). Your patch does not do any of that as far as I can see. Nevertheless, I've just tried it and I don't see any difference with it. Fn-UP/Fn-DOWN still only control brightness at hardware/LCD level, not at macOS level. This was already the case before I applied your patch and Fn-F3/Fn-Insert remain the only 2 x key strokes that control brightness at macOS level. As far as I'm concerned, the above patch is either not effective or incomplete. In addition, this patch cannot be applied "as is" to the BRT6 method defined under the dGPU device, only that of the iGPU... @jpz4085, you should probably post your DSDT and explain what you derived your patch from or how you came to it. Because it seems you send values to the keyboard as opposed to detect key strokes and trigger brightness actions accordingly...

Can you post the .dsl version of the DSDT you fail to compile? No use to post a compiled version...