MaLd0n

Hello everyone! I'd like to share an interesting project with the Hackintosh community: NullMoth NVIDIA Driver for macOS, a source-available graphics driver developed by NullMoth Systems that aims to bring NVIDIA GPU acceleration back to modern macOS systems. For years, NVIDIA graphics support has been one of the biggest limitations for Hackintosh users, particularly since Apple discontinued support for NVIDIA Web Drivers in newer macOS releases. NullMoth takes a different approach by implementing a graphics driver stack that connects Apple's Metal framework to NVIDIA hardware through a combination of shader translation, Mesa's NVK Vulkan driver, and NVIDIA's open GPU kernel modules. The project is currently focused on macOS Sequoia running on Intel-based Macs and OpenCore systems, with support targeted at NVIDIA Turing and newer GPU architectures. Important: This is a new and experimental project. Broad GPU compatibility has not yet been physically validated, and functionality may vary considerably between systems. Supported NVIDIA GPUs The driver's device table covers several NVIDIA GPU generations: Architecture GPU Families Turing GeForce GTX 16, RTX 20, TITAN RTX Ampere GeForce RTX 30 Ada Lovelace GeForce RTX 40 Blackwell GeForce RTX 50 Workstation Selected Quadro, RTX A and RTX PRO GPUs Support for a GPU's PCI device ID does not necessarily mean that the card has been successfully tested on macOS. According to the project's documentation, physical testing has primarily focused on the GeForce RTX 5060, with additional working reports for RTX 5070 and RTX 5080 configurations. Other GPUs are included through NVIDIA's supported hardware tables but still require further testing. Older architectures such as Pascal, Maxwell and Kepler are outside the scope of the current implementation. Graphics Features The project implements a number of graphics technologies and interfaces, including: Metal graphics acceleration Metal 3 interfaces OpenGL through Apple's GL-on-Metal implementation OpenCL compute support Core Image integration Metal Performance Shaders (MPS) Core ML integration Vulkan-based graphics execution through Mesa NVK GPU-accelerated desktop composition NVIDIA framebuffer and display management Support for multiple display outputs Hardware H.264 decoding on supported GPUs Shader compilation through the NAK compiler Implementation paths for ray tracing, mesh shaders and MetalFX Feature availability depends on the GPU, macOS configuration and driver implementation. Not all features or applications have been independently validated across every supported GPU generation. How Does It Work? Unlike traditional NVIDIA Web Drivers, NullMoth uses a different graphics architecture. The driver connects Apple's Metal interface to NVIDIA hardware using several components. 1. Metal Driver Plugin The NVMTLDriver.bundle component implements Metal interfaces used by applications and the macOS graphics system. 2. Shader Translation A shader translation layer converts Apple's AIR intermediate representation into SPIR-V, allowing shaders to be processed through the Vulkan graphics pipeline. 3. Mesa NVK The project uses Mesa's open-source NVK Vulkan driver and NAK shader compiler to generate NVIDIA GPU instructions and execute graphics workloads. 4. NVIDIA Open GPU Kernel Modules The kernel-side implementation adapts NVIDIA's open GPU kernel modules to the macOS XNU environment. 5. Framebuffer and Acceleration Components Additional kernel extensions provide framebuffer functionality, graphics acceleration integration and display policy handling. The resulting architecture can be summarized as: Metal Application → Metal Driver Plugin → Shader Translation → Mesa NVK → NVIDIA Kernel Driver → GPU This approach is particularly interesting because it does not depend on the traditional proprietary NVIDIA Web Driver architecture previously used on older macOS releases. macOS Compatibility The current driver targets: macOS Sequoia (Intel / x86_64) OpenCore is required for the supported configurations. The project is not an official NVIDIA or Apple graphics driver. Compatibility with other macOS releases should not be assumed unless explicitly documented by the developers. Apple Silicon Macs are not part of the current supported platform. Installation and Requirements The project provides prebuilt driver packages and a companion installation application. For an existing Hackintosh installation, the basic requirements include: A compatible NVIDIA GPU macOS Sequoia A working OpenCore configuration Appropriate BIOS/UEFI graphics settings The required macOS security and kernel-extension configuration The NullMoth NVIDIA driver package The installation process involves configuring OpenCore, installing the driver components and rebuilding the required macOS kernel collection. The project also provides the 1401 Mac application, designed to simplify installation, configuration, logging and removal of the driver. For users installing macOS from Windows, the separate 1401 project provides tools for preparing the installation media and OpenCore environment. Please note: Installation requires changes to security-related settings, including SIP and Secure Boot configuration. These changes have security implications and should only be made after reviewing the official documentation. The developers recommend following the instructions provided in the repository rather than assuming that settings from older NVIDIA Hackintosh configurations will work. Current Limitations Despite the progress described by the project, there are still important limitations. The developers document ongoing issues involving: Screen flickering on certain high-refresh-rate configurations Flickering with some multi-monitor setups HDMI and DisplayPort audio output from the NVIDIA GPU Hardware compatibility differences between desktop and laptop systems Limited physical validation across the advertised GPU families Laptop configurations may also require a direct display connection to the NVIDIA GPU. The driver does not automatically provide support for NVIDIA Optimus switching or unsupported display routing. This remains experimental software and should not yet be considered a drop-in replacement for a fully mature graphics driver. Download and Source Code Official Project Repository https://github.com/nullmoth/nvidia-macos-driver Driver Downloads and Releases https://github.com/nullmoth/nvidia-macos-driver/releases 1401 – macOS Installation and Configuration Tools https://github.com/nullmoth/1401 Technical Documentation https://github.com/nullmoth/nvidia-macos-driver/blob/main/docs/HOW-IT-WORKS.md GPU Compatibility Information https://github.com/nullmoth/nvidia-macos-driver/blob/main/docs/CARD-SUPPORT.md Official Website https://nullmothsystems.com The repository includes driver components, installation tools, source code, build instructions and technical documentation. Credits & Acknowledgments This project builds upon multiple graphics technologies and open-source components developed by the broader software and GPU development community. Full credit belongs to their respective developers and maintainers. NullMoth Systems Development and maintenance of the NullMoth NVIDIA Driver for macOS. Metal driver implementation, integration, macOS compatibility layers and installation utilities. Anees Iqbal (steelbrain) Original developer of metal2vulkan, the project upon which NullMoth's shader translation component is based. https://github.com/steelbrain/metal2vulkan Mesa Developers and Contributors Development of the Mesa graphics stack, including the NVK Vulkan driver and NAK shader compiler. https://mesa3d.org NVIDIA Corporation NVIDIA Open GPU Kernel Modules and GPU System Processor firmware used by the project. https://github.com/NVIDIA/open-gpu-kernel-modules Acidanthera and OpenCore Contributors Development of OpenCore and related technologies used by the Hackintosh community. https://github.com/acidanthera/OpenCorePkg Dortania and the Hackintosh Community OpenCore documentation, installation resources, research and ongoing contributions to macOS compatibility. https://dortania.github.io/OpenCore-Install-Guide/ Special thanks to everyone involved in Mesa, NVIDIA open driver development, reverse engineering, testing and documenting graphics technologies. Licensing The project is available free of charge with source code, but it is not licensed for unrestricted commercial use. The main NullMoth components are distributed under the PolyForm Noncommercial License. Third-party components retain their respective licenses, including LGPL for the shader translator, MIT for Mesa-related changes and NVIDIA's applicable licenses for kernel modules and firmware. Please review the repository's LICENSE and NOTICE files before redistributing or modifying the software. Final Thoughts The NullMoth NVIDIA Driver is an ambitious effort to address one of the most significant limitations of modern Hackintosh systems: NVIDIA graphics acceleration. Its architecture, combining Metal compatibility layers, Mesa NVK, shader translation and NVIDIA's open kernel modules, represents an interesting alternative to the legacy NVIDIA Web Driver approach. Although the project is still experimental and requires considerably more hardware testing, it may open new possibilities for users with NVIDIA Turing, Ampere, Ada Lovelace and Blackwell GPUs. Community testing and feedback are welcome! If you're testing the driver, consider sharing: NVIDIA GPU model and PCI Device ID CPU and motherboard macOS build OpenCore configuration Display connections and refresh rates Working features and known problems Relevant logs or crash reports Sharing detailed results can help the developers identify compatibility problems and improve the project. As always, back up your OpenCore EFI and macOS installation before making driver or system modifications. Official GitHub: https://github.com/nullmoth/nvidia-macos-driver Thanks to NullMoth Systems and all the developers contributing to graphics driver development and the Hackintosh community!

