All Activity

Hello everyone, for those who like to make life easier, I've updated VoodooHDA Builder to the new kext and added a button to remove the old VoodooHDA and PrefPane. Have fun! https://github.com/maxpicelli/VoodooHDA-Builder/releases/tag/1.1.0 All doing smooth Thanks @Slice @chris1111 and all devs!! @MaLd0n too!!

Fix some things to post here for test. I'm working on this I'm working on this

Yes!! Will be nice !! Thanks!! Grazie!!

Tried and it seems like it works but then Digital Audio (HDMI/DP) doesn't shows up ;( AppleALC works but it has only HDMI/DP working

@MaLd0n this sounds great! Is this version available for download?

Welcome! Nice to see you're sticking around even after the Hackintosh era. I'm sure your experience will still help a lot of people like me here. FNF

I'm waiting for users who own a Mac with a dual-die chip to test the app and see if it works well.

Do you think it makes sense to create widgets? If so, which ones? I look forward to your suggestions and will implement them.

HDAUniversal v0.1.353 — PCM Test Results I individually tested all 12 PCM formats currently available on the analog output. Formats tested Sample rate Bit depths 44.1 kHz 16, 20 and 24-bit 48 kHz 16, 20 and 24-bit 96 kHz 16, 20 and 24-bit 192 kHz 16, 20 and 24-bit 32 kHz is not available as an output format on this device, so I did not test it. 32-bit is also not exposed as a native physical bit depth on this output. Results All 12 selected formats were accepted by IOAudioFamily and HDAUniversal: performFormatChange: 12 occurrences setFormat returned 0x0: 12 occurrences setFormat failures: 0 The 20-bit formats were correctly transported inside a 32-bit container: fBitDepth = 20 fBitWidth = 32 The 24-bit formats also correctly used a 32-bit container: fBitDepth = 24 fBitWidth = 32 Physical readback proof The final selected format was 192 kHz, 24-bit, stereo. The physical stream readback confirmed: rate=192000 depth=24 width=32 fmt=0x1831 fmtok=1 swrun=1 hwrun=1 pos=!0 cblok=1 bdlok=1 The codec converter confirmed the same format: stream=0x10 fmt=0x1831 path=0x14>0x0c>0x02 pinctl=0x40 eapd=0x02 complete=1 Real non-zero PCM data was also captured during playback: nz=7288 peak=35750656 rate=192000 depth=24 fmt=0x1831 Stability results The Playback Blackbox reported: playback anomaly: 0 repeated-window: 0 stagnant-position: 0 timeout: 0 underrun: 0 overrun: 0 xrun: 0 clip-guard: 0 clip-normalize: 0 select failed: 0 Conclusion The complete native output matrix of 44.1, 48, 96 and 192 kHz at 16, 20 and 24-bit passed the format programming, physical readback, DMA and playback stability tests. No driver, IOAudioFamily, DMA, timeout, underrun, overrun or xrun failures were recorded.

