Hervé

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...

Are you sure you've applied your setup changes to the correct EFI folder?

Maybe an older BIOS on the laptop which would conflict with a patched DSDT?

This AppleHDA requires the dummy 92HD90 kext too. And proper layout injection.

I don't have any built-in LCD with such high resolution, only 1366x768 or 1600x900. Maybe the patch would be different for HiRes screens.

DW375 is BT3.0 and will not support hands-off. You will never get Bluetooth off your BCM94352HMB unless the DW375 is disabled in BIOS, switched off through the side switch or physically removed. If you're currently not seeing the Bluetooth module of the BCM94352HMB module, that's because you have an issue getting all your USB ports working. If you want Hands-off + Continuity to work properly, I recommend you opt for an Apple card such as the BCM94360CD + mini-PCIe adapter. That's what I've gone for on all my E Series laptop and everything works as on a real Mac. For audio, why don't you switch to patched AppleHDA. Details of the patch are available in my E6220 guide.

Ok, this will be fairly easy... -> 1st error shows: line 11613: syntax error, unexpected '}' This is due to the line 11612 that contains only "Arg0"; it's incorrect and needs to be deleted Once you've deleted that line, your DSDT should recompile Ok.

Fn-UP and Fn-DOWN should still control screen brightness but not at OS level, only at hardware/LCD level. If you want to remap brightness control, you'd have to identify either the PS2 scan codes or the APCI EC queries associated with Fn-F3 and Insert, then Fn-UP/Fn-DOWN in order to re-code the brightness instructions accordingly. There was a guide related to this but I cannot remember if it was here at at IM. 'never tried this either... From memory, I think you may be able to check PS2 scan codes through some debugging of the PS2 controller kext, the info going into syslog. For EC queries, Rehabman had a debug kext that worked alongside some DSDT patch. You'd have to look that up. Hmm, maybe it's time I look this up too...