All Activity

Just to make this absolutely clear: I never said or intended to say that the KDK itself has any direct effect on Bluetooth. The important point is that my system had been running flawlessly under macOS 26.5.2 with the AX210 for five consecutive days before the update to macOS 26.6 beta 4, without a single reboot and including proper sleep/wake behaviour. Only after the sequential OTA update to macOS 26.6 beta 4 did the AX210 Bluetooth side immediately fall back to the same broken BCM_4350C2 state that existed before the macOS 26.5 Bluetooth LE fixes by @Vinhts and @Z3c0ld were incorporated into @lshbluesky’s IntelBluetoothFirmware v2.5.1 fork. I have now also cleared NVRAM and completely disconnected the system from power for about one hour, but unfortunately neither changed anything. For completeness: I am already using BlueToolFixup 2.7.2 from Dortania together with my SleepWatcher-based Bluetooth reset script after each wake. That exact setup worked perfectly before the 26.6 beta 4 update.

macOS 27 Golden Gate Beta 3 Release Notes

I’m curious now. Did you happen to clear your NVRAM? If not, could you clear your NVRAM, use my BlueWakeFixup kext, and then reboot? The KDK shouldn’t have any effect on Bluetooth. Actually, wait it could be affecting something else indirectly. I need to test that, but I’m currently busy with another project, so I’ll probably only have time to look into it over the weekend.

Easy update. On this hack, I had used this trick to enroll in Tahoe 26.6 Beta 3. The fix has remained implemented without needing to re-apply it, so I'm still able to apply incremental Tahoe 26.6 Beta Updates with SMBIOS MacMini8,1 (and Booter Patch "Skip Board ID Check"). ... And a smooth update on my HackBookPro16,2 Using HDAUniversal for outstanding audio quality on both platforms.

👍

So, I was just trying to test the effect of the -no_compat_check boot argument. The result was negative. I'll try it tomorrow on a different system unit with 10th Gen Intel a UHD630 iGPU and a Radeon RX 560x dGPU. Then I'll write back and tell you what happened.

Sequential OTA update 1.38 GB from macOS 26.6 beta 3 (25G5052e) to macOS 26.6 beta 4 (25G5057c). Apple has not yet released a Kernel Debug Kit for macOS 26.6 beta 4 (25G5057c). OCLP correctly selects Kernel Debug Kit 26.6 build 25G5052e, corresponding to macOS 26.6 beta 3, as the closest available match. Due to ongoing AirportItlwm.kext debugging, this time I was using my Intel AX210 instead of my BCM943602CDP. Before the update, the AX210 Bluetooth side was in the working state and Hackintool reported it as: Apple 0x004C / 0x6000 / THIRD_PARTY_DONGLE / FW Loaded After booting macOS 26.6 beta 4, Intel Bluetooth immediately fell back to the old broken pre-fix state: Apple 0x004C / 0x6000 / BCM_4350C2 / FW Loaded This is exactly the failure mode I had already observed several weeks ago before the recent Intel Bluetooth fixes. At that time, the issue was one of the reasons why I replaced my previous AX210 with a new card. The important point is that the AX210 Bluetooth USB controller itself is still detected as Intel 0x8087:0x0032 and firmware loading is reported as successful. The expected Bluetooth-related kexts are also loaded, including BlueToolFixup, IntelBTPatcher and IntelBluetoothFirmware. Nevertheless, the Bluetooth personality exposed to macOS has changed from the previously working THIRD_PARTY_DONGLE state back to the broken BCM_4350C2 state. Unfortunately, the faulty BCM_4350C2 state now also persists after booting back into macOS 26.5.2 (25F84). Even a complete power-off for several minutes did not restore the previous working THIRD_PARTY_DONGLE state. So this currently looks like a persistent BlueTool / IntelBluetoothFirmware / HCI personality regression triggered by macOS 26.6 beta 4, rather than a simple AX210 hardware failure. Screenshots: 1. System Information — functional state: THIRD_PARTY_DONGLE, valid Bluetooth address, State On, firmware v12490 c12490, Magic Keyboard and Magic Mouse connected. 2. System Information — broken state: BCM_4350C2, Address NULL, State Off, firmware v0 c0. 3. Hackintool — functional state: Apple 0x004C / 0x6000 / THIRD_PARTY_DONGLE / FW Loaded. 4. Hackintool — broken state: Apple 0x004C / 0x6000 / BCM_4350C2 / FW Loaded.