I'd like to introduce WhateverXe by b00t0x, an open-source project designed to bring graphics acceleration to selected Intel Xe-LP integrated GPUs on macOS. Derived from WhateverGreen and built on top of Lilu, WhateverXe adapts Apple's graphics drivers to work with Intel integrated graphics architectures that are not officially supported by macOS. The goal is to extend Hackintosh compatibility to newer Intel platforms while providing functional hardware acceleration, external display support, and other GPU-related features. This is an experimental project under active development. Compatibility and functionality may vary depending on the hardware configuration. Supported Intel Graphics The project currently includes implemented support for the following GPU families: Intel Platform Device IDs Tiger Lake 9A40, 9A49, 9A78 Alder Lake-N 46D0–46D4 Twin Lake 46D0–46D4 Alder Lake-N and Twin Lake currently require PCI revision 0 for their implemented backends. GPU detection is handled automatically using the PCI device ID, without requiring manual CPU model selection. Features WhateverXe currently provides several graphics-related capabilities, including: Metal and OpenGL hardware acceleration Hardware-accelerated graphics rendering HDMI and DisplayPort output on supported configurations Dual external displays at 1920×1080 @ 60 Hz Hardware HEVC encoding and decoding Hardware H.264 encoding and decoding tested on Tiger Lake Display sleep and wake functionality Automatic GPU identification and backend selection Connector configuration using firmware VBT information when supported Integration with OpenCore and Lilu These capabilities have been tested on selected Tiger Lake and Alder Lake-N configurations. Some features, including three simultaneous displays, full system sleep, higher display resolutions, and additional connector configurations, still require further testing. How Does It Work? WhateverXe works as a Lilu plugin that applies runtime adaptations to Apple's Intel graphics drivers. Instead of relying solely on device ID spoofing, the project implements dedicated compatibility logic for supported Intel Xe-LP architectures. It also works alongside a modified OpenCore Legacy Patcher (OCLP) implementation, which provides the necessary Xe graphics root patches. The combination allows selected Intel Xe-LP GPUs to initialize and use Apple's graphics acceleration stack under supported macOS configurations. Requirements The following components are required: Lilu.kext – Provides the runtime patching infrastructure. WhateverXe.kext – Implements Intel Xe-LP graphics compatibility. Modified OpenCore Legacy Patcher – Installs the required graphics root patches. AMFIPass Mod – Required for the modified root-patched graphics environment. WhateverXe must be loaded after Lilu through OpenCore. Important: WhateverGreen and WhateverXe must not be enabled simultaneously, including on systems with multiple GPUs. Basic Configuration The following OpenCore boot arguments are required: -allow3d -disablegfxfirmware Tiger Lake systems without an internal display additionally require: -wex-nopanel The latter argument is not required for the current Alder Lake-N / Twin Lake backend. For graphics memory allocation, setting DVMT Pre-Allocated to 96 MB in BIOS/UEFI is recommended when available. Systems with a fixed 60 MB DVMT allocation require the alternative configuration documented in the project's README. Please refer to the official documentation for the complete installation procedure, device properties, and additional configuration options. Future Development The project roadmap includes: Compatibility with additional macOS releases, from Monterey through Tahoe Support for additional Intel Alder Lake and Raptor Lake variants USB-C display output Internal laptop displays Further graphics compatibility improvements These are planned features and should not be considered implemented or guaranteed at this stage. Xe-LPG, Xe2, and newer graphics architectures are not currently planned. Download & Source Code WhateverXe – Official GitHub Repository https://github.com/b00t0x/WhateverXe Latest Releases https://github.com/b00t0x/WhateverXe/releases Modified OpenCore Legacy Patcher https://github.com/b00t0x/OpenCore-Legacy-Patcher OCLP Releases https://github.com/b00t0x/OpenCore-Legacy-Patcher/releases GPU Device Selection Documentation https://github.com/b00t0x/WhateverXe/blob/main/docs/device-selection.md Both RELEASE and DEBUG builds are provided. The RELEASE build is intended for normal use, while DEBUG builds are intended for troubleshooting. The complete source code is publicly available on GitHub. Credits & Acknowledgments WhateverXe builds upon the work of several developers and open-source projects that have made macOS graphics patching and Hackintosh development possible. WhateverXe Development b00t0x – WhateverXe project development, implementation, maintenance, and the modified OpenCore Legacy Patcher integration. Original Projects & Developers vit9696 – Original WhateverGreen copyright holder and key developer of the underlying graphics patching ecosystem. Acidanthera Team & Contributors – WhateverGreen, Lilu, and the underlying technologies that make runtime macOS graphics patching possible. Dortania / OpenCore Legacy Patcher Contributors – Original OpenCore Legacy Patcher development and the foundation for the modified implementation used by this project. OpenCore and Hackintosh Community – Research, documentation, testing, and contributions to macOS compatibility development. Related Projects WhateverGreen: https://github.com/acidanthera/WhateverGreen Lilu: https://github.com/acidanthera/Lilu OpenCore Legacy Patcher: https://github.com/dortania/OpenCore-Legacy-Patcher WhateverXe retains the original WhateverGreen copyright notices and is distributed under the BSD-3-Clause license. Full licensing information is available in the official repository. Final Notes WhateverXe is an ongoing effort to expand macOS graphics compatibility beyond Apple's officially supported Intel GPU generations. Although hardware acceleration and multiple graphics features are already functional on selected configurations, the project remains experimental. Community testing and feedback are welcome! If you have a Tiger Lake, Alder Lake-N, or Twin Lake system, feel free to share your hardware specifications, PCI device IDs, display connections, macOS build, and testing results. Bug reports and technical feedback can help identify compatibility issues and improve the project for other users. Please make sure to read the documentation carefully and back up your system before applying graphics root patches. Project: https://github.com/b00t0x/WhateverXe Thanks to everyone who continues contributing to the Hackintosh community!

