All Activity

Hey @mitch_de and @jsl Can you guys test the latest build, that includes some patchets for Vega/GCN cards (RX-500 series), please test with and withow both Flash Attention enable and disable it... and start first with small models, and send me the logs... It should work, "should" because I still have no way of testing it directly myself; for the moment I'm going in blind and you're guiding me. It's just that, because of the earthquake, the person who was going to send me the card can't send it yet.

Well, I like it on that computer, on both systems, Tahoe and Tahoe Beta. I've left it with that kext; we'll see how it behaves in future beta updates, which will coincide with my vacation. I've created a simple informational video on the subject. Thanks to everyone for their contribution; long live Hackintosh! Regarding your program, or rather the control of the new version, I think it's spectacular. By the way, I just got an update error in version 4. And I'm waiting to see if you're going to add monitor outputs, both outputs and FreeBuffer; that would be interesting. False alarm, now it works! That's computer science for you, haha.

@kaoskinkae My friend, the UI is the same in all audio systems. Tell me your comments about it. Thanks. EDIT: it has nothing to do with HDAUniversal.

Perfect en OLD1: It works, but I don't like the way the outputs are displayed, but it's working.

Small follow-up regarding the AX210 Bluetooth BCM_4350C2 fallback state: I was able to recover my AX210 Bluetooth side under macOS 26.5.2 after it had remained stuck in the persistent BCM_4350C2 / Address NULL / State Off state. The interesting part is that the BCM_4350C2 state was still visible even after disabling IntelBluetoothFirmware, IntelBTPatcher, BlueToolFixup and AirportItlwm, and even after physically disconnecting the AX210 Bluetooth USB cable. With only Lilu loaded and no Intel 0x8087 USB Bluetooth device present anymore, System Information still showed the stale BCM_4350C2 / UART / Address NULL Bluetooth controller. At that point, this could no longer have been the real AX210 USB Bluetooth device, but looked more like a persistent macOS IOBluetooth ghost controller. The recovery path that finally worked was: 1. Temporarily reinstall BCM943602CDP. 2. Boot the native Broadcom/OCLP EFI. 3. Let macOS initialize a real Broadcom Bluetooth controller. 4. Shut down and remove power. 5. Switch back to AX210. 6. Boot again with IntelBluetoothFirmware 2.5.1, IntelBTPatcher 2.5.1 and BlueToolFixup 2.7.2. After that, AX210 Bluetooth came back as THIRD_PARTY_DONGLE again: Address: 20:BD:1D:D8:94:32 State: On Chipset: THIRD_PARTY_DONGLE Firmware Version: v12490 c12490 Transport: USB Magic Keyboard and Magic Mouse are connected again. So this is not a code fix, but at least in my case temporarily initializing a real Broadcom Bluetooth controller cleared the persistent BCM_4350C2 ghost controller state, while NVRAM reset, deleting Bluetooth preferences and long complete power-off alone did not.

Nice congrats!!

so all changed to M Chip devices :v

I re-tested UniversalHDA and VoodooHDA.kext 4.0 (in separate test volumes) just to be sure I am accurately reporting my test results. Through multiple sleep/wake cycles, macOS silently enters/exits sleep when using VoodooHDA.kext 4.0, but makes a loud "pop" with UniversalHDA. This is not enough of a problem to warrant much effort (my opinion), but I'm just reporting in case you want to fix. Note my tests are performed after updating to 26.6 Beta (25G5057c). The previous test was performed with 26.6 Beta (25G5052e). Attached are new logs collected with HDAUniversal-Collector after repeated sleep/wake cycles using HDAUniversal. The zip generated by Collect-HDAUniversal.command: attached Your codec model: Conexant CX20632 Your layout-id: 20 macOS version: 26.6 Beta (25G5057c) Bootloader used: Open Core 1.0.7 Whether the kext is installed in /Library/Extensions: Yes A clear description of the problem: On transition to sleep, audio generates a loud "tick"/"pop"; On wake, audio generates a loud "tick"/"pop". I do not observe this with VoodooHDA 4.0 or with AppleALC/AppleHDA. Steps to reproduce the issue: Sleep and listen for loud "tick"/'pop"; Wake and listen for loud "tick"/"pop" EDIT: Note that when using VoodooHDA.kext 4.0, the HP EliteDesk 800 G4 Mini requires DisableInputMonitor=True to avoid loud "pop" on macOS startup. EDIT2: @MaLd0n I think I have additional information that might offer a clue about what's going on. With HDAUniversal when my HP EliteDesk 800 G4 Mini enters sleep, the audio is not "completely off." When sleeping with HDAUniversal, there is an audio "buzzing" (from the speakers) that modulates in sync with the flashing power LED (flashing during sleep). With VoodooHDA, the audio is completely silent - there is no audio "buzzing" sound from the speaker when sleeping. HDAUniversal-Test-Logs-2026-07-07_15-26-06.zip

