Hervé

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

Hmm... Using Clover Configurator app: SMBIOS: change from (empty) iMac14,2 to MacBookPro11,1 (that should fix your graphics issues) Rt Variables: change BooterConfig from 0x0038 to 0x28 and CsrActiveConfig from 0x03ff to 0x67 Follow guides published on this site and read E7440-related threads in order to avoid such mishap.

Why don't you post your file and state what you last did that broke it?

Use Chrome... Afaik, Lilu + WhateverGreen won't fix the DRM issue in Safari with Netflix. Even real Mac computers suffer the same.

VGA is unsupported on HD4000 (the patch that works on HD3000 won't work on the Capri FB). So , you cannot have VGA output off that E6330. Only HDMI and, if you have a docking station, DVI + DP.

The "com.apple.iokit" path header part is required with all recent versions of Clover (can't remember from which version this started); this applies to other on-the-fly patches too. No idea why, in your particular case, the patch remains ineffective though. You can re-instate the vanilla kext, repair permissions and rebuild your cache. Can you post your debug info + zipped EFI folder?

There isn't much you can do for the occasional HD3000 graphics glitch (screen corruption, cross-screen horizontally lines), it seems to affect all HD3000 systems especially over time and after repeated Sleep/Wake. The best I found to lessen the degradation was to increase RAM to 8GB to, in turn, increase available VRAM; but it's no definitive and permanent fix. Patching the SNB/HD3000 kexts to increase VRAM further bring no cure either. You only apply the "Inject Intel" parameter in Clover, presumably because you already inject layout 0x00010000 in DSDT. This usually calls for MBP8,1 SMBIOS and I see you use MBP8,2; you probably want to give the MBP8,1 a try, especially as that's also an i5-based model whilst the MBP8,2 and MBP8,3 are i7-based. Re: CPU temperatures, make sure to apply the AICPUPM patch (whether direct binary patch of the kext or Clover on-the-fly patch) and to generate your CPU-specific power management SSDT. You have an i5-2520M so you can always retrieve the required SSDT off my E6220 guides (it has same CPU). Looking at the EFI you posted, it seems you're running on an old file. Try and regenerate the SSDT with Pike R Alpha's latest generator script. Regarding handoff, your posted IOReg output shows a Broadcom BCM94352HMB and the built-in DW375. You'll have to disable Bluetooth in BIOS (or place wireless side switch to off position if set to control BT in BIOS) to deactivate the DW375 and run BT services off the Broadcom card. Otherwise the built-in module always takes precedence over the add-on combo card. You will see this in SysProfiler (System Information) Bluetooth and USB sections.

Make sure to use the correct VoodooPS2Controller. R6 compiled by Bronxteck works perfectly. https://osxlatitude.com/forums/topic/8285-refined-alps-touchpad-driver/?page=1

Just add it to the Kernel & Kexts Patches section of Clover using Clover Configurator app. You have all the necessary details. It works perfectly on my Dell E6230 laptop whether through direct kext binary patching (though I do this through a modded copy of the kext in /L/E and increase the kext version) or through Clover on-the-fly patching. Note that I only use Lilu kext; not Whatevergreen or IntelGraphicsFixup since I found no need for those. Maybe your patch is incorrectly specified in Clover. What do you apply and how? When you binary modded the kext, did you rebuild your cache afterwards?

It really is nothing in your attached video... Tis being said, the patch applicable in Mojave remains the same as in High Sierra: replace 0100007522 by 010000EB22 in IOGraphicsFamily kext's binary.

1) Sleep: did you disable hibernation as detailed in our FAQ section? Your DSDT is certainly suitably patched on the USB ports power management front. 2) USB3: your DSDT contains the following (Apple-specific) code under the _INI method of scope _SB.PCI0: If (_OSI ("Darwin")) { Store (0x2710, OSYS) } Try and remove this and, instead, apply the following change to the Windows 2006-related code that you'll find a little further down the _INI method: If (LOr (_OSI ("Darwin"), _OSI ("Windows 2006"))) { Store (0x07D6, OSYS) } This should activate your USB3.0 root. Then, all you'll need are Rehabman's FakePCIID + FakePCIID_XHCIMux kexts for USB2.0/USB3.0 multiplexing. Note that the renaming of EHCx device to EH0x for USB2.0 ports may not be required on the E6x30 family. I use no such renaming on my E6230 and all works well with MBP9,2 SMBIOS. 3) SD card reader: your DSDT contains an incomplete (and cosmetic-only) patch for device RP06.PXSX. O2 SD card reader for the E6x30 laptops is covered in the dedicated R&D -> Hardware section. Patch your DSDT device accordingly. 4) Graphics glitches: did you apply the final stage boot glitch patch ? In IOGraphicsFamily kext, binary replace 0100007522 by 010000EB22. You can apply this as an on-the-fly Clover patch.

Guys, as stated in our wireless card inventory, it's fair to say that these cards suffer from poor to no support at all and are therefore best avoided. Replace them by fully supported models and avoid all hassle.

Use R6 by Dr.Hurt (compiled by Bronxteck) available in post #1 of this thread...

We don't believe it's got anything to do with the kernel. It's must be something to do with the nVidia drivers but the issue has not been identified afaik.