Hervé

I'm pretty sure @philstopford means the actual TrackPad/TouchPad device. Unless I'm mistaken, the 7480 uses a similar Alps I2C device as the 7490 and, indeed, it occasionally fails to respond to finger. Rebooting (once or multiple times) will eventually bring it back to life. This issue is undoubtedly due to those I2C drivers we use; they're not 100% kosher yet, it's work in progress. On the 7490, the device is fully functionnal as a Mac TrackPad/TouchPad and shows as such in the PrefPane. It can just be a little awkward to use. I see no reason why it would be different on the 7480, they're basically the same laptops apart from CPU generation.

So, no-one using this High Sierra/Mojave guide?

It's been mentioned in various places on the forum and I should probably write an FAQ thread on the topic. /S/L/E is the location for Apple's own (i.e. vanilla) kexts. Ideally, this should be left untouched by Hackintoshers unless for very specific and rare reasons (eg: patched AppleHDA). /L/E is the location for 3rd party/add-on kexts. This is where all kexts we use for our Hackintoshes should go. Kexts placed in either of these folders will be cached and this aims at accelerating boot time. Cached kexts are subject to signature and be set to the correct permissions. Cached kexts will be listed/registered in SysProfiler/SysInfo->Software->Extensions. Caching kexts is the recommended manner to use add-on kexts. Clover's E/C/k/O and E/C/k/10.xx are the locations for kexts that Clover injects at boot time: E/C/k/O is used to inject kexts regardless of the OS X/macOS version. E/C/k/10.xx are used to inject kexts for the given OS X/macOS version and therefore allow different kexts to be injected for different versions. Injected kexts are not cached and will not be listed/registered in SysProfiler/SysInfo->Software->Extensions. Injecting kexts results in a slower boot time than with cached kexts (though many would arguably say it's hardly noticeable). Kexts injection operates according to Clover settings on the matter: If kext injection is set to Yes, kexts placed in E/C/K/O (or E/C/k/10.xx) will be injected. If kext injection is set to No, no injection takes place obviously... If kext injection is set to Detect, kext injection operates according to the presence of FakeSMC in the cache (from /L/E or /S/L/E). If present, no injection takes place, if absent, kext injection is performed. Kext injection is very useful for recovery purposes (like booting without cache which ignores /L/E) or when testing kexts for instance; if a newly injected kexts causes issues (like a KP), it's very easy to remove/bypass it. On the other hand, kext injection is known to occasionally cause problem because it's not the natural way in which kexts should be loaded. Kext injection is basically a form of forced loading and, sometimes (though rare these days), it does not work. My own recommendation is to experiment with kexts through injection and, once kexts are validated, to cache them from /L/E. You can Google for this kext injection matter or consult the Clover wiki/InsanelyMac forum. It's all quite widely documented.

https://osxlatitude.com/forums/forum/104-wireless-and-bluetooth/

DW1397 card is not compatible with High Sierra. Disable it in BIOS or physically remove it in case it causes an issue (though it should not). You also need to use a SMBIOS compatible withy High Sierra. MacBookPro7,1 will do perfectly. Can you post a zipped copy of your Clover EFI folder or link to the folder you used (assuming you've not modified it in any way)? Please note that you cannot install High Sierra with Enoch; you need Clover for that. As such, my D630 Sierra guide is not appropriate for High Sierra (I really need to update that guide...). Once HiSie is installed, you can use Enoch to boot it but you'll then need to call on your Clover-based USB installed to complete any subsequent update (like the Security ones). So opt directly for Clover.

Moved from Guides section to Support! Please ensure you use the correct section for all future posting. K3100M is Kepler and is therefore expected to work OOB. K2200M is Maxwell and requires the nVidia Web Driver. It's therefore only supported up to High Sierra. You also have to take the potential issue of Optimus into account (unsupported on Hackintoshes).

It'll be the same EFI folder as for Sierra or High Sierra. You can derive it from the initial Chameleon/Enoch bootpacks available here. Due to unsupported C2D CPU + nVidia GPU, the D630 (like the D830) requires the well-known tricks for Mojave: replacement of telemetry plugin by that of High Sierra 10.13.6 to avoid non-SSE4.2 C2D-related KP (extract it from 10.13.6 combo update available off Apple's web site) installation of Tesla kexts from High Sierra 10.13.6 (they do not exist in Mojave due to lack of compatibility with Metal). I recommend you install those in /L/E patched PlatformSupport.plist or, ideally, change of SMBIOS to a Mojave-compatible model like, say MBP9,x (this is required for Mojave updates) And, since Mojave 10.14.4, you also need: replacement of GPUSupport + OpenGL frameworks by those from Mojave 10.14.3 (extract them from 10.14.3 combo update) You can refer to these threads/guides: https://osxlatitude.com/forums/topic/10726-macos-1014-mojave-betas-releases/?do=findComment&comment=83099 https://osxlatitude.com/forums/topic/11148-dell-vostro-200-st-with-c2d-e8600-geforce-gt730-gt1030-high-sierra-mojave/?do=findComment&comment=87085

Yes.

If Tap-to-Click and 2-finger tap don't work, then your best option is an external (cordless) mouse.

well, we require much further reading...

Config is completely inappropriate for your platform. Where did you get this from ???

By now, you should know the drill: post a zipped copy of your EFI Folder. Screenshots of backup EFI folders are useless.