AirportItlwm, OCLP, AWDL and AirDrop on Intel AX210 What actually works, what this experimental branch implemented, what remains unresolved, and why reproducible Intel AirDrop is not a small patch Experimental-fork technical status report and conclusion KGP — July 2026 IMPORTANT NOTE This is not a release announcement and it does not claim a complete, reliable or reproducible Intel AWDL or AirDrop implementation. The work described below produced a detailed source- and runtime-grounded map of the existing Apple/OCLP/AirportItlwm architecture, implemented and validated several isolated Intel AWDL building blocks, and identified the principal unresolved areas and plausible paths toward a clean implementation. The controlled Builds 2.3.131–2.3.195 did not produce a user-ready Kext, remote AirDrop visibility of the Hackintosh, or reproduce a reliable AirDrop file transfer. This does not erase an earlier isolated one-time Hackintosh-to-MacBook Pro transfer observed under a different OCLP-modified AirportItlwm state. The current experimental branch should therefore be treated as research code, not as a daily-driver replacement for the official AirportItlwm releases. POST-PUBLICATION AUDIT NOTE — JULY 2026 A subsequent read-only comparison of official AirportItlwm v2.3.0, the Dexter source baseline, the OCLP-restored Apple environment and Builds 2.3.131–2.3.195 clarified an important methodological distinction. The experimental branch tested a newly constructed explicit Intel AWDL management-plane architecture, not a proved reconstruction of the rare historical one-time-transfer path. The report has therefore been revised to narrow several conclusions. The recorded source identities and runtime milestones remain unchanged. 1. WHY I AM PUBLISHING THIS REPORT Over the past weeks I have been investigating why AirportItlwm can operate inside an OCLP-restored modern macOS wireless environment, why the restored Apple stack exposes substantial AWDL machinery, why the experimental branch can create an active awdl0 interface with Intel Wi-Fi, and why AirDrop nevertheless remains nonfunctional as a reliable and reproducible Intel feature. The project grew far beyond a simple trace or a single missing callback. The final experimental Build 2.3.195 is 100 commits beyond the exact DexterSLamb baseline from which this work began. The aggregate retained source delta is approximately 11,636 insertions and 171 deletions across 11 files. A total of 65 numbered builds, from 2.3.131 through 2.3.195, were used to decompose the problem into independently observable layers. That effort deserves a clear public result even though it did not end with reproducible working AirDrop. This report is intended to answer the questions that are usually obscured by the simplified statement “AirportItlwm does not support AWDL”: - Why does an OCLP configuration with Intel Wi-Fi work as far as it does? - What exactly is supplied by OCLP? - What is Apple code rather than OCLP code? - What already existed in stock/OpenIntelWireless/Dexter AirportItlwm? - What was added in this experimental KGP branch? - Which parts were genuinely proven at runtime? - Which parts exist only in source or as diagnostic laboratory code? - What remains unresolved, incomplete, or not reproducibly demonstrated? - Why can no credible completion schedule currently be given? The central conclusion is that the system already contains much more Apple AWDL infrastructure than one might expect. The controlled source and runtime investigation did not identify or demonstrate a coherent and production-safe AirportItlwm bridge between Apple’s existing AWDL upper plane and Intel’s firmware-facing scheduling, station, queue, packet-ownership, completion, and RX-delivery mechanisms. The earlier isolated transfers show, however, that an outbound transfer with the official release did occur under an unidentified state. They do not identify a reproducible transport path or establish that the later KGP architecture represented that state. No single explanation currently dominates: Apple-owned peer/flow behavior, generic AirportItlwm resources, temporary or lifecycle-dependent state, genuine peer-to-peer use of generic lower mechanisms, and another Apple-controlled transport decision all remain unresolved and may overlap. 2. TEST AND SOURCE CONTEXT The final controlled runtime described here used: - Intel AX210 Wi-Fi - AirportItlwm Ventura target - macOS 26.5.2, build 25F84 - OpenCore with the OCLP 3.0.0 amfipassbeta compatibility environment - an active infrastructure Wi-Fi connection - a separate working Intel Bluetooth stack - Apple devices used as references: MacBook Pro M1, iPhone 16 Pro and iPad Pro M4 - a Broadcom BCM943602CDP configuration as the known-working OCLP/AWDL reference Historical runtime baseline: AirportItlwm_v2.3.0_stable_Ventura.kext.zip All preceding-month KGP runtime use and the historical one-time transfer used this official OpenIntelWireless release asset. Dexter was not the deployed historical runtime baseline. Authoritative source identities: Official OpenIntelWireless v2.3.0 source: 4ac4c79bc7e34f8764038fc382630a29eb46213d Exact pre-KGP Dexter baseline: 51543d6cfecf8aae3f66792b0699f5a1bb16a368 Final experimental AirportItlwm commit: 0b17225dfbe1b7810b114f8fa9148b09f56d4efd Final branch: kgp-awdl-manual-gated-multi-transaction-2.3.195 Final tag: active-awdl-manual-gated-multi-transaction-2.3.195 Final Kext UUID: 814E8EE1-E63F-3C13-B4B9-78F208CC1450 Final executable SHA-256: 5928a759458f9a33ed4b85a95abc448894e9bc5eef7cd1cc9a8d5cd165251970 OCLP-amfipassbeta source inspected read-only: Branch: main HEAD: b0840696ce6f3fa9dc8892bd3ec5e4c597f24537 Tag: 3.0.0-amfipassbeta-tahoe Tag target: b0bd23b37c623d310bdca02c6225cdd32a39bb3f A direct read-only comparison established that official 4ac4c79 and Dexter 51543d6 have identical Ventura target source, build settings, plist, AWDL/P2P callbacks and generic packet paths at the compared commits. Dexter’s runtime source delta is in the Sonoma V2 LQM path and is not compiled into the Ventura target. Dexter was therefore a valid later development source baseline for this Ventura experiment, but it was not the runtime baseline for explaining the historical official-release transfers. 3. THE MOST IMPORTANT DISTINCTION: OCLP, APPLE, AIRPORTITLWM AND THE HARDWARE The word “OCLP” is often used for several different layers at once. That makes the current Intel behavior sound more mysterious than it actually is. The architecture must be divided into at least four separate responsibilities. 3.1 What OCLP itself contributes The OCLP patcher is primarily a deployment and compatibility tool. It detects the operating system and hardware situation, selects patch sets, routes payloads, restores compatible components, applies root patches, and creates an environment in which legacy or removed Apple networking components can run on a newer macOS release. For the later Tahoe environment relevant here, the inspected patching selected Ventura 13.7.2-generation wifip2pd, IO80211.framework and WiFiPeerToPeer.framework, together with restored Legacy/Skywalk Kext components. Some newer-host components remained native; the specific extended CoreWiFi/CoreWLAN replacement path inspected in the audit was not selected on that Tahoe host. The resulting runtime was therefore a hybrid rather than a complete replacement by one OS generation: - a newer Tahoe host and some native host components - restored Ventura 13.7.2-generation wifip2pd and private frameworks - restored IO80211FamilyLegacy and IOSkywalkFamily components - a user-selected Ventura-ABI AirportItlwm Kext OCLP does not execute Intel MAC/PHY commands. It does not allocate an AX210 station or queue. It does not request an Intel Time Event. It does not submit a frame to TXQ4. It does not receive an Intel RX descriptor and deliver the resulting packet to awdl0. In other words: OCLP materially determines the restored Apple runtime environment. It is not the runtime AX210 AWDL driver. The inspected OCLP source does not select or bundle AirportItlwm-Ventura itself; the user’s OpenCore configuration selects the AirportItlwm artifact. 3.2 What Apple contributes at runtime Most of the higher-level AWDL and AirDrop machinery is Apple code, not code written by OCLP and not code written by AirportItlwm. The restored Apple environment includes or exposes: - wifip2pd, Apple’s peer-to-peer/AWDL daemon - IO80211.framework - WiFiPeerToPeer.framework - CoreWiFi/CoreWLAN integration - IOSkywalkFamily networking infrastructure - IO80211FamilyLegacy - IO80211AWDLPeerManager - IO80211 virtual-interface and P2P interface classes - Finder and AirDrop service logic - peer lifetime and data-mode machinery - native flow queues - packet preparation - AWDL SNAP/header handling - multicast policy - transmit status/completion interfaces - receive-input interfaces - higher-level IPv6, mDNS and service behavior once a usable lower data path exists Exact analysis of the restored IO80211FamilyLegacy binary confirms that Apple already contains substantial generic AWDL peer and packet machinery. This is not merely a collection of empty method names. The binary contains peer lifetime, data mode, flow, packet preparation, multicast, dequeue, RX and completion behavior. That is one of the most important positive findings of this project: The evidence does not support reimplementing the complete Apple AWDL peer and service stack from scratch. Substantial Apple-owned machinery is already present and should be reused through validated interfaces wherever possible. However, Apple’s upper plane still expects the hardware driver below it to perform the driver-specific work correctly for any genuine Intel AWDL path. 3.3 What the Broadcom spoof does — and what it does not do The Broadcom-oriented matching and compatibility environment can help macOS and OCLP select or expose the expected Apple wireless components and properties. Depending on the exact EFI and patching arrangement, a Broadcom-style device identity or property may therefore be useful as an enablement mechanism. It is not a command translator. It does not turn the AX210 into a Broadcom chipset, and it does not cause Broadcom firmware commands to become Intel commands. AirPortBrcmNIC is inseparably tied to Broadcom-specific assumptions, including: - Broadcom PCI register behavior - Broadcom firmware loading and initialization - Broadcom DMA and ring structures - Broadcom wl/wlc/d11 structures - Broadcom IOVARs - Broadcom event and completion paths - private Broadcom driver object state Changing a device ID or provider match would only make Broadcom code inspect Intel hardware through the wrong hardware ABI. A “thin wrapper” beneath AirPortBrcmNIC would have to emulate most of a Broadcom chipset and firmware contract. That would be larger, more fragile, and less defensible than implementing the required Apple-facing behavior directly in AirportItlwm. The useful Broadcom contribution is therefore not reusable hardware code. It is a behavioral reference: - ordering - lifecycle - peer presence and removal - queue ownership - completion semantics - channel scheduling behavior - RX delivery behavior Broadcom can be used as an A/B behavioral oracle. Linux iwlwifi can be used as the primary reference for Intel firmware mechanics. Neither implementation can simply be copied wholesale into AirportItlwm. 3.4 What AirportItlwm contributes AirportItlwm remains the actual AX210 hardware driver. The runtime path is conceptually: Finder / AirDrop / wifip2pd | v Apple frameworks and IO80211FamilyLegacy | | Apple controller, VIF, peer and packet contracts v AirportItlwm | | Intel MAC / PHY / binding / station / queue / | Session Protection / Time Event / TX / RX commands v Intel AX210 firmware and hardware For normal Wi-Fi, AirportItlwm already performs the required Intel driver work. For AWDL, the baseline contained useful scaffolding and generic Intel primitives, but no coherent end-to-end bridge was identified. This experimental branch added many management-plane components and diagnostics, but no complete, understood and reproducible bridge was identified or demonstrated in the inspected source and controlled runtime. The earlier one-time transfer proves that an outbound transfer occurred, but it does not identify whether the runtime used a hidden/generic peer-to-peer equivalent, a temporary state, or another transport decision. 4. WHAT OFFICIAL/DEXTER AIRPORTITLWM ALREADY PROVIDED The official v2.3.0 Ventura source and the exact pre-KGP Dexter Ventura baseline were identical in the relevant target at the compared commits. This baseline was not an empty project and it was not missing all ingredients. It already provided: - working ordinary Intel infrastructure Wi-Fi - scanning, authentication and association - the normal Intel command transport - generic TX and RX ownership - reset and lifecycle infrastructure - generic Intel Time Event mechanisms - generic Session Protection mechanisms used by normal association - virtual-interface scaffolding - Apple method declarations and partial AWDL callback surfaces - basic P2P/AWDL placeholders The important source-visible limitation was that these pieces were not assembled into a complete AWDL implementation. The exact Ventura block was narrower than the broad statement “official AirportItlwm blocked AWDL”: official Ventura v2.3.0 returned kIOReturnUnsupported from one legacy setVIRTUAL_IF_CREATE() setter path before the older explicit P2P/AWDL allocation body. Separate source-visible gaps included: - requestPacketTx did not perform native virtual-packet dequeue and handoff - raw/action/BPF output paths dropped packets - no complete Intel AWDL scheduler was visible - no visible RX demultiplexer delivered packets to awdl0 - several AWDL callbacks were shallow stubs, logs, or state copies - peer registration did not create coherent Intel peer state - P2P scan/listen/GO operations remained stubbed - no dedicated and coherent peer-specific AWDL Intel station lifecycle was identified - no dedicated and coherent AWDL peer-data queue mapping was identified - no complete and reproducible Apple packet-dequeue/ownership/completion bridge was identified - no explicit and reproducible RX demultiplexer delivering AWDL packets to awdl0 was identified - no reliable and reproducible awdl0 L2 data path was demonstrated The baseline nevertheless mattered greatly because it already contained the reliable ordinary Wi-Fi driver and the generic Intel building blocks on which all experiments depended. These source gaps do not prove that every Apple-superclass, temporary, generic, lifecycle-dependent, binary-specific or alternate-transport runtime path was impossible. Source absence is not runtime impossibility, and the rare historical official-release transfers were not captured well enough to identify their mechanism. 5. WHAT THE KGP EXPERIMENTAL BRANCH ADDED This branch should be understood as a research branch containing several different kinds of work: - functional lower-plane additions - source-present but runtime-unproven paths - bounded active experiments - diagnostic instrumentation - safety infrastructure - superseded experiments retained for evidence or later reuse It would be misleading to classify all 11,000-plus added lines as working AWDL support. Builds 2.3.131–2.3.195 chiefly constructed and tested one plausible explicit clean-room Intel AWDL management-plane architecture. The branch began by enabling a Ventura path that the official target rejected through the early return in setVIRTUAL_IF_CREATE(). It subsequently added its own VIF attachment/lifecycle, Intel P2P PHY/MAC/binding, Station 3, TXQ4, scheduling, timing, Time Event and safety architecture. The experiment did not establish that this architecture was the path used by the official release during the historical one-time transfers. 5.1 AWDL virtual-interface lifecycle The narrow, evidence-backed statement is: “The KGP branch first enabled and runtime-proved its explicit Ventura setVIRTUAL_IF_CREATE/attach/enable/link-state AWDL VIF path, and later its separate experimental Intel lower-context setup.” This is not the universal claim that KGP first enabled AWDL. The branch’s explicit virtual-interface path included: - creation of IO80211P2PInterface - assignment of the AWDL role - attachment - enable/disable handling - link-state publication - reset/state integration Runtime proof: - awdl0 was created - awdl0 was UP - awdl0 was RUNNING - awdl0 reported active - an IPv6 link-local address was assigned This is a real improvement over the baseline. It is not proof of a usable AWDL packet path. An interface can exist, have link state, and receive an IPv6 link-local address while no bidirectional L2 traffic is possible. 5.2 Apple upper-plane callback capture The branch made the Apple upper-plane interaction observable and coherent. It captured or tracked: - OOB requests - synchronization parameters - synchronization sequence - channel sequence - profile data - AF_TX_MODE - management-frame templates - template generations and refresh - requestPacketTx demand - interface and peer-registration-related callbacks These runtime callbacks prove that the restored Apple upper plane is not merely sitting unused on disk. Apple is actively trying to configure and use the driver. They do not prove that AirportItlwm correctly translates every request into Intel firmware behavior. 5.3 Exact Apple AWDL RX classification and timing The branch added bounded early and late RX classification for: - management frames - action frames - vendor-specific action category 0x7f - Apple OUI 00:17:f2 - AWDL OUI type 0x08 - frame length and bounded copies - TLV parsing - TLV 0x04 channel-sequence/timing information - peer source address - local-MAC rejection - channel and frequency - MAC/PHY context - generation and reset generation - TSF and GP2/host timing This path produced genuine runtime results in earlier controlled builds and in Build 2.3.193. The project therefore did not merely infer AWDL traffic from a Finder window. It captured and parsed exact Apple AWDL action frames when the radio and driver actually received them. 5.4 Intel P2P lower context The branch implemented a staged Intel lower context for the AWDL/P2P device role: - PHY1 - P2P Device MAC1 - binding of MAC1 to PHY1 - channel 6 configuration - generation tracking - coherent partial-prefix handling - broadcast Station 3 - management TXQ4 - reset and teardown state - a failed-closed latch for incoherent partial setup Build 2.3.195 proved that the complete configured and bound context could be created successfully and without a generation change: phy_modified = 1 mac_added = 1 binding_added = 1 sta_added = 1 queue_enabled = 1 Station ID = 3 TXQ = 4 ready = 1 This is a meaningful lower-plane result. It proves configuration and binding. It does not prove that the shared radio was actually scheduled onto channel 6 during the later receive window. Station 3 and TXQ4 were plausible and experimentally validated lower resources for the explicit KGP architecture. They have not been proved to be universal prerequisites for every possible outbound transfer or for the historical one-time events. 5.5 Session Protection and channel scheduling experiments The branch used Intel Session Protection as a bounded P2P/AWDL scheduling mechanism. Earlier Build 2.3.166 produced: - a successful Session Protection command - a successful start notification - an explicit channel-6 receive opportunity Build 2.3.167 then recorded several valid channel-6 Apple AWDL timing entries from multiple peers. A separate Build 2.3.193 runtime also recorded one Session Protection command and one successful start. These results prove that the Intel firmware contains a usable scheduling mechanism. They do not yet provide a stable production scheduler that continuously translates Apple’s AWDL timing requirements while safely coexisting with infrastructure Wi-Fi. 5.6 Management-frame template, Station 3/TXQ4 submission and completion Apple supplied a synchronization/management template through its upper callbacks. The branch captured, validated, refreshed, and used the template to prepare an Apple vendor-action management frame with: - broadcast destination ff:ff:ff:ff:ff:ff - management action subtype - category 0x7f - Apple OUI 00:17:f2 - AWDL type 0x08 - Intel broadcast Station 3 - Intel management TXQ4 Earlier Builds 2.3.168 and 2.3.169 proved isolated, bounded management submissions and matching TX completions through TXQ4. That is genuine TX evidence. It validates these resources inside the KGP experiment; it does not establish that the official historical path required or used the same station and queue. It is not proof of a complete AWDL advertisement. Those submissions were isolated experiments, not the final sequence of: scheduler window -> accepted Time Event response -> nonzero UID -> matching Event Start -> correctly timed management submission -> completion -> repetition -> remote Apple-device visibility 5.7 GP2 timing, peer anchor and next-AW reservation Build 2.3.188 added coherent peer phase/TLV capture. Subsequent builds connected that information to timing correlation and a bounded next-AW reservation. The most important positive runtime milestone was Build 2.3.193. It recorded: - a genuine Apple AWDL frame on channel 6 - presence mode 4 - AW period 16 TU - 63 TU to the next availability window - coherent Apple callback/profile state - coherent driver and reset generations - all required technical predicates true - approximately 2 microseconds from RX classification to reservation - approximately 63.805 milliseconds of forward command lead - reservation return 0 - task_add return 1 - entry into the real worker/command stage This proved that the branch could take a real peer timing frame and transform it into a coherent Intel-side reservation decision. The attempt still did not produce: - a valid firmware UID - an accepted Event Start - management TX through the final pipeline - remote visibility 5.8 Correct Intel Time Event response parsing Build 2.3.194 corrected a fundamental host-side interpretation error. The previous path treated numeric status zero as success. Analysis of the Intel firmware contract showed that success requires: - documented success bit 0 set - no documented error bits - exact response payload length - a nonzero UID Build 2.3.194 corrected the relevant helpers and added immutable transaction evidence. This correction is source- and model-proven. It remains runtime-unproven because Build 2.3.195 stopped before entering the Time Event helper and therefore never exercised the corrected response parser. 5.9 Build 2.3.195 manual safety and diagnostic framework After earlier automatic active experiments caused uncertainty around resets, timing, and system stability, Build 2.3.195 deliberately converted the current path into a strictly controlled laboratory experiment. It added: - a 300-second continuous quiet/stability period - READY-FOR-MANUAL-TRIGGER state - a private privileged userspace command - an exact version and monotonic nonce - one-shot semantics - LOWER-SETUP-IN-PROGRESS - a bounded five-second lower-setup stage - a fresh three-second post-setup peer window - automatic-attempt suppression - no automatic retry - no automatic reservation - no automatic Time Event - no automatic TX - eight immutable transaction slots - bounded explicit STATUS publication - reset-preserved evidence - a helper utility for status and trigger control These mechanisms worked as designed in the final test. They are not a production AWDL architecture. They are laboratory safety and evidence machinery. 6. WHAT THE FINAL BUILD 2.3.195 TEST ACTUALLY PROVED The final controlled test is easy to misdescribe, so the exact boundary matters. Build 2.3.195 successfully proved: - the intended Kext and UUID were loaded - ordinary infrastructure Wi-Fi remained operational - Bluetooth remained operational - IOSkywalkFamily and IO80211FamilyLegacy were loaded - wifip2pd/IO80211 user-client activity occurred - awdl0 was UP, RUNNING and active - the 300-second quiet period completed - the state reached READY-FOR-MANUAL-TRIGGER - exactly one privileged trigger was accepted - lower setup ran - PHY1, MAC1, Binding1, Station 3 and TXQ4 were successfully created - the complete lower-context predicate returned ready - no transaction slot was consumed during setup - the state entered ARMED-WAITING-FOR-POST-TRIGGER-PEER - the attempt failed closed and safely when its peer window expired - all automatic background attempts remained suppressed The final test did not prove or test: - an active channel-6 scheduling grant during the three-second peer window - the corrected Time Event response parser - a valid firmware UID - Event Start - management TX - TX completion - remote visibility - the Apple peer data plane - AirDrop transfer The final failure was: POST-TRIGGER-PEER-TIMEOUT The lower PHY1/MAC1/Binding1/Station 3/TXQ4 context was configured and validated, but no active channel-6 scheduler grant or physical channel-6 dwell was proved during the fresh three-second post-trigger window. The earlier Session Protection producer had deliberately been made passive for Build 2.3.195. The timeout therefore constrains only that exact manual KGP sequence: configured lower context, no proved receive dwell, and a conservative requirement for a fresh post-setup peer. It was not: - a Station 3 failure - a TXQ4 failure - a Time Event failure - a firmware-response-parser failure - a TX failure - a completion failure Those later stages were never entered. 7. WHY THE MACBOOK CAN BE VISIBLE ON THE HACK WHILE INTEL AWDL IS STILL INCOMPLETE The Hackintosh could see Apple devices in its AirDrop window before this project began. That observation was never presented as a new Build 2.3.195 success. The final runtime contained thousands of management frames, but only two action frames. Both were category 0x03 on the infrastructure context and channel 36. During the relevant final window: - exact Apple category 0x7f count remained zero - Apple OUI count remained zero - AWDL OUI type 0x08 count remained zero - early exact AWDL count remained zero - late exact AWDL count remained zero - genuine peer commit count remained zero - timing-anchor count remained zero The AirDrop UI can be influenced by information outside this exact current Intel AWDL RX path, including retained/cached service state, BLE-assisted discovery, or another Apple discovery source. The preserved evidence does not identify which source produced the local MacBook entry. Therefore the correct conclusion is: The local AirDrop UI proves that macOS had enough discovery state to display the MacBook. It does not prove that the AX210 received a fresh exact AWDL synchronization frame during the controlled window, and it does not prove a usable AWDL data path. 7.1 IMPORTANT HISTORICAL EXCEPTION: ISOLATED ONE-TIME AIRDROP TRANSFERS Before the controlled Builds 2.3.131–2.3.195 were developed, I completed one real AirDrop transfer from the Hackintosh to a MacBook Pro while using the official AirportItlwm_v2.3.0_stable_Ventura.kext.zip under an earlier OCLP-modified environment. The Hackintosh was not visible as an AirDrop destination on the MacBook Pro, but the MacBook Pro was visible on the Hackintosh and the transfer completed once. Other isolated reports, including one in OpenIntelWireless/itlwm Issue #1062, exist under different OCLP codes or variants. Across the reports presently known to me, only a handful of isolated successes exist, approximately four reports at most. This is an approximate count of presently known reports, not a universal statistic. No report has become a reliable procedure, and no synchronized successful runtime capture exists. These observations have two important but separate meanings: - they prevent a categorical claim that an outbound transfer with official AirportItlwm never occurred or was absolutely impossible; - their rarity and missing evidence make them unsuitable as a reproducible experimental or development baseline. The exact system state, interface, channel, route, packet path and transport decision were not identified. The reports occurred under different OCLP variants, which weakens any claim that one uniquely identified OCLP build alone explains them. Even many later failed attempts would establish only that the event is exceptionally rare under tested conditions; they would not falsify the historical observations. The correct conclusion is therefore not that Intel AirDrop is categorically impossible, and it is not that a known transient partial path can simply be stabilized. Current AirportItlwm does not provide a complete, understood, reliable or reproducible AWDL/AirDrop implementation, while the mechanism of the isolated official-release transfers remains unknown. 8. CURRENT FUNCTIONAL STATUS The following summary separates ordinary networking from genuine AWDL support. 8.1 Working and preserved Infrastructure Wi-Fi: - WORKING - Supplied by stock AirportItlwm plus Apple’s normal Wi-Fi/network stack. Scanning, authentication, association and DHCP: - WORKING - These are normal infrastructure functions and were preserved throughout the final experiment. Bluetooth: - WORKING in the controlled setup - Supplied by IntelBluetoothFirmware and Apple’s Bluetooth stack, not by the AirportItlwm AWDL implementation. Sleep/wake: - WORKING for ordinary tested use - Full AWDL peer/station/queue recovery and long-duration stress remain unproven. AirPlay and Screen Mirroring: - WORKING in the tested Intel configuration - These services can operate over infrastructure networking and therefore do not prove a usable Intel AWDL data plane. 8.2 Working as an upper plane or isolated building block Restored Apple AWDL upper plane: - WORKING as an active upper plane - Apple callbacks, profiles, templates and demand are present. awdl0 interface lifecycle: - WORKING - Interface creation, role, attachment, enablement and link state are proven. Exact Apple AWDL frame classification: - PARTIALLY WORKING - Proven when matching frames actually reached the Intel RX path, but reliable receive scheduling does not exist. TLV 0x04 parsing and peer timing extraction: - WORKING for received matching frames. P2P PHY1/MAC1/binding: - WORKING as configured and bound firmware contexts. Station 3 and TXQ4: - WORKING as lower resources. - Isolated bounded management submission/completion was proven in earlier builds. - They are plausible, validated resources within the explicit KGP architecture, not proved universal requirements for the historical or every possible outbound path. Session Protection: - PARTIALLY WORKING - A bounded start was proven; stable integration is missing. Next-AW reservation: - PARTIALLY WORKING - One coherent Build 2.3.193 reservation was proven. Corrected Time Event response parser: - SOURCE-IMPLEMENTED, RUNTIME-UNPROVEN. Event Start matching: - SOURCE-IMPLEMENTED, RUNTIME-UNPROVEN. One bounded management TX and completion: - PARTIALLY WORKING as an isolated experiment. - Not proven through the final end-to-end scheduling pipeline. 8.3 Present but not functional as a complete feature Reliable AWDL channel scheduling: - Intel primitives and isolated experiments exist. - No stable and reproducible production policy mapping Apple’s schedule to recurring, safe Intel channel occupancy was demonstrated. Repeated management advertisements: - Earlier experimental source existed and was later constrained and suppressed for safety. - No reliable and reproducible advertisement loop was demonstrated. Remote visibility of the Hackintosh: - NOT ACHIEVED in the controlled experiments. awdl0 L2 packet path: - No reliable and reproducible bidirectional path was demonstrated. - The one-time transfer means that a transient partial path cannot be excluded. AWDL IPv6: - A link-local address exists. - No reliable and reproducible bidirectional AWDL packet transport was demonstrated. mDNS over AWDL: - No reliable or reproducible AWDL mDNS transport was demonstrated by the controlled experimental branch. - The earlier one-time transfer prevents a categorical claim that no transient service path can ever exist. 8.4 Not demonstrated as coherent and reproducible implementations Apple peer lifecycle adapter: - No complete and reproducible Intel integration was identified or demonstrated. Peer-specific Intel firmware station: - No dedicated AWDL peer-station lifecycle was identified in the controlled path. - It remains unknown whether the one-time transfer reused another existing station or generic path. Peer-specific Intel data queue and TID mapping: - No coherent AWDL-specific implementation was identified or demonstrated. Native Apple packet dequeue and ownership: - No reproducible end-to-end path was demonstrated. - Bounded diagnostic probes did not obtain a native packet, but the earlier one-time transfer shows that another transient path cannot be excluded. Native TX completion reporting back to Apple: - No coherent and reproducible AWDL data-packet completion bridge was demonstrated. RX peer/context demultiplexing: - No explicit and reproducible implementation was identified in the inspected path. packet_info_tag construction: - No ABI-validated and reproducible implementation was identified; the exact private contract remains unresolved. IO80211P2PInterface input delivery: - No explicit and reproducible Intel AWDL input bridge was identified or demonstrated. - It cannot currently be established whether every one of these functions must be newly implemented from scratch or whether Apple and existing generic driver paths transiently supplied functional equivalents during the one-time transfer. AirDrop discovery of the Hackintosh: - No complete and reproducible remote-discovery path was demonstrated. One-way or bidirectional AirDrop file transfer: - No controlled, understood and reproducible AirportItlwm path was demonstrated. - One isolated Hackintosh-to-MacBook Pro transfer and comparable community reports demonstrate that an outbound AirDrop transaction can occur under a transient state, but its interface, transport and exact mechanism have not been identified or reproduced. Personal Hotspot through Intel AWDL: - No controlled, reliable or reproducible implementation was demonstrated. Continuity Camera through Intel AWDL: - No controlled, reliable or reproducible implementation was demonstrated. Sidecar: - No reliable service-specific conclusion can be drawn from the preserved evidence. 9. DEVELOPMENT HISTORY IN PHASES A complete Build 2.3.131–2.3.195 ledger was compiled and retained in the private technical archive. The following is the shorter architectural history. Phase 1 — Initial bridge and bounded active concepts, Builds 2.3.131–2.3.139 The first builds explored whether existing Apple callbacks could be connected to Intel Time Event and one-shot active behavior. These attempts established the scale of the problem but did not leave a reliable working active path. Phase 2 — Decomposing the Intel lower context, Builds 2.3.140–2.3.157 The lower plane was separated into individually testable components: - capability and context previews - MAC1 - PHY1 - binding - Station 3 - TXQ4 - deferred task context - generation/reset handling - persistent complete lower-context hold This phase converted a monolithic failure into a known sequence of Intel firmware operations. Phase 3 — Templates, RX, channel opportunity and first TX, Builds 2.3.158–2.3.168 This phase added: - native Apple synchronization-template capture - complete TLV capture - bounded packet-dequeue probes - raw management/action RX classification - P2P Session Protection - channel-6 peer timing records - one bounded TXQ4 management submission and matching completion Builds 2.3.166–2.3.168 established that the AX210 could be given a P2P scheduling window, could receive exact Apple AWDL traffic in that development phase, and could submit/complete a bounded management frame through Station 3/TXQ4. Phase 4 — Apple native packet and peer-manager investigation, Builds 2.3.169–2.3.184 This side-line explored: - manual late TX - multicast and unicast native dequeue - requestPacketTx selectors - peer registration and presence - PeerManager binary behavior - Event 58 state transitions - output handoff - repeated bounded dequeue - early/late RX classification The key negative result was consistent: Apple’s upper plane and pending state were visible, but no coherent native packet was obtained for Intel data TX. This phase also demonstrated that guessed private offsets and vtable calls are not an acceptable production strategy. Phase 5 — Timing, reservation, Time Event contract and manual safety, Builds 2.3.185–2.3.195 The final ancestry added: - template coherence and refresh - GP2 timing - exact peer/TLV phase - next-boundary Time Event logic - bounded demand/anchor rendezvous - compact publication - immutable reservation records - corrected Intel response status - manual gating - safe lower setup - immutable transaction slots - explicit status publication Build 2.3.193 reached the reservation/command boundary. Build 2.3.194 corrected the response contract. Build 2.3.195 proved safe manual lower setup but did not receive the required fresh post-setup peer. 10. MANAGEMENT PLANE VERSUS FULL DATA PLANE It is essential not to mix the first management advertisement with the much larger AirDrop data path. 10.1 First management advertisement The explicit clean-room KGP architecture modeled the first remote-visibility milestone as a sequence resembling: 1. Apple upper plane is active. 2. A valid Apple management template and profile exist. 3. Intel PHY1/MAC1/binding exist. 4. Station 3 and TXQ4 exist. 5. The Intel scheduler grants the correct channel/time window. 6. Timing is derived from a valid source. 7. The Time Event command is accepted. 8. A nonzero UID is returned. 9. Event Start is matched. 10. The management frame is submitted. 11. TX completion is matched. 12. Advertisements repeat at an acceptable cadence. 13. Apple peers accept the frame and display the Hackintosh. The current frame is broadcast. It does not require a peer-specific unicast data station merely to address a specific peer. Station 3 and TXQ4 are plausible and experimentally validated choices inside this architecture, not proved universal requirements for every possible implementation. The current Build 2.3.195 policy nevertheless waits for a fresh inbound peer because that peer supplies a conservative timing anchor, channel/presence state, AW phase and GP2 correlation. The source does not prove that a fresh inbound peer is fundamentally required before one broadcast advertisement or that the historical one-time events used such a peer. It is a conservative requirement of the current experimental policy. 10.2 Full AirDrop data plane Even successful remote visibility would not mean that AirDrop was nearly complete. A clean and explicit production implementation would normally be expected to provide the following capabilities, or functional equivalents of them. The isolated one-time transfers mean that it cannot currently be proven that every item must be newly implemented from scratch before any outbound transfer can occur: - safe Apple peer-manager lifecycle - peer presence, absence and IPv6 presence - peer traffic registration - Apple data-mode transition - peer-specific Intel station - peer-specific data queue - TID/access-category mapping - native Apple flow dequeue - exact mbuf ownership - backpressure - transmit success/failure reported exactly once - Intel RX context and peer mapping - packet_info_tag - decapsulation responsibility - IO80211P2PInterface input - awdl0 bidirectional L2 - AWDL IPv6 - mDNS - service negotiation - sustained transfer - reset and removal - sleep/wake - long-duration stability Apple already supplies significant peer, flow and packet behavior above this boundary. No coherent and reproducible AirportItlwm adapter for these facilities was identified or demonstrated. Whether the earlier transient path already supplied some of the required behavior through existing generic mechanisms remains unknown. 11. WHAT CAN BE REUSED AND WHAT REMAINS UNRESOLVED Already present in the restored Apple environment and potentially reusable through validated interfaces: - wifip2pd - Apple IO80211 and WiFiPeerToPeer frameworks - relevant CoreWiFi/CoreWLAN components - IOSkywalkFamily - IO80211FamilyLegacy - the Apple AWDL virtual-interface model - substantial IO80211AWDLPeerManager functionality - native Apple peer and flow machinery - packet preparation and multicast policy - Finder/AirDrop service logic - Apple IPv6/mDNS/service layers once the lower transport works Reusable through declared or independently validated Apple interfaces: - virtual-interface lifecycle - createPeerManager - peer presence/absence operations - native dequeue/drop/prequeue - input/output packet methods - data-path events - transmit completion interfaces Portable only as observed clean-room behavior: - callback order - peer lifetime - data-mode transitions - queue ownership - completion semantics - multicast policy - RX handoff semantics - reset/removal ordering Not portable from Broadcom: - AirPortBrcmNIC hardware implementation - Broadcom PCI/register code - Broadcom firmware - Broadcom DMA/rings - Broadcom IOVARs - Broadcom wl/wlc/d11 structures - AirportBrcmFixup as an Intel command translator Areas likely to require further AirportItlwm development, integration or stabilization: - stable Apple-to-Intel channel scheduling - production-safe multi-context occupancy - management Time Event/UID/Event Start integration - repeated advertisement lifecycle - Apple peer lifecycle adapter - peer-specific Intel station/queue/TID - native packet ownership and completion mapping - RX demultiplexing and awdl0 delivery - AWDL reset/sleep/wake/stability handling These are the most plausible components of an explicit production architecture. The isolated one-time transfers prevent a categorical conclusion that every item is wholly absent or must necessarily be written from scratch. No current evidence indicates that an OCLP source modification is required for the Intel lower work. A future OCLP change could become useful for deployment or capability selection if a later macOS release requires Intel-specific restoration enablement. Such a change would not replace the unresolved AirportItlwm-side hardware integration. 12. DEVELOPMENT SCOPE AND UNCERTAINTY It is not possible to provide a reliable development schedule for the remaining work. This investigation identified the principal unresolved architectural layers, but several of the decisive interfaces remain undocumented or only partially understood. These include Intel multi-context scheduling behaviour, Apple peer and packet lifecycle contracts, native dequeue activation, packet_info_tag requirements, and RX/TX ownership across the Apple-to-Intel boundary. The handful of isolated historical transfers prevents a categorical impossibility claim but does not establish a reproducible partial path that can be selected and stabilized. Their exact system states and transport mechanisms were never identified, they occurred under different OCLP variants, and no synchronized successful capture exists. No single transport or architecture hypothesis currently dominates. Several overlapping families remain possible: restored Apple peer/flow behavior interacting with generic AirportItlwm resources and temporary or lifecycle-dependent state; genuine peer-to-peer use of generic Intel lower mechanisms; another Apple-controlled transport decision; or a cleaner explicit bridge such as the one the KGP branch explored. The evidence does not select among them. Even the smallest controlled next experiment would address only one prerequisite and would not produce reliable AirDrop by itself. Reliable remote discovery would require several additional scheduling and management stages. A clean and stable bidirectional implementation would normally be expected to provide the peer lifecycle, station and queue management, packet ownership, completion reporting, RX delivery, IPv6, mDNS, reset and sleep/wake capabilities listed above—or functional equivalents of them. The work must therefore be regarded as an open-ended driver-development and reverse-engineering project, not as a one-day fix or a feature for which a credible completion date can currently be given. 13. RECOMMENDED NEXT INVESTIGATION AND PRACTICAL LIMITS The historical one-time successes are too rare to make another-success campaign a realistic or scientifically efficient strategy. A successful transfer must not be a prerequisite for the next investigation. 13.1 Compare the known isolated reports The first work package is a structured comparison of every presently known success, including where available: - exact AirportItlwm artifact and target - Wi-Fi hardware - macOS version/build - OCLP code, fork or patch variant - sender, receiver and transfer direction - asymmetric visibility - shared infrastructure-network state - Bluetooth state - preceding reboot, login, sleep/wake, Wi-Fi or Bluetooth transition - number of successful transfers and what happened afterward - quality and contemporaneity of the evidence The purpose is to identify any genuine common denominator rather than treating anecdotes from different environments as one reproducible experiment. If no useful common denominator exists, the reports should remain only as evidence against categorical impossibility claims. 13.2 Characterize the reproducible normal official failure path The next controlled observation should use a verified unmodified official v2.3.0 Ventura artifact in one completely documented current OCLP environment. It should not expect or require a successful transfer. The research question is: What does the unmodified official Kext reproducibly do during an ordinary failed AirDrop attempt? Passive observation should cover, where available: - awdl0 and other interface/object creation or change - interface counters - routes, neighbors and process sockets - bounded wifip2pd, sharingd, rapportd and related logs - ordinary primary-interface traffic - temporary interface or object lifecycle - relevant Wi-Fi, Bluetooth and service transitions - exact loaded Kext/framework/daemon identities This would characterize the normal current official failure path and provide a controlled comparator to the KGP architecture. It would not reproduce or falsify the historical one-time mechanism. Even many failed attempts would establish rarity under the tested conditions, not historical impossibility. 13.3 Conditional minimal passive instrumentation Only if that normal-path characterization exposes one concrete unresolved callback or ownership boundary should a diagnostic source change be considered. It should: - base directly on official 4ac4c79 - add bounded passive counters and monotonic timestamps only - inspect the smallest number of existing callbacks needed - preserve return values, interface creation, scheduling, queue ownership, reset behavior and packet flow - add no active AWDL command or transport path Historical OCLP reconstruction may continue as optional archival research, but it is not a prerequisite for this normal-path comparison and should not be represented as likely to reproduce a success. No further active AWDL architecture development should resume without new concrete technical evidence, a developer explanation, or a newly identified bounded boundary. 14. PROJECT DECISION The investigation has now reached the point where the scope of the explicit KGP architecture, its controlled failure boundary and the remaining uncertainty are sufficiently clear. From a practical daily-driver perspective, continuing is difficult to justify: - the Broadcom reference already provides working AWDL and AirDrop - the first Intel remote-visibility milestone is still not guaranteed - no complete, understood and reproducible peer/data bridge was identified or demonstrated - private Apple ABI risk grows sharply in the later milestones - stable daily-driver support and macOS maintenance could require a long-term development commitment From a research perspective, the project was still valuable and achieved more than a simple failed patch attempt. It established: - which Apple components are already reusable - why OCLP helps without implementing Intel AWDL - why Broadcom hardware code is not portable - which Intel mechanisms already exist - which AirportItlwm baseline stubs were incomplete - which lower resources can be created - how exact Apple AWDL frames can be classified and timed - how a next-AW reservation can be constructed - where the current management pipeline stops - what a clean and explicit full data plane would likely require - the remaining development scope, uncertainty and risk I am therefore ending the current active development phase at Build 2.3.195 and freezing it as a research and evidence milestone. This does not prove that Intel AWDL is impossible. It means that achieving a controlled and reproducible implementation may require a substantial long-term driver project. The rare historical reports are not an operational baseline and no single explanation for them currently dominates. No further active AWDL architecture build is planned without new concrete technical evidence, a developer explanation, or a newly identified bounded boundary. The remaining problem is not correctly described as one callback or a small compatibility patch. 15. EVIDENCE BASE AND REPRODUCIBILITY This report is based on archived Git history, exact source identities, source diffs, controlled runtime captures, implementation and review reports, Intel firmware-contract analysis, exact Apple binary evidence, and a read-only analysis of the relevant OCLP-amfipassbeta source. The underlying evidence has been preserved and integrity-checked, including the exact commits, tags, Kext UUIDs, executable hashes, Build 2.3.193 and Build 2.3.195 runtime captures, and the implementation reports for the final experimental stages. These materials are retained as the technical archive of the investigation. Relevant source, runtime, or implementation records can be provided where they are useful for a concrete technical review or for a developer intending to continue the work. 16. COLLABORATION AND ATTRIBUTION This project was initiated, directed and performed by KGP. KGP performed: - all hardware changes - all EFI operations - all Kext replacements - all reboots - all manual AirDrop/UI observations - all controlled runtime procedures - final judgment over scope and safety - validation of the observed system behavior ChatGPT assisted with: - architecture analysis - experiment and safety design - independent interpretation of source and runtime evidence - formulation of discriminating tests - review of conclusions - public-report planning, drafting and finalization OpenAI Codex performed, under KGP’s explicit instructions: - repository and Git-history inspection - source analysis - implementation work - builds - bounded model tests - code review - read-only OCLP and Apple-binary analysis - the later read-only official-versus-Dexter, target, ABI and methodology audit ChatGPT and Codex were technical assistants, not autonomous project owners. The final claims were checked against source, exact Git identities, existing reports, immutable diagnostics or controlled runtime evidence. Conclusions that remain unproven are explicitly identified as inference or unknown. The collaboration produced substantial Intel AWDL research infrastructure and several isolated lower-plane milestones. The controlled KGP experimental branch did not produce reproducible working Intel AirDrop. This does not erase earlier isolated one-time send-only successes observed under other OCLP-modified configurations. Technical corrections, alternative interpretations, and review by OpenIntelWireless/AirportItlwm developers would be very welcome, especially regarding any existing Apple-facing, generic, or lifecycle-dependent path that this investigation may have overlooked or misclassified. If useful for a concrete technical review or continuation effort, I can make the current private repository branch and the relevant archived source, build, and runtime evidence available through private communication. The branch remains research code; it is not a release, a pull request, or a user-ready Kext. 17. FINAL CONCLUSION The most accurate summary is: OCLP restores the Apple environment. Apple supplies most of the AWDL upper plane. Stock AirportItlwm supplies ordinary Intel Wi-Fi and generic Intel primitives. The KGP experimental branch constructed and proved significant components of one explicit clean-room AWDL management-plane architecture. No coherent, understood and reproducible Apple-to-Intel peer and data bridge has yet been identified or demonstrated. The handful of isolated official-release transfers remain genuine historical observations and prevent categorical impossibility claims, but they do not identify a reproducible partial path or prove equivalence to the KGP architecture. The unresolved work required for a clean and reproducible implementation is unlikely to be one patch. It may span: - scheduler ownership - management advertisement - peer lifecycle - peer-specific firmware resources - native packet dequeue and ownership - completion reporting - RX demultiplexing - awdl0 packet delivery - IPv6 and mDNS - AirDrop service traffic - reset and sleep/wake - long-term macOS maintenance The project therefore ends its current experimental phase with a negative product result but a positive engineering result: No complete, reliable or reproducible Intel AirDrop implementation was achieved. The audit established that the KGP experiment investigated a valid but newly constructed explicit Intel AWDL management-plane architecture rather than a proved reconstruction of the historical official-release path. No single hypothesis currently dominates. The strongest broad family may combine restored Apple peer/flow/runtime behavior, generic AirportItlwm resources, temporary or lifecycle-dependent state, possible genuine peer-to-peer operation through generic lower resources, or another Apple-controlled transport decision. There is no route, socket or packet evidence that justifies ranking pure infrastructure first. Future work should compare the known isolated reports, characterize the normal reproducible official v2.3.0 failure path, await or seek concrete external technical evidence, and add only minimal passive instrumentation at a specifically identified unresolved boundary. Active AWDL architecture development should not resume without such evidence, a developer explanation, or a newly identified bounded boundary. The architecture, proven milestones, failure boundaries and remaining implementation scope and uncertainty are now documented in enough detail that future work no longer has to begin from the vague statement that “AWDL is missing.”