@MakAsrock I took a quick look at your config.plist and don't see any glaring issues, other than the fact that you're using SMBIOS MacMini8,1 with a 12th Gen Intel PC. I suspect that if you are having issues, it's more because you're attempting to use an SMBIOS for an 8th Gen Intel platform that expects an iGPU than because of your use of -no_compat_check. I would think that with 12th Gen Intel / no iGPU / dGPU that you'd be using MacPro7,1 which is supported by Tahoe.

Z97 HACK UPDATE WENT WELL FOR ME 26.6 Beta (25G5057c)

Sequoia 15.7.8 RC4 is now available. ... Easy update

Easy update from RC3 -> RC4. And no, I'm not staying with Sonoma

That might be true, but it doesn't work for me for some other reason. Perhaps it's because of the physical iGPU in the i7-12700KF, although it doesn't matter if it's there or not, since there's no corresponding driver anyway. Take a look at my config, maybe I made a typo somewhere too... config.plist.zip

@MakAsrock There are Reddit users like this Reddit user who have problems with the boot-arg, because they type it wrong. It's a common mistake. If you post the config.plist with the -no_compat_check boot-arg that is not working for you, I'd be happy to review.

MacOS 27 beta 3 (26A5378j) @miliuco, "About This Hack" is immediately moved to trash despite using Sentinel.app, Xattr-remove.app or the xattr -cr terminal command.

I'm not saying this categorically, but that's what they're saying on Reddit and it doesn't work for me as expected.

👍 26.6 Beta 4 ((25G5057c)

@MakAsrock Ok - I still didn't understand your new explanation, but no worries, because those who needed to understand probably did. What confused me was your statement that "-no_compat_check" boot-arg no longer works in Tahoe.... It does.

Ok, I'll add that to the release notes. Is this normal? 🏆 Hall of Fame slice — for general project management, profound dedication, and single-handedly rethinking the long-standing restriction on SVG clip-path counts. Resolved a critical Clover feature for OS-dependent SMBIOS injection that had been broken since January, delivering major improvements in his branch. ybronst — for comprehensive menu refactoring, quirks layout implementation, audio/GUI bug fixes, adapting the build scripts, and updating tools_def.template for full GCC 16.1 integration. MaLdOn — for initiating the GCC 16.1 transition by updating the build_gcc16.sh script in his branch. chris1111 — for creating the Tahoe, Christmas, and various other high-quality theme assets. hnanoto — for implementing ModernCpuQuirk, completing the Brazilian Portuguese (pt-BR) translations, and resolving UI build warnings. 🇧🇷

I am not only "management and dedication". This is me who provided rethinking long time restriction for number of clipPathes in SVG graphics. This is me who resolved new Clover feature with SMBIOS depending on booted OS. The bug exists since January and nobody made attempts to improve something. Except MaLdOn who at least proposed to use gcc-16.1 and made new improvements in his branch. (5200?).

You don't actually need an SMBIOS specific to your hardware. For example, I could use a MacBook Pro's SMBIOS. This wouldn't change anything except for specific hardware specific to MacBooks, such as the battery, etc. By itself, -no_compat_check does not affect the skipping of Tahoe kernel checks and if your integrated graphics are not supported in Tahoe, you probably won't be able to install it, even with the no_compat_check boot argument. Clover's behavior in terms of boot arguments has not changed for a very long time.

Hello, @Cyberdevs Regarding the issue with image generation, where it replaces the already generated image, in the latest update I added a feature that automatically saves the image by date and time of generation to prevent future replacements or image loss. I hope that with everyone's help, I can continue to refine the app every day. Best regards

Thank you, @MaLd0n. I will be able to test in a few hours and will update this post with my test status. EDIT: @MaLd0n Your logic is sound. I would have expected the mute/wait strategy to fix the Sleep audio and the wait/unmute strategy to fix Wake audio. Unfortunately, the sleep/wake "pop" did not change with your new HDAUniversal. I don't want to be difficult or cause you to go to extreme lengths to refine what is already a very good solution. I only want to help. If this is something you want to resolve and you need additional test data from me, just ask. Thanks again for your hard work on this. The audio quality is outstanding.