@kgp At the risk of keeping you up until 4am again , those of us using Intel Wi-Fi/Bluetooth on a regular basis should accept the fact that there will be limitations with Intel. Note that I'm not having any issues with AX201 Bluetooth and Tahoe 26.6 Beta (25G5057c), but it wouldn't surprise me that Intel behavior varies with different models (e.g., AX210).

I use the same config during installation and subsequent use. 😉🫠

After switching back to my BCM943602CDP, the Broadcom/OCLP setup works under macOS 26.6 beta 4 as expected. AppleHDA, Wi-Fi, native Bluetooth, AirDrop, AirPlay, Screen Mirroring, Continuity Camera, Personal Hotspot and sleep/wake appear to be fine. I have not observed any macOS 26.6 beta 4-specific regression with the BCM943602CDP/OCLP setup so far.

@miliuco, many thanks for your immediate feedback! 🤗 First, one observation I already observed quite a while ago: when downloading About.This.Hack-4.3.9-glass.zip. the included app is also named About\ This\ Hack.app and no longer About\ This\ Hack-glass.app. Nevertheless, the included version is definitely the glass version. What worked for me after downloading the app: 1.) codesign --force --deep --sign - \ About\ This\ Hack.app/Contents/Frameworks/Sparkle.framework codesign --force --deep --sign - \ About\ This\ Hack.app 2.) Subsequently dropping the app into the Sentinel.app or Xattr-remove.app This solved my issue with the app under macOS 27 beta 3. The same approach also worked for Download Full Installer 4.5.3:

@LockDown Yes, I have read it too, but also the contrary. I’ve tried both commands with no difference, Xattr-remove runs the whole command, I’ll test it again.

That's exactly what I'm saying in the post, but I asked to see if it's possible somehow, but I don't think so.

I read somewhere to avoid --deep when targeting Sparkle🤔

Many thanks for the clarification and comments on my original post, @Mirone! You are right that the placement of the KDK note directly before the Bluetooth regression description may have unintentionally suggested a connection between the two. That was not my intention. The KDK information was only meant as general update context for the macOS 26.6 beta 4 OTA report, as I usually document the selected KDK after each sequential update. It was not intended to suggest any connection between the KDK selection or OCLP root patches and the Intel Bluetooth regression. The Bluetooth issue is unrelated to both and should be treated separately, as it has been handled so far anyway. The Bluetooth part was meant as a separate observation: after booting macOS 26.6 beta 4, my AX210 Bluetooth side fell back from the previously working THIRD_PARTY_DONGLE state to the broken BCM_4350C2 / Address NULL / State Off state. Your comment that you know why Bluetooth devices show up as BCM_4350C2 when Bluetooth stops working is actually very helpful. If you find the time, I would be very interested in understanding what exactly causes this fallback state, since it matches the old pre-fix failure mode I had observed before. Maybe you also know whether there is a way to recover from this state without replacing the card with another one?

Well. Im used to installing an OS on a running OS. And since my running OS already has the svbmm flag, i never thought i would be needing it on a USB install method 😀 Do you consider that as a trick? Dont think so 😜✌️

Hello my dear friends, @miliuco I used VS Code with Copilot to compile About This Hack with Xcode because I prefer the hidden serial number to open as a native option. I only had to grant permission in Sentinel and didn’t need to sign the application. It opened normally on Golden Gate Beta 3. Regards

If you're using Open Core, just create GUID formatted USB with a custom EFI and boot from the USB for your test. If you're using CLOVER, you can add another config.plist and select at boot.

You didn't explicitly say that the KDK affects Bluetooth, but that's clearly the impression your reply gave. You stated, "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..." and then immediately went on to describe your Bluetooth issue. It's only natural that someone would connect the two. It may have been just a misunderstanding, but that's not really the point here. I haven't had the time to look through that GitHub link or the changes made to the IntelBT kext yet, although I do know why Bluetooth devices always show up as BCM_4350C2 when Bluetooth stops working. In any case, thanks for sharing it. Hopefully it'll be fixed soon and your Bluetooth will be working again.

I am using that on any macOS since Ventura. I couldn't imagine that someone wouldn't know about this trick. 😜

@kgp Indeed, xattr quarantine removal is not enough to run the app, but re-signing app and Sparkle does the job. Checking re-sing the app in Xattr-remove, I am able to run ATH as expected. This does the same as code signing Sparkle and app in your own machine: codesign --force --deep --sign - \ About\ This\ Hack-glass.app/Contents/Frameworks/Sparkle.framework codesign --force --deep --sign - \ About\ This\ Hack-glass.app I suppose that you must have at least one Apple account in Xcode settings or in the Keychain to this task to work.

I am using that on a already installed OS but not during install. Never thought the issue i posted above will fix it