SSDT Maintenance — SSDT Generator + macOS-Support Suite for Hackintosh Free · Open Source (MIT) · by Lumina Dev Apps WHAT IT IS SSDT Maintenance is a native macOS app that generates clean, OpenCore-ready SSDTs and compiles them to .aml locally with iasl — no manual DSL editing. On top of the usual device SSDTs, it includes a full set of macOS-support "maintenance" tables (AWAC, PMC, USBX, EC, SBUS-MCHC and more) that most Alder Lake / Raptor Lake (Z690 / Z790) builds need to boot and stay stable. You pick your ACPI paths and hardware, tick the tables you want, hit Generate ALL SSDTs, and drop the resulting .aml files into EFI/OC/ACPI/. WHAT IT GENERATES Device SSDTs: - SSDT-PLUG — CPU power management, auto-sized to core count - SSDT-DTPG — DTGP helper method - SSDT-HDEF — onboard audio (layout-id injection) - SSDT-IGPU — Intel iGPU (Alder/Raptor Lake, headless) - SSDT-GPU — discrete GPU + HDAU (AMD RDNA2 / Vega) - SSDT-LAN — Aquantia AQC107 / Realtek / Intel I225-I226 - SSDT-WIFI — Intel (itlwm) / Broadcom - SSDT-TB3 — Thunderbolt (Titan Ridge / Maple Ridge) - SSDT-XHCI — USB port maps (15 / 20 / 25 / 30 / Type-C) - SSDT-SATA / SSDT-NVME — storage controllers Maintenance SSDTs (macOS support) — on by default: AWAC, PMC, USBX, EC, SBUS-MCHC. Optional: PNLF, GPRW, RHUB, ALS0, BRG0. - SSDT-AWAC — system clock fix (RTC/AWAC), required on Z690/Z790 - SSDT-PMC — native NVRAM for 300-series and newer - SSDT-USBX — USB sleep/wake power properties - SSDT-EC — fake Embedded Controller - SSDT-SBUS-MCHC — SMBus + Memory Controller Hub - SSDT-PNLF — backlight (iGPU display) - SSDT-GPRW — instant-wake-from-sleep fix - SSDT-RHUB — USB root-hub reset - SSDT-ALS0 — fake ambient light sensor - SSDT-BRG0 — PCI bridge _ADR template (advanced) REQUIREMENTS - macOS 13.0 or later - iasl (the ACPI compiler): brew install acpica HOW TO USE IT 1. Install iasl: brew install acpica 2. Open the app. In the Generator tab, set the ACPI paths for your board. Defaults target the _SB.PC00 layout (Alder/Raptor Lake). Always confirm these against your own disassembled DSDT — if your PCI root is PCI0, or your iGPU is GFX0 instead of IGPU, adjust accordingly. 3. Choose your hardware presets (iGPU, dGPU, LAN, Wi-Fi, TB, USB, SATA, NVMe) and set your audio layout-id. 4. Scroll to Maintenance (macOS Support) and enable the tables you need. The essential five are on by default. 5. Click Output Folder (bottom bar), pick a destination, then Generate ALL SSDTs. Use Show Log / Copy Log to check the iasl output — every table should report 0 Errors. 6. Copy the generated .aml files into EFI/OC/ACPI/ and add each under config.plist → ACPI → Add (ProperTree "Snapshot" does this automatically). REQUIRED ACPI RENAMES Add these under config.plist → ACPI → Patch (Base empty, Count 0): SSDT-EC — only if your board's real EC device is named "EC": Comment : Rename EC to EC0 Find : 45435F5F Replace : 45433000 SSDT-GPRW — required for the instant-wake fix: Comment : Rename _GPRW to XGPW Find : 5F47505257 Replace : 58475057 RECOMMENDED SET For most Z790 builds, install AWAC + PMC + USBX + EC + SBUS-MCHC (add PNLF / ALS0 if wanted). Only add GPRW / RHUB with their renames/edits, and treat BRG0 as a template — edit its path and _ADR before using it. Generating all ten is fine; only deploy the ones your build actually needs. Note: injected SSDTs change how macOS sees your PCI tree. Verify device paths against your own DSDT and test before relying on them. Use at your own risk. DOWNLOAD - Release (DMG): https://github.com/luminadevapps/SSDTMaintenance/releases/tag/v1.1.0 - Source: https://github.com/luminadevapps/SSDTMaintenance First launch: the app is currently unsigned, so macOS Gatekeeper will block it the first time. Right-click the app and choose Open (once), or run: xattr -dr com.apple.quarantine /Applications/SSDTMaintenance.app FEEDBACK Bug reports, board-specific path issues, and suggestions are welcome — reply here or open an issue on GitHub. Mentioning your motherboard model + macOS version helps others too. SSDT Maintenance v1.1.0 · © 2026 Lumina Dev Apps · MIT License