The Realtek ALC888B/ALC887 has only two physical analog ADCs. In this layout, the Rear Microphone uses one ADC, while the Front Microphone and Rear Line-In share the other. Because of this, Front Mic and Line-In cannot capture audio simultaneously. The main issue was the ADC handoff: when switching between them, macOS could try to start the new input before the previous one had fully released the shared ADC. The latest fix keeps all three inputs as separate devices while safely waiting for the shared ADC to be released before activating the next source. Use this and save new logs HDAUniversal-Release.zip

HDAUniversal-Release.ziptest 03

Wrong bootloader config

Test 02 HDAUniversal-Release.zipalcid=170

Reporting Issues If you find a problem with HDAUniversal, please report it with proper logs. Before posting, run the included log collector: Collect-HDAUniversal.command Download HERE

HDAUniversal-Release.zip Use alcid=170 and check if work

U need extract codec dump on linux or clover

HDAUniversal-Release.zip Test this

Yes. Have support for Tahoe. Enjoy!

SystemPulse-Release.zip This app is for Ventura+. Check if this version work, I changed support to Bigsur+.

UVCProbeFix is a macOS kernel extension designed to restore certain USB UVC webcams that are correctly detected by macOS but fail to produce a usable video stream, resulting in a black screen or a failed camera start. Confirmed Working – Lenovo IdeaPad S145 Ice Lake The fix has been verified through UVC runtime traces, not only by visual testing. Before UVCProbeFix was active, the webcam returned a malformed PROBE response: Frame: 4 Frame Size: 184549376 Payload: 16842753 Result: Start Stream Failed With UVCProbeFix loaded, the same camera negotiated: Frame: 1 Frame Size: 614400 Payload: 3072 Interval: 333333 The captured PROBE response and COMMIT were byte-for-byte identical, after which macOS selected Stream Alternate Setting 6, opened the USB streaming pipe and reported start streaming for client. The successful trace contains zero Start Stream Failed events. Hardware: Lenovo IdeaPad S145 Ice Lake Resolution: 640×480 YUV422 @ 30 FPS Result: ✅ UVC negotiation recovered and video streaming successfully started. The problem Some UVC webcams enumerate normally and expose valid video formats, but their firmware returns malformed values during the UVC PROBE/COMMIT negotiation performed by macOS. In the hardware case that led to this project, macOS selected a valid video mode, but the webcam returned an invalid GET_CUR(VS_PROBE_CONTROL) response containing incorrect frame-size and payload values. macOS then committed those invalid parameters and attempted to start the stream, which resulted in a black image / stream startup failure. The camera itself was functional. The failure happened during UVC negotiation. What UVCProbeFix does UVCProbeFix intercepts the affected negotiation path and applies a known-good recovery before macOS commits the broken configuration. For the currently verified hardware case, the original negotiation behaves approximately like this: macOS selects: Frame 4 640x480 30 FPS Camera returns: Frame size: 184549376 Payload: 16842753 macOS COMMIT: same invalid values Result: stream fails / black screen UVCProbeFix detects this broken negotiation and performs a controlled re-negotiation using the working equivalent UVC frame. The recovered negotiation becomes: Frame: 1 Resolution: 640x480 Interval: 333333 Frame size: 614400 Payload: 3072 macOS then commits the corrected values and the camera starts producing real image data normally. Important distinction UVCProbeFix is not a generic webcam driver and it does not replace Apple's UVC stack. It works alongside the existing macOS camera stack and targets a specific class of problems where: the webcam is detected; the UVC interface enumerates correctly; supported video formats are visible; PROBE/COMMIT negotiation occurs; but the camera firmware returns malformed negotiation values or a broken equivalent-frame path. Problems involving USB power, physical connection, proprietary camera protocols, missing device enumeration, sensor failure or unsupported codecs are outside this recovery path. Current release strategy The production Release currently preserves the physically verified recovery implementation for the known working case. The experimental branch also contains a descriptor-driven generic recovery engine intended to eventually support other webcams exhibiting the same class of UVC negotiation failure. The generic design does not rely on a specific VID/PID or fixed camera model. Instead, it is being developed to: parse the webcam's own UVC descriptors; validate the returned PROBE data; identify impossible frame-size or payload values; discover equivalent frames dynamically; perform at most one safe re-negotiation; leave healthy webcams completely untouched; fail closed when a correction cannot be proven. This generic path remains isolated from the stable Release until it passes sufficient real-hardware validation. Compatibility Initial target: macOS Tahoe Darwin 25.6 Intel x86_64 Lilu-based kernel extension environment The current recovery has been physically validated on the hardware that originally exhibited the black-screen UVC negotiation issue. Other webcams may exhibit a similar symptom for completely different reasons, so additional hardware must be analyzed before compatibility can be claimed. Future webcam support For additional webcams, the goal is not to create an endless VID/PID compatibility list. The intended workflow is: Passive UVC trace ↓ Analyze PROBE / COMMIT negotiation ↓ Parse the webcam's descriptors ↓ Identify the failure class ↓ Prove a safe recovery ↓ Add regression fixtures ↓ Test in Generic Recovery mode ↓ Hardware validation This allows future fixes to be based on UVC behavior and descriptor evidence, rather than camera brand or model. Safety The project follows a conservative recovery policy: healthy negotiations are passed through unchanged; no arbitrary frame or payload values are guessed; unsupported or ambiguous cases remain untouched; internal recovery attempts are bounded; the stable legacy recovery remains isolated from experimental generic code. Status The original black-screen webcam case is working again under the stable recovery path. Development is now focused on safely generalizing the same concept so that other UVC webcams with equivalent negotiation failures can potentially be recovered without camera-specific hardcoding. Download Kext HERE Download DUMP HERE Credits Special thanks to the developers and projects that made this work possible: Lilu by vit9696 / Acidanthera — kernel patching framework used by UVCProbeFix. MacKernelSDK by Acidanthera — kernel development headers and build support. Apple UVC / IOUSBHost stack — platform interfaces analyzed during development and debugging. Linux uvcvideo developers — valuable reference for UVC negotiation, descriptor parsing and recovery behavior. Olarila.com community — testing, feedback and hardware reports that help expand compatibility. UVCProbeFix development and research: DNMTechLabs / MaLd0n Contact: dnmtechlabs@gmail.com

