Leaderboard

So according to @Hervé's guidance, I was able to use my DW1820A. My configs were posted here. After some research, I'm able to use Auto Unlock function now, and still no freeze, after 1 hour of usage. A. Some research. Model Typical Devices Device ID Auto Unlock Supports BCM94331CSAX MBP 2012 14e4:4331 NO BCM943224PCIEBT2 MBA 2011 14e4:4353 NO BCM94360CS MBP 2013 14e4:43a0 YES BCM94360CS2 MBA 2013 14e4:43a0 YES It looks like by faking dw1820a(bcm4350) into 14e4:4353 will make it looks like an 2011 mba card, and won't get Auto Unlock function. BCM433x can't use auto unlock, BCM436x can. DW1820A was BCM4350, in between of 433X and 436X. B. The new config. So instead of faking the card into 14e4:4353, and setting brcmfx-driver=1, I tried 14e4,43a0 and set brcmfx-driver=2. And that's it, nothing else changed, everything's working, including Apple Watch Auto Unlock. (It didn't work in the first place, but worked after disabling and enabling the feature again). C. Some screenshots and terminal outputs. a. kextstat|grep -y brcm b. SysInf Wi-Fi. (firmware version changed, and the Auto Unlock line comes out) c. SysInf BLE.( firmware version changed) D. Some problems. I heard some noise, maybe coil whine, after booting into the system with this new config. The noise disappeared after several minutes. I never noticed such noise before switch to this config.

Hi, I have also DW1820A part # CN-0VW3T3, but 1028:0023. I was able to get it to work by clover hack injecting: ... <key>compatible</key> <string>pci14e4,4353</string> ... it works without AirportBrcmFixup and brcmfx-driver=1. But I want to get to work also Apple Watch unlock. Problem is, that with pci14e4,43a0 system not booting. I tried it also with AirportBrcmFixup and brcmfx-driver=2, but still no luck. With brcmfx-driver=1 system boots but it says, that WIFI HW is not present. Did you use FixAirport and AddDTGP? I can work without this hack, because my path is <key>PciRoot(0)/Pci(0x1C,0)/Pci(0,0)</key>, but may be without this fixes pci14e4,43a0 not working? I just guessing. Thank you for any suggestion. BTW. I also found wifi card BCM943602CS that is newest and have 14e4:43ba, but this also not working for me.

Questions still arise about this matter so here's a recap of what caching kexts and injecting kexts (through Clover) mean: 1/ Caching kexts: Kexts placed in /L/E and/or /S/L/E are cached in the kernel cache (or prelinked kernel) which aims to accelerate boot time. This is the natural and expected mode of operation of the OS. Cached kexts are subject to signature by Apple and must be set with the correct permissions (Cf. our FAQ topics on permissions). Cached kexts will be shown/listed/registered in System Info (ex-SysProfiler) -> Software -> Extensions. Caching kexts is the recommended scheme for all add-on kexts. /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. Add-on kexts should only be placed in either folder, never in both. 2/ Injecting kexts through Clover: Injected kexts are not cached and will not be shown/listed/registered in System Info (ex-SysProfiler) -> Software -> Extensions. Injecting kexts results in a slightly slower boot than caching 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 kext cache (the kext having been properly installed in /L/E or /S/L/E). If present, no injection takes place, if absent, kext injection is performed. If kext injection is used, make sure the kexts aren't cached at the same time. 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. Apart from the obvious requirement for fresh OS X/macOS installations (and/or updates), 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. This is why -as stated on numerous occasions by Rehabman himself- Clover should really be set with kext injection in "Detect" mode and contain only the absolutely essential/minimum set of kexts required to boot the system. My own recommendation is to experiment with kexts through injection and, once kexts are validated, to cache them from /L/E. Google for this kext injection matter or consult the Clover wiki/InsanelyMac forum. It's all quite widely documented.

I've found something interesting for settings via PrefPane So, who has an empty prefPane when you installed a fresh copy of modern system 10.12+ and you want to make some settings in it. Like to enable Clicking. By default PrefPane saves it's settings in plist file located at ~/Library/Preferences/com.apple.AppleMultitouchTrackpad.plist and by default sometimes earlier you can enable Clicking via Terminal: defaults write com.apple.AppleMultitouchTrackpad Clicking -bool true but something went wrong (AAPL cheers) and a Key 'Clicking' has a wrong value format. It should be bool but has an integer. So we have to fix this issue integer --> bool Open this file with your editor.app (PlistEdit for ex) and fix this: to this and then reboot or reenter account. Voila! Your prefPane will work properly. EDIT: Also I tried to revert this value format to the wrong one (integer --> 0) and reentered acc. PrefPane worked after all. Setting 'Tap to click' was enabled but no clicking was physically. Then I tried two commands: defaults write com.apple.AppleMultitouchTrackpad Clicking -integer 1 defaults write com.apple.AppleMultitouchTrackpad Clicking -int 1 without success. Then unchecked 'Tap to click' and prefPane automatically fixed in it's plist integer (0) --> bool (false). Checked it once more to enable Clicking and voila: plist file has bool (true) and everything is working fine.