Nice..enjoy

I found a bug and am fixing it. (cpu freq) I'll soon release a new version in the first post, marked as b2. https://github.com/Lorys89/App-test/raw/refs/heads/main/SiliconMonitorCenter 1.0 b2.zip

@lorys89 Great app and very nice UI design. It works very well. And translated to a lot of languages. Thanks.

@Slice Installation of VoodooHDA.kext 3.6.4 running macOS Tahoe 26.6 Beta 5(25G5065a) Perfect, the audio works and sounds great No HDMI aud

Thanks a lot @lorys89 nice app my friend!!

Working fine, thanks !!

Hi everyone, I’m developing this app for Macs with Apple Silicon processors. If you’d like to try it out and give me some feedback... https://github.com/Lorys89/App-test/raw/refs/heads/main/SiliconMonitorCenter 1.0 b2.zip

Thanks, I’ll give it a go later

VoodooHDA is finished with a help oh AI Qwen. But I checked every line of code didn’t allowed fantastic workarounds and allowed only right codes. It works!

There were a lot of posts about it way back then. Gave it a try but didnt work

Never exists

Hello everyone, it's a pleasure to announce that I've updated the main post with new information to keep you up-to-date with the changes... also, I wanted to let you know that the app now has a website. https://toshllm.com Thanks to everyone who has been testing the app since I first released it.

Thanks for this feature. Im too lazy to test layouts 😁