U just need to use imac20 smbios

Dont use internal graphics, use RX6600m

This guide explains how to create an audio codec dump using Clover Bootloader or Linux. -Linux Use Ubuntu or other distro then run this tool HERE Download Ubuntu HERE -Clover You must already have the prepared EFI folder installed or copied to your EFI partition. Download EFI HERE Steps Boot your computer using the prepared EFI folder with Clover Bootloader. When you reach the Clover boot screen, do not boot macOS. Press the F8 key on your keyboard. You don't need boot to macOS! Clover will create a codec/audio dump automatically. Open your EFI partition. Go to the Clover folder: EFI/CLOVER/ Inside the Clover folder, look for a folder named: misc Compress the entire misc folder into a .zip file. Send me the zipped misc folder. Important Notes The F8 key must be pressed at the Clover boot screen, before booting macOS. Do not rename or modify the files created inside the misc folder. Send me the complete misc folder exactly as Clover/Linux created it. If the misc folder was not created, reboot and try pressing F8 again at the Clover boot screen.

no support for this

Yes. Have support.

ZeroRPMBuilder is a native macOS utility created to generate AMD GPU fan-control patches for Clover/OpenCore through DeviceProperties. The application can extract or import an AMD PowerPlay table, validate its structure, apply a controlled Zero RPM modification, and generate a ready-to-use PP_PhmSoftPowerPlayTable without flashing or modifying the GPU VBIOS. It was designed for users who want a cleaner and safer way to disable Zero RPM or configure a predictable fan start/stop temperature on supported AMD GPUs. Extracting the VBIOS with Clover (if you don't use Windows) You can dump your GPU VBIOS directly from the boot menu: Boot with Clover HERE Press F6. Clover will save the GPU ROM/VBIOS to the EFI partition, usually inside the Clover misc folder. Copy the generated file and load it into ZeroRPMBuilder. This is useful when you want ZeroRPMBuilder to work with the exact VBIOS from your GPU. Main Features Native macOS application AMD GPU and PowerPlay table detection Automatic GFX0 detection Bundled gfxutil 1.84b Automatic OpenCore PCI Device Path detection VBIOS / PowerPlay table extraction SPPT import support Strict PowerPlay structure validation Automatic Clover/OpenCoreDeviceProperties generation Automatic device-id spoofing when required Automatic no-gfx-spoof for supported Lexa cases Offline patch generation for GPUs not installed in the current Mac Original SPPT backup Patched binary and hexadecimal exports OpenCore config.plist generation OpenCore DeviceProperties snippet generation Detailed export report No VBIOS flashing required Fan Presets ZeroRPM OFF — Fan Always On This mode disables the GPU's Zero RPM behavior. Only the Zero RPM enable field is changed. The original: fan start temperature fan stop temperature fan curve RPM limits thermal targets are preserved. This is intended for users who prefer the fans to remain available instead of entering the GPU's factory Zero RPM state. FAN 35°C — Stop 30°C This preset keeps Zero RPM enabled but changes the fan activation temperatures to: Fan Stop Temperature: 30°C Fan Start Temperature: 35°C Zero RPM: Enabled The GPU can stop its fans below the configured threshold and restart them at approximately 35°C. Only the required PowerPlay fan-control fields are modified. Supported AMD Architectures ZeroRPMBuilder currently supports validated PowerPlay layouts for: Polaris Polaris 10 Polaris 11 Polaris 12 / Lexa Polaris 20 Polaris 21 Polaris 23 Examples include: RX 460 RX 470 RX 480 RX 550 RX 560 RX 570 RX 580 RX 590 Radeon Pro WX series Vega 10 Including: RX Vega 56 RX Vega 64 Vega Frontier Edition Radeon Pro WX 8100 / 8200 / 9100 Vega 20 Including: Radeon VII Radeon Pro VII Navi 10 / Navi 14 Including: RX 5300 RX 5500 RX 5600 RX 5700 Radeon Pro W5500 Radeon Pro W5700 Navi 21 / Navi 22 / Navi 23 Including members of the: RX 6600 family RX 6700 family RX 6800 family RX 6900 family Radeon Pro W6600 / W6800 families The application currently recognizes 56 AMD PCI Device IDs across the supported PowerPlay families. Automatic DeviceProperties Detection ZeroRPMBuilder includes gfxutil 1.84b directly inside the application bundle. No Homebrew installation is required. The application first attempts: gfxutil -f GFX0 to obtain the real EFI PCI device path. Example: PciRoot(0x2)/Pci(0x0,0x0)/Pci(0x0,0x0) If gfxutil cannot resolve the device, ZeroRPMBuilder uses its internal IORegistry detector. If no usable GPU path can be determined, generation is still allowed through a generic fallback: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0) The user can also manually enter the required DeviceProperties path. Offline / Cross-GPU Patch Generation ZeroRPMBuilder does not require the target GPU to be installed in the Mac used to generate the patch. For example: Mac currently running: RX 6600 XT / Navi 23 Loaded VBIOS: RX 580 / Polaris The application will still generate the Polaris patch. The local GPU is used only when appropriate for DeviceProperties path detection. The loaded VBIOS/SPPT remains authoritative for the actual patch. This makes ZeroRPMBuilder useful for: preparing an EFI for another computer; preparing a patch before installing the GPU; building patches remotely; working with VBIOS dumps from another machine. A different GPU installed in the current Mac will no longer block generation. Automatic Device-ID Spoofing For selected GPUs that require a compatible PCI Device ID, ZeroRPMBuilder can automatically generate: device-id inside OpenCore DeviceProperties. Current automatic mappings include selected: Navi 21 Navi 23 Polaris Lexa Examples: 73EF → 73FF 73AF → 73BF 73A5 → 73BF and supported Lexa mappings such as: 699F → 67FF 6987 → 67FF 6995 → 67E3 6985 → 67E3 6981 → 67E3 The property is stored in the correct little-endian OpenCore format. Lexa no-gfx-spoof For the supported Lexa Device IDs that require the additional WhateverGreen behavior, ZeroRPMBuilder also generates: <key>no-gfx-spoof</key> <data>AQAAAA==</data> which corresponds to: 01 00 00 00 This is currently applied to: 699F 6987 6995 6985 6981 It is not added globally to every spoofed GPU. Generated OpenCore Properties A generated entry can look like: DeviceProperties └── Add └── PciRoot(...)/Pci(...)/Pci(...) ├── PP_PhmSoftPowerPlayTable ├── device-id └── no-gfx-spoof device-id and no-gfx-spoof are only added when applicable. The actual PowerPlay patch is stored as raw binary data in: PP_PhmSoftPowerPlayTable Safe PowerPlay Validation ZeroRPMBuilder does not blindly patch arbitrary offsets. Before modifying a table, it validates the expected PowerPlay structure for the detected architecture. Depending on the GPU family, validation can include: PowerPlay format revision content revision table revision declared structure size fan table revision fan table offset SMU PowerPlay version thermal controller type OverDrive table layout required field bounds If the loaded table does not match a supported structure, the application refuses to patch it. Unknown layouts are not guessed. What Does ZeroRPMBuilder Modify? Depending on the architecture, only the equivalent fields for: FanZeroRpmEnable FanStopTemp FanStartTemp are modified. ZeroRPMBuilder does not intentionally change: GPU core clocks memory clocks GPU voltage memory voltage power limits TDC limits fan curves minimum RPM maximum RPM fan target temperature OverDrive capability tables FeaturesToRun Original Table Preservation Before exporting the modified PowerPlay table, ZeroRPMBuilder preserves the original source. Generated packages can contain: Original SPPT Patched SPPT HEX export OpenCore config.plist OpenCore DeviceProperties snippet Generation report This makes it easier to compare or restore the original configuration. VBIOS Safety ZeroRPMBuilder does not flash your GPU. It does not write anything to the physical VBIOS. The modified PowerPlay table is applied through OpenCore: DeviceProperties → PP_PhmSoftPowerPlayTable Removing the property restores normal behavior without reflashing the graphics card. Built-in gfxutil ZeroRPMBuilder includes the official Acidanthera gfxutil 1.84b RELEASE universal binary: x86_64 arm64 It is used exclusively for PCI / EFI Device Path discovery. The application therefore does not require the user to install gfxutil separately. Credit for gfxutil belongs to its respective upstream authors and contributors. Testing The current release has been validated through automated regression, structural, parser and stress testing. The current development test set includes: Core regression tests: 405/405 Structural validation: 143/143 Swift parser checks: 13/13 AddressSanitizer tests: 405/405 ThreadSanitizer tests: 405/405 Stress testing: PASS Stress testing includes repeated: PowerPlay modifications; VBIOS extraction; PCI path parsing; OpenCore plist generation; ZIP generation; import/export operations. The patch matrix also covers both fan modes across all currently recognized GPU IDs. Important Notes PowerPlay tables can vary between: GPU generations; board partners; VBIOS revisions; OEM cards; workstation variants. ZeroRPMBuilder therefore validates the structure before writing anything. If a VBIOS contains an unknown PowerPlay layout, please provide the original ROM/SPPT so support can be investigated safely. Always keep a working EFI backup before modifying your OpenCore configuration. Feedback and Hardware Samples Compatibility reports are welcome. If a GPU is detected but its PowerPlay table is rejected, please include: exact GPU model; PCI Device ID; VBIOS ROM if possible; original SPPT; macOS version; ZeroRPMBuilder log. Additional real-world VBIOS samples help improve validation without resorting to unsafe generic offsets. Credits ZeroRPMBuilder ©DNMTechLabs dnmtechlabs@gmail.com Additional credit to the Acidanthera project and the authors/contributors of gfxutil, Lilu, WhateverGreen and the broader Hackintosh development community. Download ZeroRPMBuilder HERE AMD PowerPlay / Zero RPM patch generator for macOS and OpenCore. No VBIOS flashing. No permanent GPU modification.

Disable HT, dual socket dont work with HT enable in many cases

Yes. Have support.

I think this processor is kabylake

**UPDATE** Here are the most important improvements. 🔹 Major Intel HDMI / DisplayPort audio evolution Intel integrated graphics display audio received one of the largest development efforts in the project. Support was improved for shared-HDEF architectures and multiple Intel generations, with better framebuffer discovery, native audio-codec-info handling and stricter association between the HDA controller and the correct graphics device. HDMI/DP endpoints can now be matched using actual framebuffer topology instead of relying only on generic assumptions. 🔹 Native framebuffer audio topology HDAUniversal can use framebuffer-provided codec information to identify: • Codec Address • Audio Function Group • Digital Pin • Active display endpoint The discovered topology is cross-checked against the live HDA widget graph and ELD information before being accepted. Ambiguous mappings fail safely rather than selecting an arbitrary display output. 🔹 Improved Intel display-audio wake Display-audio codec wake handling was added for supported Intel generations. The implementation verifies the correct GPU, framebuffer, codec address, active endpoint and display state before interacting with the display-audio hardware. Wake attempts are bounded and protected against unsupported hardware. 🔹 Intel HDMI/DP mux improvements Intel Haswell-style digital mux handling was significantly expanded. Dynamic converter selection can now follow the actual codec topology instead of assuming a fixed converter. Multiple HDMI/DP pins are handled more safely, with retry and end-to-end validation of the selected path. 🔹 Better multi-monitor and MST support DisplayPort MST routing received additional protection around converter selection and Device Select state. Previous hardware state is preserved and can be restored if a route transaction fails. This significantly reduces the risk of leaving another display endpoint in an invalid state. 🔹 Linux-aligned Intel stripe control Intel display audio gained capability-driven WCAP_STRIPE support. Stripe configuration now considers: • controller NSDO capability • sample rate • sample width • channel count • converter capabilities • active stream descriptor Both converter and stream-descriptor programming are verified through hardware readback. If the physical commit cannot be confirmed, the previous state is restored. 🔹 Capability-driven HDMI/DP amplifier handling Digital pins that expose a hardware output amplifier can now be detected through their widget capabilities. Muted amplifier channels are selectively unmuted while preserving the existing gain value. The operation includes physical readback and rollback protection. This behavior is limited to qualified Intel display-audio routes and is not applied blindly to analog codecs or unrelated digital hardware. 🔹 Stronger hotplug handling HDMI/DisplayPort hotplug processing was extensively redesigned to eliminate lifecycle races. Framebuffer callbacks no longer perform heavy HDA operations directly. Events are safely transferred to the HDAUniversal workloop, while callback lifetime is protected during detach, sleep and teardown. This also addresses scenarios involving rapid monitor connection/disconnection. 🔹 Deadlock prevention Lock ordering between framebuffer events and HDA runtime operations was hardened. Registry operations, notifier callbacks and graphics discovery are kept outside inappropriate HDA lock regions. This reduces the risk of WindowServer or graphics-stack stalls during HDMI/DP hotplug events. 🔹 Late framebuffer metadata recovery HDAUniversal can now recover when framebuffer audio metadata is not available during the first hardware scan. A bounded retry mechanism allows audio-codec-info to appear later without permanently losing the HDMI/DP endpoint. Retries stop automatically after the metadata becomes valid or the defined retry budget is exhausted. No unlimited polling is used. 🔹 Connection List parser hardening Malformed HDA Connection List ranges are now handled safely. Invalid range entries can be skipped without corrupting neighboring valid connections, selector indices or downstream routes. This behavior was aligned more closely with proven Linux HDA parsing strategies. 🔹 Physical route qualification Route discovery became more rigorous. A route can now be physically qualified by checking: • Pin direction • Widget type • Converter direction • Connection graph • Canonical path edges • DAC/ADC reachability • Pin capabilities This prevents a semantic label from overriding an impossible physical topology. 🔹 Route Authority separated from hardware qualification Detecting a valid physical path no longer automatically gives that path authority over the selected layout. This preserves an important project principle: the selected layout remains authoritative unless explicit runtime route authority is enabled. Live codec discovery is used as a fallback when layout information is absent, not as an uncontrolled replacement. 🔹 AppleALC-style layout authority preserved User-selected layouts remain the primary source for: • Pin configuration • Routing • PathMap • Codec-specific initialization Live codec data cannot silently replace a valid selected layout. This makes behavior more predictable across different machines using the same codec. 🔹 Advanced combo-jack support Combo-jack handling was extensively redesigned. Headphone and microphone detection are treated independently. A simple TRS headphone is no longer incorrectly interpreted as a headset microphone. CTIA/OMTP headset routing can be handled through explicit layout policy while ordinary layouts retain their existing behavior. 🔹 Improved microphone and headset transitions Headset state changes now use transactional routing. If a new microphone or headphone route cannot be fully committed, HDAUniversal can restore the previous verified state. This prevents partial jack transitions from leaving the codec incorrectly configured. 🔹 Smarter jack detection Jack monitoring received major efficiency improvements. HDAUniversal prioritizes unsolicited codec events whenever they are reliable. Physical polling becomes a fallback rather than the default source of constant hardware traffic. 🔹 Automatic unsolicited-event recovery When unsolicited jack events stop behaving correctly, HDAUniversal can temporarily enable fallback polling and later attempt to restore event-driven operation. This provides recovery without forcing permanent aggressive polling. 🔹 Adaptive jack fallback Fallback polling uses bounded timing and backoff. Stable hardware is queried less frequently, reducing unnecessary verb traffic while still allowing physical changes to be detected. 🔹 Corrected analog fallback latency A timing interaction that could accidentally increase non-combo jack polling from approximately hundreds of milliseconds into multi-second intervals was identified and corrected. Normal analog fallback detection once again operates at the intended responsive cadence. 🔹 Bluetooth / A2DP idle isolation Idle HDA behavior was reduced where unnecessary so that the driver avoids generating avoidable hardware activity while another audio transport is active. The implementation deliberately avoids making unsupported assumptions about the Bluetooth stack itself. 🔹 Transactional output routing Output routing now follows a stricter transaction model. Before changing hardware, previous codec state can be captured. After programming, the result is verified. If verification fails, HDAUniversal attempts a controlled rollback rather than continuing with a partially configured route. 🔹 Transactional input routing The same fail-safe model was expanded to input and capture paths. ADC selection, mixers, PinControl, amplifier state and related routing components can participate in verified route transactions. 🔹 Fail-closed recovery One of the most important architectural changes was the wider adoption of fail-closed behavior. If a hardware transaction fails and the previous known-good state cannot be restored, HDAUniversal avoids pretending that the route is valid. Unknown codec state is treated as unsafe. 🔹 Verified rollback Rollback itself is no longer assumed to succeed. Critical restoration paths can be physically verified through codec readback. This applies to several routing, initialization, capture and digital-output operations. 🔹 Capture lifecycle hardening Capture start, stop and rollback paths received additional protection. Partial ADC or stream ownership cannot silently remain active after a failed capture transaction. Lease and ownership states are kept consistent with the actual hardware state. 🔹 Exact Init safety Codec-specific initialization sequences were integrated more tightly with transactional state management. Initialization failures can participate in the same verification and rollback model instead of leaving partially programmed codec state behind. 🔹 Controller stability audit Low-level HDA controller operations were reviewed for compliance and stability. Work included: • CORB handling • RIRB handling • stream format programming • register access • bounded transport recovery • controller reset boundaries • DMA lifecycle protection 🔹 Sleep / wake improvements Command transport, framebuffer state, timers and codec state received additional lifecycle protection across system sleep and wake. The driver avoids freeing resources when hardware quiescence cannot be proven. This favors safety over aggressive cleanup. 🔹 Timer lifecycle hardening Timer creation, arming, cancellation and teardown were audited. Timers are armed with a new deadline before being enabled, preventing stale deadlines from being accidentally reused. Callback draining is also coordinated with teardown. 🔹 Framebuffer lifecycle cleanup Graphics resources, notifier objects and framebuffer references are released through safer lifecycle boundaries. Races between discovery, callback execution and driver shutdown received additional protection. 🔹 Release signing integrity The build pipeline was hardened so Release artifacts consistently use the expected signing model. Nested Mach-O components are processed correctly instead of assuming that only the main kext executable requires handling. 🔹 Executable-mode integrity Release packaging now verifies that executable permissions survive every stage of the build/package process. Nested binaries remain executable inside the final bundle instead of depending on filesystem luck. 🔹 Stronger release validation The project now uses an extensive regression matrix covering previous fixes as new functionality is introduced. Validation includes areas such as: • layouts and codecs • routing • jack handling • HDMI/DP • MST • capture • controller transport • sleep/wake • rollback • framebuffer lifecycle • release packaging • signing • resource integrity 🔹 Expanded hardware database HDAUniversal continued expanding its codec and layout database while preserving strict (Codec ID + Layout ID) identity. New layouts can coexist for the same codec without changing existing configurations. ⚙️ What these development cycles represent The biggest change is not a single codec or feature. HDAUniversal has progressively moved toward a hardware-verified, transactional and fail-safe HDA architecture. Instead of assuming that a verb worked, critical operations can verify the hardware. Instead of accepting an ambiguous route, the driver can reject it. Instead of leaving partially programmed state behind, transactions can roll back. Instead of continuously polling hardware, event-driven mechanisms are preferred and polling becomes a controlled fallback. And instead of letting runtime discovery override everything, the user-selected layout remains authoritative. The goal remains simple: broader HDA hardware compatibility on macOS while maintaining predictable behavior, strong isolation and strict hardware-state control.

With one GPU with support yes

We are releasing a version of VoodooI2C with VoodooI2CSynaptics that includes a specific fix for Sleep/Wake issues affecting Synaptics trackpads. On some laptops, the Synaptics trackpad works normally after boot, but stops responding after macOS enters Sleep and wakes up again. The device may still remain present in the system, but the RMI communication/interrupt state is not properly restored after wake. This version introduces specific power-management handling inside VoodooI2CSynaptics. What does the fix do? During Sleep, the driver tracks the device power-state transition. After Wake, VoodooI2CSynaptics performs the required recovery procedure to restore proper trackpad operation, including: restoring RMI ATTN mode; restoring the F01 interrupt mask; dedicated handling through IOKit power states; preventing unnecessary reinitialization when the trackpad is already awake; dedicated Sleep/Wake diagnostic messages. When the recovery succeeds, the driver reports: Woke up from Sleep! RMI ATTN mode restored. There are also specific diagnostic messages if any part of the recovery procedure fails: Wake recovery failed to restore RMI ATTN mode Wake recovery failed to restore F01 interrupt mask If the device is already active, the driver reports: Trackpad already awake! Not reinitializing. Version The provided package contains: VoodooI2C 2.9.1 VoodooI2CSynaptics 1.0 Current architecture: x86_64 The current build is configured for the Synaptics device identified as: SYNA2B61 Please verify the ACPI device name of your trackpad before using this version. Purpose of this fix The main goal is to address the common behavior where: Boot → Trackpad works → Sleep → Wake → Trackpad stops working With this fix, the RMI state required for trackpad interrupts is restored during Wake, allowing the device to remain operational without requiring a macOS reboot. Check the trackpad device name in IORegistryExplorer (IOReg) for each laptop, then replace the existing device name in the VoodooI2CSynaptics.kext Info.plist with the correct one for your hardware. Download: VoodooI2CSynaptics.zip Credits to the original VoodooI2C project and its developers. This version keeps the original project base while adding the Synaptics Sleep/Wake handling described above.