All Activity

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. 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 macOS already creates 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 parts of an effective outbound path can arise transiently through a system state that has not yet been identified. Stabilizing that transient path—or replacing it with an explicit and reproducible bridge—may still require substantial driver development. The available evidence does not establish which of those two paths is necessary. 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 Authoritative source identities: 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 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 modern wireless environment relevant here, that includes restoration or enablement of components such as: - wifip2pd - IO80211.framework - WiFiPeerToPeer.framework - version-appropriate CoreWiFi/CoreWLAN components - IOSkywalkFamily - IO80211FamilyLegacy - related compatibility components selected by the patch set 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 restores and enables the environment. It is not the runtime AX210 AWDL driver. 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: We do not need to reimplement the complete Apple AWDL peer and service stack from scratch. However, Apple’s upper plane still expects the hardware driver below it to perform the driver-specific work correctly. 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 indicates that some functional equivalent can nevertheless arise transiently. 4. WHAT STOCK/DEXTER AIRPORTITLWM ALREADY PROVIDED The exact pre-KGP Dexter 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 limitation was that these pieces were not assembled into a working AWDL implementation. Examples of the baseline boundary included: - Ventura AWDL VIF creation was incomplete or rejected - several AWDL callbacks were shallow stubs, logs, or state copies - requestPacketTx did not execute a native AWDL packet path - 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. 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. 5.1 AWDL virtual-interface lifecycle The branch enabled and validated the Ventura AWDL virtual-interface path: - 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. 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 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 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 under an earlier OCLP-modified AirportItlwm configuration. The Hackintosh was not visible as an AirDrop destination on the MacBook Pro, but the MacBook Pro was visible on the Hackintosh and the Hackintosh-to-MacBook Pro transfer completed once. A comparable isolated one-time AirDrop result was also reported by another user in OpenIntelWireless/itlwm Issue #1062 under the OCLP amfipassbeta environment. This also demonstrates that normal reverse visibility of the Hackintosh is not necessarily a prerequisite for an outbound transfer when the Hackintosh already knows and can select the receiving Apple device. These observations are technically important. They demonstrate that, under a particular transient system state, enough of Apple’s restored AirDrop upper plane and the existing Intel driver path can apparently become operational to complete at least one outbound transfer. However: - the result was not reproducible; - the exact system state and transport path were not identified; - the Hackintosh still lacked normal reverse discovery and visibility; - no reliable bidirectional AWDL operation was established; - and the later controlled experimental builds did not reproduce the transfer. The correct conclusion is therefore not that every Intel AirDrop transfer is fundamentally impossible. The correct conclusion is that current AirportItlwm does not provide a complete, understood, reliable or reproducible AWDL/AirDrop implementation. The isolated one-time transfers remain evidence of a transient partial path, not evidence of a production-capable data plane. 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. 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 a comparable community report demonstrate that a transient send-only path can occur, but its exact mechanism has 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 A clean and explicit path to the first remote-visibility milestone would be expected to follow 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. 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. It is required by 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 Reusable unchanged from the OCLP/Apple environment: - wifip2pd - Apple IO80211 and WiFiPeerToPeer frameworks - relevant CoreWiFi/CoreWLAN components - IOSkywalkFamily - IO80211FamilyLegacy - the Apple AWDL virtual-interface model - much of IO80211AWDLPeerManager - 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 OCLP source modification is currently required for the Intel lower work. A future OCLP change could become useful only for deployment or capability selection if a later macOS release requires Intel-specific restoration enablement. Such a change would not replace the missing AirportItlwm implementation. 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 earlier isolated one-time Hackintosh-to-MacBook Pro AirDrop transfer also shows that a transient partial path can apparently exist without the complete controlled architecture described here. Its exact system state and transport mechanism were never identified or reproduced. Consequently, the remaining development could follow very different paths: - identifying and stabilizing an already existing transient path; - completing only the management and discovery plane; - or implementing the full peer-specific TX/RX data bridge inside AirportItlwm. 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. WHAT WOULD BE THE MOST INFORMATIVE NEXT EXPERIMENT? In light of the isolated one-time AirDrop transfers, the most informative next experiment would no longer necessarily be another isolated lower-plane build. The first priority would be to reproduce the earlier OCLP-modified system state as closely as possible and capture the complete successful or attempted Hackintosh-to-MacBook Pro sequence with synchronized evidence, including: - loaded Apple and third-party components - AirportItlwm and OCLP versions and configuration - awdl0 state - IORegistry state - wifip2pd and unified-log activity - Bluetooth and infrastructure-network state - AirportItlwm callbacks - packet and interface traces - the selected recipient and transfer lifecycle This would determine whether the earlier transfer used: - a transient but genuine Intel AWDL path - existing generic AirportItlwm TX/RX resources - an Apple-managed alternative path - or another transport transition that was not represented by the later controlled architecture A manually authorized receive-only channel-6 dwell would remain a useful secondary experiment if the transient state could not be reproduced. It would test the scheduler and RX opportunity, but it would not explain how the earlier complete transfer occurred. Neither experiment would by itself establish reliable AirDrop. Their purpose would be to distinguish between stabilizing an already existing partial path and implementing a more complete Apple-to-Intel bridge. 14. PROJECT DECISION The investigation has now reached the point where the remaining scale is 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 unless the transient path can first be understood and stabilized 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 unless the earlier transient path can first be identified and stabilized. It is not correctly described as one remaining 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 and drafting 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 - reconstruction of the final evidence dossier 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. 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 added and proved significant AWDL management-plane groundwork. No coherent, understood and reproducible Apple-to-Intel peer and data bridge has yet been identified or demonstrated. The isolated one-time transfers prove that enough of a partial path can nevertheless arise under an unknown transient state. 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. Earlier isolated one-time send-only transfers demonstrate that a transient partial path can occasionally exist, but its mechanism remains unidentified and was not reproduced by the controlled experimental branch. 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 😁

closed, gave permission

Final Release 3.6.4 I got clear sound on my AMD RX570 on TV Samsung. https://github.com/CloverHackyColor/VoodooHDA/releases/tag/Release364 If you hear a noise then open Info.plist and change InhibitCache option. Layout 0 will be traditional autodetect, other values same as AppleALC. But PciRoot(0x0)/Pci(0x1F,0x3) voodoo-layout-id <0C000000>

Close and re-open....I'm fixing that bug

version 1.0.5 shows nothing, only the safari icon

Give me some feedback, and I'll tweak or improve it if necessary.

i prefer this Features: Scans /Applications, /System/Applications, and ~/Applications Adaptive SwiftUI grid with native app icons Search by app name or bundle identifier One-click app launching Drag-and-drop folder organization Context menu actions: Open and Show in Finder Organize app icons without deleting or modifying installed apps Native macOS visual effect background Asset catalog with app icon and accent color LaunchPadBasic_1.0_b1.zip