Hervé

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.

DW1510 remains fully supported in Mojave. But it's a half-size mini-PCie card and the E5470 WLAN slot is NGFF/M.2... Pray that yours comes with the correct DW1820A...

Ok, so you're caching some kexts from /L/E and injecting most add-on kexts from Clover E/C/k/O. You should probably cache all your add-on kexts from /L/E, knowing that you can then keep exising kexts in Clover's Other folder and set kext injection to "Detect". In that mode, Clover only injects kexts if FakeSMC is not in /L/E. You appear to run audio with AppleALC so get rid of that AppleHDA-IDT kext you've installed in /L/E. Once you've copied all your kexts to /L/E, repair permissions and rebuild your cache.

Sorry, 'never heard of it.

Setting kexts injection to "Detect" is fine. The question is: do you know what this does/do you know how kext injecton works? Hence the need to know where you placed FakeSMC... Did you install any kexts in /L/E?

So the main change was the uninstallation of the SierraWireless drivers. The WWAN icon may simply refer to a different piece of previously registered hardware from when you had the SierraWireless drivers installed. It may be like when you choose show the Bluetooth icon in the menu bar and then remove or disable the Bluetooth hardware: the icon stays there but is unusable. Try and uncheck the box used to display the icon, then recheck it afterwards.

Ok but do you inject or cache kexts (latter recommended)? Where is FakeSMC?

That difference in "About this Mac" is just language related and is totally irrelevant to your DRM predicament. If you switched to English you'd have the "graphics" word in the report. The DRM/green screen issue was normally solved by Shiki kext, which is now integrated in WEG Lilu PlugIn, so all should be ok on that front.

That "Key" field is just like a title, so if that's the only thing you modified, it's not possible that it made a change in terms of operations; you must have changed something else. In addition if you opted to modify the vendor id of your dedicated entry from 0x1199 (i.e. 4505 in decimal) to 0x(0)199 (i.e. 409 in decimal), then your dedicated entry no longer applies to your hardware (its ids obviously will not change!) and another profile is being used instead...