Hervé

New version v2.2 released today with bug fixes.

Check your hibernation status and, if required, disable it as per our FAQ topic on the matter.

IOGraphicsFamily patch that used to fix the Apple logo glitch at boot time is normally irrelevant and deprecated with Lilu + WEG.

All those you cache, yes.

@Tubardus, try again with boot args: bpr_handshake=0 bpr_presetdelay=250 On the other topic, yes you may load with your cached kexts (from /L/E) and inject kexts from /E/C/k/O if you set kexts injection to "Yes" in your Clover config.

Try again to cache the 3 x kexts I had uploaded a couple of days ago, but this time, add the following boot argument to your Clover config: bpr_handshake=0

It used to with the PS2 controller used on old D Series Hackintosh. You could try and compare the settings of the Info.plist files of the PlugIns of both set of kexts.

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.