Do not install kexts to /S/L/E, it's supposed to stay vanilla. Use /L/E instead. Kext Wizard is an old tool that's probably unsuitable to macOS versions. Once you've installed your kexts to /L/E, manually repair permissions and cache using the well-known process we documented in FAQ section several years ago.

Post-Kepler cards remain unsupported; those attempts to get Web Drivers working under Mojave do not provide any graphics acceleration and are just a waste of time. You just get cards more or less properly reported in the OS and that's about it.

If you want USB3.0 ports, you need to make sure your DSDT injects Darwin; no USB3.0 otherwise. Then you'll need to cache or inject FakePCIID + FakePCIID_XHCIMux kexts.

The seller was wrong to advertise it as a Broadcom BCM4352, I guess he did not know any better. Those cards are definitely BCM4350 chipset despite the BCM94356xxxx label at the back of them (that's illustrated in my guide). OUI 30:52:CB belongs to Lite-On just like other OUIs such as C8:FF:28 or 74:DF:BF. Nothing wrong with your MAC address.

Very strange because you clearly have the DW1820A 0VW3T3 model which works fine for most people... Yet, the behaviour you describe is that encountered with the 08PKF4 model or the Foxconn T77H649 model. I'm at a loss... You've cleaned up the kexts duplication but kept FakeSMC only in E/C/k/O, so you're still injecting kexts. Copy the following kexts to /L/E, repair permissions and rebuild your cache: AppleBacklightFixup.kext ApplePS2Controller.kext FakeSMC.kext IntelGraphicsFixup.kext (is it really needed?) IntelMausiEthernet.kext NoTouchID.kext USBPorts-E7470.kext WhateverGreen.kext Remove the following kexts from E/C/k/O: SMCBatteryManager FakePCIID You may also try the following Clover config where I've made a few adjustments to the ACPI section and, as a test, changed SMBIOS to MBP15,2 which is what I'm using without issues with the DW18120A 0VW3T3. config.plist.zip Nothing else to offer, sorry.

There you are: Archive.zip Rest assured those kexts are part of the vanilla installation, no doubts to be had on that front. For future reference, with Pacifist app you can extract kexts from any given combo update (like 10.14.4) available off Apple's web site. Simply Google for it.

You may also try the DSDT patch that re-assigns keys properly on the E6230. It may apply to the E6530 too.

A few comments... a) IORegistryExplorer screenshot you attached shows info leading to believe you've not implemented the settings recommended in the guide: name + device-type show being set to "Airport" model shows being set to "AppleWifi Card" which is indicative of Clover "FixAirport" remaining enabled. You don't need this and I did ask you to remove this from your Clover config no kext loaded for your card which is indicative of a highly likelihood that some non-vanilla kexts remain on your system. b) But it's a red herring because on looking into your attached debug pack, I can see that: Clover config is now 100% Ok IOReg output shows all properties correctly injected but no kext loaded for the card Kextcache shows you kept an older and inappropriate IO80211Family kext in /S/L/E despite being specifically told to revert to the vanilla kext Revert to a full vanilla installation as requested before by re-instating the original IO80211Family kext in /S/L/E. Once you've done that, you card will work perfectly. NB: Kextcache log also shows how much you messed up with kexts: you've installed some add-on kexts in /S/L/E, some in /L/E, some in both. That's the best recipe for disaster! Only install add-on kexts to /L/E. Remove all those you installed in /S/L/E, repair permissions and rebuild you cache. Lilu -> LE + SLE AppleALC -> SLE ACPIBatteryManager -> LE + SLE BrcmPatchRAM2 -> LE + SLE BrcmFirmwareRepo -> LE + SLE And that's on top of injecting those same kexts through Clover (where you've also added unnecessary or competing kexts: AtherosE2200Ethernet / IntelMausiEthernet / RealtekRTL8111, ACPIBatteryManager / SMCBatteryManager, etc.). You really ought to use the correct add-on kexts and decide what you want to do with them: cache them (from /L/E) -which is recommended- or inject them (from E/C/k/O). Just don't duplicate or triplicate stuff...

You should use Cover Configurator app; the guide is quite clear on that matter... Anyway, remove the FixAirport Clover option (your initial IOReg text output shows the card under RP05@1c->PXSX@0) remove that old IO80211Family kext you were trying to inject remove AirportBrcmFixup and post a new debug package with an IORegistryExplorer saved output (IOReg text output is no pleasant read). If DPCIManager app sees the card in IOReg, IORegistryExplorer will too! You're either missing it or doing something wrong. I assume that Wireless + Bluetooth are enabled in BIOS.

Yes, partitions are usually reduced or increased from their end not their beginning. Unless there are specific tools that allow to basically "move" a partition, it's impossible to free-up disk space ahead of a given partition to give the recovered disk space to that partition. What you'd have to do now is clone your existing partition onto the 1st/new one and then, you'd be able to delete that initial 2nd partition to recover the disk space and re-allocate it to the 1st one on disk.

Look at our BCM4350 guide in Wireless section. But 1st check the model you have...

I've no idea then. Nothing looks wrong on the Clover setup. That leaves the question of a full vanilla installation or not...

If you're using latest Lilu + WEG, you don't need to set "Inject Intel" + "ig-platform-id 0x01660003" in Clover->Graphics section. Also, remove Drop OEM SSDT from ACPI section.