Hervé

Your Clover config does indeed apply the expected and required patches to IOReg device located @00020000 (i.e. the IGPU). Open up your config file in Clover Configurator, go to Devices tab, click on Properties and select device PciRoot(0x0/Pci(0x2,0x0). In the right section, you'll see that HDMI connector-type 00080000 is applied to FB@1/port #5 and revised DP connector-type 00040000 is applied to FB@2/port #6. This is the expected config to activate and support HDMI output + DP output. So yes, HDMI will work if you plug an HDMI display into the laptop's HDMI port for instance. Same should be applicable for DP outputs out of an E/Dock. With regards to VRAM increase to 2GB, the patching guide also explains what to do on the matter and in that same properties section as above, you should notice a 1st line starting with a #. # character means that the line is commented out and that it actually corresponds to the VRAM increase patch. Uncomment the line by removing the # character and you'll obtain 2GB VRAM.

Please refer to the Haswell iGPU patching guide in R&D graphics section. It's illustrated with the E6440 I used to own.

Cholonam has now issued a version v2.1 which appears to work for some of our Realtek RTS52xx car readers. https://www.insanelymac.com/forum/topic/321080-sineteks-driver-for-realtek-rtsx-sdhc-card-readers/?do=findComment&comment=2718154 https://github.com/cholonam/Sinetek-rtsx/releases I've tested the driver successfully on my Latitude 7490 fitted with Realtek RTS525a microSD card reader. I experienced a read/write limitation to 5MB/s max. It was reported to Cholonam who is aware of this. Other than that, it works fine. It's probably the best we'll get for some time as Cholonam indicated he was unlikely to pursue work on his driver given that it works for the RTS525a card reader of his Dell XPS 9350. If that were the case, hopefully someone will be able to pick from there and resume work in the future. Please note that I've only tested this driver under Catalina since that's the only version I've got installed on my Latitude 7490. Would be grateful if people would feedback with their own tests under other macOS/OS X versions. Also note that if Clover is booted off the microSD card, laptop will need to be put through 1 x sleep/wake cycle to initialize access to the card.

Item #2 -> Please read our FAQ !

I've never really looked into this PCIe auto power setting matter so I'm afraid I don't know. It's not a boolean parameter if that's what you thought. I found that some cards on some laptops require this to be disabled (value 0). But, on my 7490 for instance, I didn't have to touch this with the 2 x DW1820a 0VW3T3 cards I initially bought. On the other hand, it was required with other DW1820a models... Anyway, that's off-topic.

@Tubardus, those cards are combo: they have a wireless chip (BCM4350) and a Bluetooth chip (BCM2045A0). The two are totally separate things.

Latest Broadcom patching kext set is build 2.5.2. Build 2.0.6 is old now. You should only be using Repo or Data. 1st one if you cache kexts, 2nd if you inject them through Clover. I very recently posted about my experimentation and findings re: Bluetooth of DW1820a and those patching kexts here.

No, because on p1, you posted the same BT module ids (0a5c:6412).

To clarify the matter: I added my own extracted and uncompressed firmware files, hence the .hex extensions I tested shorter name with both uncompressed .hex files and compressed .zhx files. BT worked in both cases I did not rename a compressed .zhx file to a .hex extension; I only renamed the firmware files to a shorter name and BT started to work. The kexts I uploaded in my previous post contain my added uncompressed firmware v5974. Make sure the BT module is actually fully enabled. Go to your BIOS settings and disable Bluetooth + Apply change enable Bluetooth + Apply change then, reboot into macOS. I don't think you need to redo all the tests I did, but it's up to you.

I've sanitised your last post and added specific details such as the facts that you're now running Catalina and that you switched from BrcmPatchRAM2 to BrcmPatchRAM3 on April 12th, probably after you came to realise things were not working with your 1st Catalina-incompatible firmware patching kext. This being said, I notice that your firmware does not appear to get updated by the patching kexts. I suspect you could be facing the same situation as I did on my DW1820a and that the name of the firmware file used for deployment on the Bluetooth module actually causes a fail in that respect. Maybe you ought to try the adjustment I detailed here to fix things, in a nutshell shorten the name of the firmware file.

Just to be sure, you're following the Catalina guide for Catalina, right? Because your initial link pointed to the Mojave guide. Would I be right to assume that you're installing Catalina 10.15.4? I might need to revisit Catalina's installation guide given that there were many issues with the 10.15.4 update. Will try a fresh 10.15.4's installation on the 7490 to see...

@Tubardus, I've spent 2 x days on this DW1820a Bluetooth problem as it really bothered me. I believe I've sorted it out. It's a fairly long story (which is detailed here) but I basically identified that the issue we experienced was due to the name of the compressed firmware file referenced for our DW1820a BT module (0a5c:6412). Furthermore, I believe the devs who wrote the new Broadcom firmware patching kexts got it wrong on the matter of firmware version due to a misunderstanding regarding a non-generalised convention. Anyway, I am now able to get Bluetooth working normally at all time, not just only when warm rebooting from Windows. Please try the attached kexts where I've modified Repo and PatchRAM3 to use uncompressed firmware v5974 rather than compressed v4688 which did not work. Copy them to /L/E, repair permissions and rebuild your cache. Then shutdown and perform a cold reboot. Bluetooth should then work and work all the time. BrcmBluetoothInjector.kext.zip BrcmFirmwareRepo.kext.zip BrcmPatchRAM3.kext.zip NB: you may experience a KP on 1st cold boot after rebuilding your cache. I do. I don't know why yet but it only happens on the very 1st cold reboot, never afterwards.

Problem is not that of firmware; something is done when booting Windows that does not happen when booting macOS. I'm convinced firmware is irrelevant here. If you reboot from Windows into macOS, you'd be Ok. Best card would be Fenvi BCM94360NG but they cost about 45-50$/€.

I just ran all sorts of test with acidanthera's Bluetooth patching kexts v2.52 since yesterday and it's systematically repeatable: no functional Bluetooth on a cold boot into Catalina 10.15.4, no matter what, whether the kexts be injected, cached or a mix of both. Bluetooth only functional as long as I remain on warm boots/reboots from an initial Windows boot (my Latitude 7490 is setup for dual boot). I used the debug kexts version and, to my surprise, the logs are identical so it's a mystery to me as to what actually happens in Windows that does not happen on a cold boot into macOS. I hardly ever do a cold boot on this machine, I keep it in sleep mode most of the time, so I never really experienced too much trouble with BT before.

Save it under a different name (eg: config_test.plist) and call it from Options->Config menu once you reach Clover startup screen.

That's the actual firmware v7.5799, extracted from a Windows driver. Not of any real use for you at this stage/point of time. My observations after further lengthy testing and recommendations: In Windows, make sure your BT module is operational with whatever firmware (I found that v4688, v5799, v5803 all work). In macOS, make sure you're not using AirportBrcmFixup kext; I found it interferes with Bluetooth. I found BT works only when warm rebooting from Windows into macOS and that it does not work after a cold boot. No matter whether Brcm kexts are cached or injected.

Here's how things look for me in 10.15.4: I use a BT mouse, I can hook audio to my JBL BT speaker or hook to my iPhone either via BT or via HotSpot to use the shared data connection. So all is Ok on the BT front. Handoff and AirDrop between my Latitude 7490 and my iPhone work perfectly too: .

Yes that's what I meant. Now I had kept a copy of DW1820a BT info screenshots, so here they are: Try and Google for DW1820a Dell driver v12.0.1.750. It's called Dell-Wireless-1550-1560-1704-1708-1820A-1830-Bluetooth_YW21W_WIN_12.0.1.750_A04_02.EXE.

Try and update the card to the latest Bluetooth firmware from Windows using the Dell drivers. I think the required driver is mentioned somewhere in the defunct DW1820a general troubleshooting thread now located in the Archive.

What's the origin of this kext? I can see it contains older versions of the Broadcom PlugIns but I've not verified which macOS version they came from. Can the Atheros40 PlugIn be added to 10.15.4's IO80211Family kext or is this entire revised IO80211Family version need to replace the vanilla one? Did you test this revised IO80211Family kext in /L/E whilst keeping 10.15.4's vanilla kext in /S/L/E?

If it's different from 4096, that is good. That shows that the kexts do load a FW to the module. My DW1820a Bluetooth shows FW v5799 but I had updated it in Windows using one of those Win10 drivers. How does BT behave after you put your 7490 to sleep and wake it?

@Tubardus, Bluetooth module of DW1820a should be fully functional if you use acidanthera's latest kexts (version v2.5.2 at time of writing). There are 2 x ways to use them: if you cache kexts from /L/E, use BrcmBluetoothInjector + BrcmFirmwareRepo + BrcmPatchRAM3 if you inject kexts from Clover's E/C/k/O, use BrcmBluetoothInjector + BrcmFirmwareData + BrcmPatchRAM3 That's what I use (I cache kexts from /L/E) and I don't use AirPortBrcmFixup kext (therefore no use of brcmfx-country boot parameter either) since I found no need for it with my DW1820a, the properties injected through Clover's configuration being totally sufficient. Bluetooth is fully operating with these kexts in Catalina 10.15.4.

And you forgot to state what wireless card you use.

it's a Latitude 5491, not an E5491 which does not exist... Qualcomm card not supported -> to be replaced by a supported model. For the rest, your Clover setup (config & kexts set) is very messy. ACPI renaming contains stuff for Z390 desktop motherboard. Your Clover Kernel & Kexts patches section contains all sorts of irrelevant and inappropriate patches (eg: BDW + SKL + KBL patches). Remove those You selected MacBookAir8,1 SMBIOS, i.e. that of an Amber Lake platform with UHD617 graphics Amber lake model when you have Coffee Lake CPU with UHD630 graphics. Use MBP15,2 instead. Graphics: you inject layout id 12345678, i.e. a fake layout used for troubleshooting graphics in VESA mode. You cannot get any graphics acceleration with this. Replace this fake layout value by one of a UHD630 layout or don't inject anything in Graphics section and, instead, inject any required properties such as layout id (eg: 0x3E9B0000) and iGPU id (but native id should be Ok) in Devices section for device PciRoot(0x0)/Pci(0x2,0x0). Then rely in Lilu + WEG kexts. Get rid of all those XHCI and SATA kexts, they're not required TouchPad will undoubtedly be I2C so you'll need to add the VoodooPS2 I2C kexts and probably the I2C SSDT tables too. Refer to existing Coffee Lake/Latitude 5490/Latitude 5400/Latitude 7490/Latitude 7400 threads for guidance and do a search on UHD630.

You can look at the models for which we've published benchmarking results here. There's only a couple but the best you can do is Google for NVME SSDs compatible with Mac. Example here.