Hervé

It's all to do with the I2C drivers... A Magic TrackPad will of course work perfectly, it's an Apple acessory! You really can't compare the 2 x devices when one is an Apple product and the other a PC piece of hardware that's not even meant to be supported and relies on goodwill development.

You may try the I2C kexts that are available in my Latitude 7490 guide. Got them from another thread but I already forgot which one! Oups...

If you already cache FakeSMC from /L/E, that's normal. You need to understand how Clover kext injection works in relation to FakeSMC. Anyway, it's recommended to install add-on kexts in /L/E and cache, rather than inject them from E/C/k/O at boot time.

I got to test the Dell WD15 USB Type-c docking station today. Supported OOB: HDMI, mini-DP and VGA outputs GigEthernet RJ45 port (Realtek RTL8153 USB3-to-Ethernet converter, 0x0bda:0x8153) Rear USB2.0 ports Rear USB3.0 port Front USB3.0 port Front headset jack Unsupported: Rear line-out jack (tried various layouts to no effect) Regarding VGA output: VGA worked OOB as single connected display, laptop booted lid closed. VGA worked as 2nd display only if connected at startup (it's quite usual for VGA not to work if connected after system has started). VGA worked alongside DP and/or HDMI but only in clone mode, not as 2nd or 3rd display. This is something apparently done at docking station level. Dell manual states it's the expected mode in 3 x displays setup but, in my case, this was experienced only with DP connected, laptop's lid closed. Front headset output: VGA output (lid closed): DP/HDMI output (lid closed, with or without VGA): Dual display, built-in LCD + VGA: Dual display, built-in LCD + DP or built-in LCD + HDMI:

Use the revised pack I posted in the guide. It's got better I2C kexts which fully support the TouchPad, except the buttons. I've just tested USB-c WD15 docking station and it's supported near-100%. I only have 1920x1080 external displays though so cannot comment on 4k.

Looking good at my end!

No, you can install a fresh version over your existing one without needing to remove anything. That method will actually retain all your apps and data.

No, you'd have to have the system fully running under Clover for that.

Regarding loss of boot, try and re-install Enoch on your El Capitan partition. You may also try to boot without cache, provided your kexts were copied to /Extra/Extensions. You'll need the following boot flags and boot options for that: -f -v KernelBooter_kexts=Yes If you're running Enoch and wish to retain it, you have no choice but make up a new USB installer with the macOS version of your choice and install the new version over your El Capitan partition. The E6230 perfectly supports Mojave so don't hesitate. You'll just have to switch to Clover.

USB keyboard and mouse normally work OOB. Maybe you replaced or removed the default vanilla drivers.

No patched DSDT in the uploaded debug package Mario.

Changing topic title since we've gone way past audio issues in 10.14.1... @TheOtherOne, you config is quite messy and needs tidying up, especially on the ACPI fixes and CPU power management front. Boot options look incorrect too. Specified boot volume seems wrong: you point to a /dev/disk2s2 device when one usually points to a partition name... Regarding kexts, you inject FakePCIID with none of it's PlugIns, so what do you aim to achieve with that?

You may simply enable/activate the Clover AICPUPM patch rather than those kexts that have become a little obsolete with the demise of old Chameleon. Even Enoch offered on-the-fly AICPUPM patch in the end.

@Achille In the future, please use the forum Spoiler facility for such posts. Thank you. I don't think many people will bother to read that stuff you posted but if you want to verify CPU power management, there are 2 x little tools at your disposal: Intel Power Gadget HWMonitor app (available alongside FakeSMC and its Plugins which are required for proper monitoring). See here for instance.

I can't see anything wrong or obvious in your debug pack. Clover config appears Ok to me, you're not injecting any kext that would not be required or using unnecessary boot options/flags. The only thing I noticed is that you have some add-on kexts in /L/E (like the Broadcom firmware patching kexts) that appear to be ignored. Kexts injection looks active (FakeSMC in E/C/k/O, not in LE or SLE) from your Clover EFI folder. IOReg output shows that no kext loaded for your DW1820A. As such, I am wondering if you have the full vanilla IO80211Family kext in SLE without any mods or any additional kext that would prevent AirPortBrcm4360 + AirPortBrcm4331 to load... Please check that and then rebuild your cache through Terminal: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /S*/L*/E* sudo touch -f /L*/E* sudo kextcache -i /

If all you want is list devices in your SysProfiler->PCI section, it's a simple matter of: identification of the devices location IOReg (ACPI device & address) injection of the devices properties into DSDT via a _DSM method under the identified ACPI device (hundreds of example on the forum) or injection of properties through Clover (as per DW1820A guide for instance)

I've just given a hand to a new member who's installed Mojave on his Latitude 5490, fitted with a DW1820A. He could not get the card to work properly either, stating that the card would only work Ok a few minutes then cause severe lag or performance degradation. After a few minutes checking his machine, it was found that: AirportBrcmFixup kext was injected by Clover -> removed Vanilla IO80211Family kext was in /S/L/E -> Ok Incorrect BrcmFirmware kexts were being injected through Clover -> corrected A kext called AirPortBrcmNIC-MFG was present in /S/L/E -> removed Installation was said to be full vanilla with Chris1111's installation tool. Member confirmed he did not manually add the AirportBrcmNIC-MFG kexts to /S/L/E and that the partition was freshly formatted before installation, so it must have been done by Chris1111's tool. This AirportBrcmNIC-MFG kext was last seen in High Sierra and it was understood as a replacement for AirportBrcm4360... Anyway, once the above defects were corrected (and all add-on kexts copied to /L/E, permissions repaired and cache rebuilt), the DW1820A started to work perfectly, as expected and as described in my setup guide, with no performance degradation on the Latitude 5490. So guys, please double/triple check your installation setups before posting about your non-working DW1820A.

By the way, you did not have a DW1820A but a Lenovo/Foxconn T77H649.00 (subsystem id 17aa:075a)...

@bluesbendeer, if you want more support, please post your debug package. Without this, we're blind and can't assist.

Read the DW1820A guide Remove AirPortFix Clover fix Remove brcmfx-country=CN Clover boot option Remove AirportBrcmFixup from Clover kexts folder Make sure you run on full vanilla 80211Family kext in /S/L/E

Update to latest Clover... https://github.com/Dids/clover-builder

It does not seem like there is any kext loaded for a Broadcom-based attached to PXSX device located @1C,4. Are you sure it's the right location? Double check your Cover config and injected kexts in case you have something clashing. If you want further assistance, please post a zipped. copy of your Clover config + saved output of IORegistryExplorer. You should know the drill by now; impossible to say more in the blind...

As far as I know, that card will definitely cause trouble until the property injection is done (or the other older alternatives such as removing the BrcmNIC Plugin kext).

Seriously...