NootedRed v0.9.0-pre-release.15

NootedRed v0.9.0-pre-release.15

This pre-release focuses on unified macOS compatibility, improved patch reliability, and GPU initialization stability.

The main changes include a unified patching architecture for macOS Sonoma, Sequoia, and Tahoe, improved dynamic cache compatibility, and fixes for GPU engine allocation failures.

Unified macOS Support

The Metal and VCN user-space patching paths have been unified across:

• macOS Sonoma 14 (Darwin 23)
• macOS Sequoia 15 (Darwin 24)
• macOS Tahoe 26 (Darwin 25)

All three versions now use version-specific patch data with the same dynamic resolution and verification architecture.

• Extended Sonoma support to include SRD, LegacyBlend, ComputeScratch, SubmitGuard, and experimental VCN 2.2 acceleration.
• Removed legacy fixed-offset patching paths and unnecessary version-specific implementations.
• Unified patch verification, dependency handling, private COW transactions, and rollback behavior.
• Preserved native synchronization behavior and existing OpenGL fixes.

Hardware validation is still required, particularly for the newly unified Sonoma implementation.

Dynamic Patch Compatibility

• Improved compatibility with updated macOS shared caches, including macOS Tahoe 26.7.2.
• Metal, ComputeScratch, SubmitGuard, and video patches now use dynamic function and reference resolution across all three macOS versions.
• Removed fixed-offset SubmitGuard resolution and unnecessary legacy cache dependencies.
• Improved ComputeScratch matching by removing an unrelated VideoToolbox dependency.
• Retained full-function verification, reference validation, and automatic rejection of incompatible patch locations.

These changes are intended to improve compatibility with macOS updates without weakening patch validation.

GPU Stability Improvements

• Fixed an issue where GPU initialization could continue even after a required PM4 or SDMA engine allocation failed.
• Improved failure handling and resource cleanup during hardware engine initialization.
• Preserved the existing optional VCN engine allocation behavior.

Video Hardware Acceleration

Experimental VCN 2.2 hardware acceleration remains available for supported APUs, including H.264/HEVC decoding and encoding and experimental HEVC Main10 support.

The video patching architecture is now shared across Sonoma, Sequoia, and Tahoe.

System Integrity Protection (SIP)

NootedRed applies userspace patches to Apple's native graphics drivers. These modifications require certain SIP protections to be disabled.

Recommended OpenCore configuration:

csr-active-config: 430A0000

• 430A0000 — Recommended for NootedRed userspace patching.
• 00000000 — Fully enabled SIP, which may prevent modified executable pages from being accepted.

With SIP fully enabled, macOS may terminate processes such as WindowServer due to code-signing enforcement, resulting in a black screen during graphics initialization.

Boot Arguments

• -NRedDisplayFix — Enable Metal and OpenGL rendering fixes.
• -NRedVideoFix — Enable experimental VCN hardware acceleration.
• NRedECFix=1 — Optional EC backlight support.
• -NRedNoFVRC — Disable verified resolution caching for troubleshooting.

FVRC remains enabled by default. No additional boot argument is required.

Known Limitations

• The newly unified macOS patching paths still require broader real-hardware testing.
• VCN hardware acceleration remains experimental and may vary between devices and macOS versions.
• FairPlay-protected video playback is not yet fully functional.
• GPU resets, sleep/wake behavior, and application-specific issues still require additional investigation.

Please report issues with your GPU PCI ID, macOS version and build number, and relevant logs.

This is an experimental pre-release. Keep a working backup before updating.

Source: 690e6c5

NootedRed v0.9.0-pre-release.14

NootedRed v0.9.0-pre-release.14

This pre-release focuses on HEVC Main10 hardware encoding, VCN compatibility, and patch reliability improvements.

The main changes include experimental 10-bit hardware encoding support, removal of the previous codec interception guards, and improved patch validation.

HEVC Main10 Hardware Encoding

• Added experimental HEVC Main10 (10-bit) hardware encoding support for VCN 2.2 APUs.
• Updated AppleGVA encoding capabilities to expose the Main10 profile.
• Improved 10-bit input handling and P010 pixel format processing.
• Corrected bit-depth handling when 10-bit textures are passed through NV12 encoder contexts, while preserving source texture pitch calculations.
• Added additional tests for 10-bit encoding and pixel output verification.

Hardware diagnostics for the Main10 implementation passed H.264, HEVC Main, and HEVC Main10 tests, including 1080p Main10 encoding across 60 frames.

These results do not establish full compatibility across all devices and applications.

VCN Codec Handling

Removed the previous experimental codec format and dimension interception guards.

• Removed custom encoding dimension checks and H.264 SPS format restrictions.
• Removed the additional private RX guard page and its associated interception logic.
• Simplified video patch installation while retaining verified function matching, patch transactions, and rollback handling.
• Left codec capability and format decisions to the native video stack without the additional experimental guard layer.

This change removes the custom restrictions but does not guarantee that every codec, profile, or resolution is supported by the hardware.

Patch Reliability

• Fixed an issue in the Verified Patch Framework (VPF) where partially overlapping patch sites could be accepted.
• Improved patch boundary validation while allowing valid adjacent patch sites.
• Preserved the existing verified patch execution and rollback mechanisms.

Boot Arguments

• -NRedDisplayFix — Enable Metal and OpenGL rendering fixes.
• -NRedVideoFix — Enable experimental VCN hardware acceleration.
• NRedECFix=1 — Optional EC backlight support.
• -NRedNoFVRC — Disable verified resolution caching for troubleshooting.

FVRC remains enabled by default. No additional argument is required.

Known Limitations

• VCN acceleration and HEVC Main10 support remain experimental.
• Hardware video patching is currently limited to the supported VCN 2.2 devices on macOS 15 and macOS 26. macOS 14 still lacks the required user-space video patch data.
• Removal of the codec guards has not been fully validated across hardware and application workloads.
• FairPlay-protected video playback remains unresolved.
• Compatibility may vary depending on the APU, macOS build, and video application.

Please report any issues with your GPU PCI ID, exact macOS version, NootedRed build, and relevant logs.

This is an experimental pre-release. Keep a working backup before updating.

Source: 62405e6

NootedRed 0.9.0 Pre-release.13

NootedRed v0.9.0-pre-release.13

This pre-release focuses on stability, patch coordination, and further performance improvements across Metal, OpenGL, and experimental VCN hardware acceleration.

Stability and Reliability

• Fixed an issue where the shared Display/Video patch coordinator could fail to recognize registered callbacks due to state being duplicated across kernel extension compilation units.
• Improved coordination between rendering and video patches to ensure the intended shared transaction mechanism is used.
• Strengthened patch installation checks for Metal and OpenGL.
• Rendering patches are now prevented from being installed when required SubmitGuard preparation or dependency verification fails.
• Improved patch-state tracking and failure reporting.

These changes address potential patch installation inconsistencies and improve the reliability of the unified patch architecture.

Performance Improvements

• Further optimized dynamic shared-cache scanning to reduce CPU overhead during patch resolution.
• Improved candidate filtering for Metal display functions, SubmitGuard, and video safety guards.
• Reduced unnecessary scanning work while preserving full-function verification and duplicate-match rejection.
• Retained the FastScan + Verified Resolution Cache (FVRC) architecture for reusing verified patch locations across compatible processes.

FVRC remains enabled by default, with automatic fallback to full scanning when cached locations cannot be verified.

VCN Hardware Acceleration

• Retained experimental VCN 2.2 H.264/HEVC hardware decoding and encoding support.
• Preserved the 1080p encoding alignment fix and existing video safety checks.
• Improved coordination between video and display patch installation.

Hardware acceleration remains experimental and requires further testing across supported devices.

Boot Arguments

• -NRedDisplayFix — Enable Metal and OpenGL rendering fixes.
• -NRedVideoFix — Enable experimental VCN hardware acceleration.
• NRedECFix=1 — Optional EC backlight support.
• -NRedNoFVRC — Disable verified resolution caching for troubleshooting.

FVRC is enabled automatically. No additional boot argument is required.

Older individual rendering and VCN boot arguments are no longer supported.

Issue Reporting

Updated the GitHub issue templates to make bug reports, feature requests, and hardware compatibility reports easier to submit.

When reporting an issue, please include your GPU PCI ID, exact macOS version, NootedRed build, reproduction steps, and relevant logs.

Known Limitations

• VCN hardware acceleration is still experimental.
• macOS 14 VCN user-space adaptation remains unavailable where the required safety verification is missing.
• FairPlay-protected video playback is not yet fully functional.
• Some graphics or application-specific issues may remain unresolved.
• Further real-hardware validation is needed for the latest changes.

This is an experimental pre-release. Please keep a working backup before updating.

Source: 7ef0c4b

NootedRed 0.9.0 Pre-release.12

NootedRed v0.9.0-pre-release.12

This pre-release focuses on performance, stability, and architectural improvements across Metal, OpenGL, and experimental VCN hardware acceleration.

The biggest changes include faster dynamic patch resolution, verified cache reuse, improved patch coordination, and additional video encoding fixes.

Performance Improvements

• Significantly reduced dynamic shared-cache scanning overhead through optimized function matching, memory reads, and candidate filtering.
• Introduced FastScan + Verified Resolution Cache (FVRC) to reuse previously verified patch locations across compatible processes.
• FVRC is now enabled by default. Cached locations are revalidated before use, with automatic fallback to full scanning if verification fails.
• Reduced additional overhead from memory mapping checks and kernel stack usage.

These improvements aim to reduce patching overhead without sacrificing compatibility or validation safety.

Video and Display Architecture

Introduced the Verified Patch Framework (VPF) and Display Verified Patch Framework (DVPF).

• Unified patch verification, dependency management, and transaction handling across video and display components.
• Improved coordination between Metal and video patches to reduce unnecessary blocking during process initialization.
• Preserved OpenGL's validated page-based patching mechanism.
• Improved rollback handling, resource management, and per-process patch state tracking.

VCN Hardware Acceleration

• Fixed an issue where valid 1920×1080 H.264/HEVC encoding could be rejected because the encoder used aligned dimensions of 1920×1088.
• Improved encoder surface validation while preserving existing hardware safety limits.
• Added safeguards against unsupported H.264 bit depths, chroma formats, and invalid encoding dimensions.
• Improved video client lifecycle management to prevent patch-state exhaustion after repeated process creation.

Isolated 1080p H.264/HEVC hardware encoding tests have passed with decoded-output verification. Normal XPC-based workflows and broader hardware compatibility still require additional testing.

Boot Arguments

The following options are available:

• -NRedDisplayFix — Enable Metal and OpenGL rendering fixes.
• -NRedVideoFix — Enable experimental VCN hardware acceleration.
• NRedECFix=1 — Optional EC backlight support.
• -NRedNoFVRC — Disable verified resolution caching for troubleshooting.

FVRC is enabled automatically. No additional boot argument is required.

The older individual rendering and VCN boot arguments are no longer supported.

Known Limitations

• VCN hardware acceleration remains experimental and is not fully validated across all supported GPUs and macOS versions.
• The VCN user-space patch path on macOS 14 remains disabled where the required safety verification is unavailable.
• FairPlay-protected video playback is not yet fully functional.
• Additional hardware testing is required to confirm stability during sustained workloads, process restarts, and sleep/wake cycles.

If you encounter rendering corruption, freezes, performance regressions, or video acceleration issues, please report them with your GPU PCI ID, macOS version, and relevant logs.

This is an experimental pre-release. Please keep a working backup before updating.

Source: 4ab2211

NootedRed 0.9.0 Pre-release.11

NootedRed 0.9.0 Pre-release.11

Experimental Pre-release — Shared Cache Relocation Fix

This release addresses a compatibility issue that could prevent existing rendering and video acceleration fixes from being applied on certain macOS builds.

I've noticed that some users were still experiencing GPU stuttering and rendering instability even with the previous fixes enabled.

After further investigation, I found that some of the fixes were not actually being applied, despite their boot arguments being enabled.

The issue was caused by changes in how macOS organizes data sections within the dyld shared cache.

Pre-release.11 improves dynamic cache resolution to handle these relocations while preserving the existing code validation and patching safety checks.

Source commit:

4e8e5e2

Changes since pre-release.10:

v0.9.0-pre-release.10...4e8e5e2

1. Fixed Shared-Cache Relocation Compatibility

The previous dynamic patch resolver already supported relocated driver images and functions.

However, some external data references were still validated using fixed offsets relative to the original image base.

On certain macOS builds, sections such as __DATA and __DATA_CONST can be relocated independently.

As a result, the native driver code could remain compatible while its external data references pointed to different locations.

The previous resolver would incorrectly reject these otherwise compatible functions.

This could prevent several existing fixes from being applied, including:

• ComputeScratch allocation corrections.
• Metal rendering and LegacyBlend fixes.
• VCN userspace video patches.

In other words, enabling -NRedDisplayFix or -NRedVideoFix did not necessarily mean the corresponding userspace patches had successfully taken effect.

What changed?

The new resolver identifies external data targets using:

• Driver image path.
• Mach-O segment name.
• Section name.
• Offset within the section.

This allows independently relocated data sections to be recognized without requiring their original fixed addresses.

Full instruction validation, reference checking, and compatibility rejection rules remain in place.

Unknown function implementations, incompatible data layouts, and unsupported driver ABI changes are still rejected.

This is not a blanket relaxation of patch validation or a new macOS version whitelist.

2. Investigation of GPU Stuttering

During investigation on a Ryzen 7 5800H (Cezanne, PCI ID 1002:1638) running macOS Tahoe 26.7.2 (25G332), the previous build showed recurring GPU resets.

Multiple reports involved mediaanalysisd and its computeUQ3 / VTMTSComputeFunction workload.

The symptoms included periodic desktop and mouse stuttering.

Further inspection showed that rendering and ComputeScratch features had been registered, but their expected Applied indicators were missing.

Testing against the actual shared cache confirmed that the previous resolver rejected several valid display, Scratch, and video patch plans.

The investigation also identified relocation-only differences in the Metal rendering pipeline constructor, rather than changes to its actual instruction logic.

This explains why some users could still experience the original problems even after enabling the fixes: the patches could be rejected before they were applied.

Pre-release.11 corrects the identified matching problem.

However, the updated build still requires post-installation hardware testing to confirm whether the observed GPU resets and stuttering have been resolved.

3. Improved Metal and SubmitGuard Compatibility

The Metal pipeline constructor now supports relocation-aware validation.

The implementation verifies the original function's non-relocation instructions and external references instead of requiring every relocation field to retain its reference value.

The existing blending correction remains selective; unrelated rendering behavior is preserved.

On Tahoe, SubmitGuard can now dynamically locate and validate the complete command-submission method even when the shared-cache UUID differs from the reference build.

Previously, an unknown cache UUID could prevent SubmitGuard from being installed.

The updated implementation retains the existing trampoline, memory-protection, and rollback checks.

The dynamic resolver also reuses previously discovered image information to avoid unnecessary repeated scanning.

4. Validation

The latest changes have passed:

• Debug, Research Release, and Release builds.
• Static analysis across all three configurations.
• 16 related regression checks.
• Independent data-section relocation tests.
• Full-function and external-reference validation.
• Rejection tests for unexpected instruction changes and invalid references.
• Existing Sequoia and legacy compatibility checks.
• Real shared-cache patch-plan verification.

In the investigated Tahoe shared cache:

• 6 Vega APU display patch plans resolved successfully.
• 4 VCN 2.2 video patch plans resolved successfully.
• The complete SubmitGuard command-submission method was successfully located and validated.

All plans remained within the existing resolver read budgets.

These results confirm that the identified cache-matching failures have been addressed in offline validation. They do not yet establish that GPU stuttering or resets are completely resolved on real hardware.

5. Boot Arguments

No new boot arguments are required.

For rendering fixes:

-NRedDisplayFix

For experimental VCN hardware acceleration:

-NRedVideoFix

Both can be enabled together:

-NRedDisplayFix -NRedVideoFix

Optional EC brightness control remains available using NRedECFix=1, only on laptops that require it.

The OpenGL fixes introduced in pre-release.10 are also retained under -NRedDisplayFix.

6. How to Check Whether the Fixes Are Applied

After installing the new build and rebooting, you can inspect the relevant IORegistry properties:

ioreg -lw0 -r -n IGPU | grep -E 'NRed(CacheSectionRevision|ComputeScratchApplied|LegacyBlendWindowServerApplied|SubmitGuardWindowServerApplied|VCNUserApplied)'

The new implementation reports:

NRedCacheSectionRevision = 1

The corresponding Applied properties should appear after the relevant processes load and the patches are successfully installed.

Please note that an enabled feature is not necessarily an applied patch.

Similarly, successful patch installation does not by itself guarantee that every GPU workload is stable.

7. Known Limitations

This remains an experimental release.

• The GPU stuttering investigation identified a real patch-rejection issue, but the final hardware outcome still requires testing.
• The dynamic resolver cannot automatically support arbitrary driver changes or incompatible ABI layouts.
• Existing Sonoma and Sequoia compatibility restrictions remain in effect.
• VCN 1.x hardware acceleration is still unsupported.
• HDR-specific experimental fixes are not included.
• FairPlay-protected video playback and complete DRM support remain unresolved.
• Long-duration stability and sleep/wake behavior still require additional testing.

If you previously experienced stuttering despite enabling the display fixes, I especially encourage you to test this release and check whether the patches are now being applied correctly.

Please include your APU model, GPU PCI ID, macOS version and build, relevant IORegistry properties, and any .gpuRestart or kernel panic reports when submitting feedback.

Back up your working EFI and NootedRed.kext before updating.

Acknowledgements

Thanks to everyone who reported continuing rendering problems and GPU stuttering. Your feedback helped identify a case where the existing fixes could be silently rejected by the compatibility checks.

Special thanks to weachy/NootedRed, Kingtous, and the original ChefKissInc/NootedRed developers for their contributions to the project and its underlying compatibility work.

---

This update focuses on making the existing fixes apply correctly on compatible relocated shared caches. It is not a claim that all GPU stuttering, rendering, or video acceleration problems have been resolved.

NootedRed 0.9.0 Pre-release.10

NootedRed 0.9.0 Pre-release.10

Experimental pre-release

This is an unofficial development fork of NootedRed. The new OpenGL fixes have been validated against reference driver code and regression tests, but application-level hardware testing is still recommended.

This release builds on pre-release.9 and introduces a new set of OpenGL rendering fixes for Vega APUs, alongside the existing Metal rendering, ComputeScratch, and VCN improvements.

The main focus is correcting OpenGL shader-engine topology and dual-source blending behavior while keeping the patching process safe, selective, and compatible with multiple macOS versions.

Source commit:

f8179e5

Changes since pre-release.9:

v0.9.0-pre-release.9...f8179e5

1. New OpenGL SE/CU Topology Fix

This release adds a dedicated OpenGL patching path for the AMDRadeonX5000GLDriver.

The first correction targets _gfx9_HwInfoInitData, which initializes GFX9 hardware information.

For the selected Vega APU, the patch corrects the reported shader-engine count to 1 SE, while preserving the native compute-unit calculation.

The implementation:

• Applies the correction only to the matching integrated GPU.
• Preserves native hardware identification for other devices.
• Retains the original 32-bit CU calculation.
• Preserves unrelated hardware information and capability flags.
• Does not modify Metal's hardware topology or synchronization behavior.

This addresses a potential mismatch between the GPU topology reported to the OpenGL driver and the actual Vega APU configuration.

2. New OpenGL DualQuad Blending Fix

The second correction targets:

_glrAMD_GFX9_UpdateHwCbDualQuadMode

For affected Vega APUs, the patch sets CB_COLOR_CONTROL.DISABLE_DUAL_QUAD when dual-source blending is used.

The correction is deliberately conditional.

It does not disable DualQuad globally or alter normal rendering paths unnecessarily.

The implementation preserves:

• Native behavior for ordinary rendering.
• The original capability checks for unrelated GPUs.
• Existing PM4 command-submission logic.
• Other rendering and blending operations.

This complements the existing Metal LegacyBlend corrections by addressing the corresponding OpenGL rendering path.

3. Safer OpenGL Patching and Dynamic Matching

Unlike the Metal driver, the OpenGL driver is loaded from a separate file rather than through the same shared-cache patching path.

Pre-release.10 introduces a dedicated page-validation-based mechanism.

The implementation:

• Runs the native macOS code-signing validation first.
• Accepts the supported successful validation results, including XNU's 0xF whole-page bitmap.
• Checks page validity, taint, and non-executable status before patching.
• Matches the complete expected code block within the currently validated 4 KiB page.
• Supports compatible function relocation without relying exclusively on fixed file offsets.
• Rejects unknown bytes, ambiguous matches, incompatible references, and cross-page candidates.
• Restores memory write protection after patching.

The original driver file on disk and the native code-signing validation result are not modified.

The new implementation also removes the need for startup file preparation.

It does not perform driver-file I/O, Mach-O parsing, or heap allocation inside the page-validation path.

Diagnostic reporting is deferred outside the validation callback, and small noinline entry functions help control kernel stack usage.

These changes are intended to reduce unnecessary work during driver loading while retaining strict validation and failure handling.

4. macOS and Hardware Compatibility

The OpenGL fixes are integrated into the existing display-fix infrastructure for:

• macOS Sonoma 14 / Darwin 23
• macOS Sequoia 15 / Darwin 24
• macOS Tahoe 26 / Darwin 25

The implementation uses device-specific patch data for the six Vega APU PCI IDs already recognized by NootedRed:

1002:15D8
1002:15DD
1002:15E7
1002:1636
1002:1638
1002:164C

This is an OpenGL rendering compatibility feature. It does not enable VCN 2.2 on the VCN 1.x devices.

Validation status

The original OpenGL driver pages have been verified against local reference data for:

• Sequoia 15.8.1 (24H32)
• Tahoe 26.7.1 (25G241)

Sonoma currently uses verified reference data but has not completed equivalent local-file or real-hardware validation.

Earlier Sequoia 15.8.1 hardware testing remains valid for the previously implemented display and video paths.

The new OpenGL functionality still benefits from application-level testing, particularly OpenGL drawing, dual-source blending, mixed OpenGL/Metal workloads, and sleep/wake behavior.

5. Boot Arguments

No new boot arguments are required.

OpenGL and Metal rendering fixes are now enabled together using:

-NRedDisplayFix

For rendering fixes and experimental VCN hardware acceleration:

-NRedDisplayFix -NRedVideoFix

For laptops requiring the optional EC backlight workaround:

NRedECFix=1

Do not enable EC backlight control if your laptop's native brightness adjustment already works correctly.

Older experimental arguments such as -NRedComputeScratch, -NRedVCN, and the previous standalone OpenGL development switches are not supported.

6. Validation and Diagnostics

This update adds dedicated regression coverage for:

• Native SE/CU calculation and device isolation.
• Conditional DualQuad behavior and PM4 submission.
• Complete code-block matching and dynamic relocation.
• All valid in-page patch locations.
• Unknown bytes, conflicting candidates, and cross-page rejection.
• Native page/range validation callbacks.
• Code-signing validation status, taint, and NX handling.
• Memory-write failures and protection restoration.
• Bounded diagnostics and kernel stack usage.

The implementation also introduces the following IORegistry diagnostics:

NRedOpenGLRevision = 5
NRedOpenGLPageLocal = 1
NRedOpenGLEnabled
NRedOpenGLSEApplied
NRedOpenGLDualQuadApplied
NRedOpenGLDynamicApplied
NRedOpenGLWriteRejected
NRedOpenGLRestoreFailed

NRedOpenGLDynamicApplied=1 indicates that both fixes matched through the dynamic page-local resolution path. It is not required when the exact reference-page path is used.

A successful patch status does not by itself guarantee correct OpenGL rendering.

Real application testing is still important.

7. Existing Features and Known Limitations

The existing features from pre-release.9 are retained:

• Metal LegacyBlend and rendering corrections.
• Shared SRD and ComputeScratch fixes.
• SubmitGuard command-buffer protection.
• Experimental VCN 2.2 H.264/HEVC hardware encoding and decoding.
• Dynamic Sequoia and Tahoe userspace cache matching.
• Optional EC backlight control.
• Experimental FairPlay client compatibility improvements.

Known limitations remain:

• OpenGL fixes require further testing across different APUs and applications.
• Unknown or incompatible driver implementations may be rejected.
• VCN 1.x hardware acceleration remains unsupported.
• HDR-specific experimental fixes are not included.
• FairPlay-protected video playback and complete DRM support remain unresolved.
• Long-duration stability and sleep/wake behavior across different hardware configurations need further testing.
• Vega discrete GPU support has not been added.

Please keep a backup of your working EFI and NootedRed.kext before testing.

Feedback is welcome, especially regarding OpenGL rendering corruption, blending issues, application compatibility, and any startup or stability regressions.

Acknowledgements

Special thanks to weachy/NootedRed for the OpenGL reference research and earlier multi-macOS compatibility work.

Thanks to Kingtous for the shared-region stack improvements, and to the original ChefKissInc/NootedRed developers.

Thanks also to everyone who continues testing these experimental builds and reporting issues.

---

This remains an unofficial experimental development release. The new OpenGL corrections extend Vega APU compatibility, but successful patch installation should not be confused with complete hardware validation.

NootedRed 0.9.0 Pre-release.9

NootedRed 0.9.0 Pre-release.9

Experimental pre-release

This is an unofficial development fork of NootedRed. The expanded Sequoia compatibility paths have passed automated regression tests and have now been validated on real hardware running macOS Sequoia 15.8.1 (24H32).

This release builds on pre-release.8 and focuses on bringing the rendering and VCN userspace improvements previously developed for macOS Tahoe to macOS Sequoia 15.

The main changes include:

• Expanded Sequoia rendering support with Shared SRD and ComputeScratch fixes.
• Dynamic Sequoia userspace patch resolution without requiring an exact dyld shared-cache UUID.
• H.264/HEVC video pitch, swizzle, and encoder feedback corrections for Sequoia.
• Improved SubmitGuard compatibility through complete function matching.
• Expanded Sequoia FairPlay client compatibility while preserving native AppleGVA and encoder behavior.

The new Sequoia implementation has been tested on real hardware running macOS 15.8.1 (24H32). Compatibility with other Sequoia versions and APU configurations may still vary.

Source commit:

ac1a08e

Changes since pre-release.8:

v0.9.0-pre-release.8...ac1a08e

1. Expanded Sequoia Rendering Support

Previous releases introduced LegacyBlend and SubmitGuard support for macOS Sequoia.

Pre-release.9 extends this implementation with additional rendering fixes previously available on Tahoe.

The Sequoia display-fix path now includes:

• Shared SRD: Corrects affected resource allocation and descriptor handling.
• LegacyBlend: Applies the verified RB+ / dual-source blending correction.
• ComputeScratch: Corrects scratch allocation behavior for supported Vega APUs.
• SubmitGuard: Protects against invalid or stale commands in unused AMD command-buffer regions.

These fixes use independently generated Sequoia driver data rather than reusing Tahoe-specific function offsets.

Native synchronization preserved

The implementation preserves the original driver's deferred synchronization behavior.

The experimental ImmediateSync modification remains disabled, allowing rendering and resource-layout corrections without forcing additional synchronization changes.

Sequoia-specific ComputeScratch

The Sequoia implementation uses a separately verified 456-byte native ComputeScratch function.

The patch generator validates the original function and creates device-specific replacements while preserving unrelated allocation and cleanup behavior.

The existing Vega APU device classification is retained.

The expanded Sequoia rendering implementation has now been tested on real hardware running macOS 15.8.1 (24H32).

Further feedback from other APUs and Sequoia builds is welcome.

2. Dynamic Sequoia Shared-Cache Resolution

One of the most important changes in this release is the extension of dynamic userspace cache resolution to macOS Sequoia.

Previously, Sequoia userspace patches depended on a specific reference dyld shared-cache UUID and layout.

Pre-release.9 can locate compatible functions dynamically, even when the shared-cache UUID differs from the reference build.

The resolver now supports Sequoia-specific matching for:

• Shared SRD initialization.
• LegacyBlend and pipeline construction.
• ComputeScratch allocation.
• SubmitGuard command submission.
• VCN video-driver functions.

Instead of assuming fixed offsets, it locates the relevant driver images and verifies complete native functions, relative references, and required external targets.

Compatibility requirements

The new reference data was generated from macOS Sequoia 15.8.1 (24H32), which has also been validated on real hardware.

The exact UUID is no longer required for dynamic matching, but this does not guarantee compatibility with every Sequoia update.

Other cache versions must still pass complete function-content, reference-target, and ABI validation.

Changes to driver implementations or ABI layouts can cause patches to be rejected.

3. Expanded Sequoia VCN Hardware Acceleration

Pre-release.9 ports additional video-driver corrections from Tahoe to Sequoia.

The new Sequoia implementation includes:

• Video surface pitch corrections.
• Eight swizzle-related corrections.
• 48-byte VCN encoder feedback stride handling.
• Dynamic userspace video-driver patch resolution.
• Device-specific VCN 2.2 capability identification.

These changes extend the H.264/HEVC hardware acceleration infrastructure previously developed and tested under Tahoe.

The experimental VCN 2.2 device range remains:

1002:15E7
1002:1636
1002:1638
1002:164C

VCN 1.x devices, including 1002:15D8 and 1002:15DD, remain unsupported.

Hardware validation

The Sequoia implementation has now undergone real-hardware testing on macOS 15.8.1 (24H32).

Previously, H.264 and HEVC hardware encoding and decoding were successfully tested through VideoToolbox on a Ryzen 7 5800H / 1002:1638 running macOS Tahoe 26.7.1.

The new Sequoia testing establishes real-device validation for the port on the tested configuration, rather than relying only on simulated regression tests.

However, compatibility across all supported APUs, codecs, applications, and long-duration workloads has not been established.

Further H.264/HEVC testing and feedback from other configurations are welcome.

4. Improved Sequoia SubmitGuard

SubmitGuard can now dynamically locate the Sequoia command-submission method.

Before installing the guard, the implementation validates the complete native function and its relative references.

Existing safety checks remain in place for:

• Original function entry validation.
• Previously installed guard detection.
• Trampoline and return-address verification.
• Memory-protection restoration.
• Installation failure and rollback handling.

This avoids relying solely on a fixed command-submission offset.

SubmitGuard remains included in -NRedDisplayFix.

5. FairPlay Client Compatibility

The FairPlay compatibility policy remains enabled for eligible clients when -NRedVideoFix is used.

Pre-release.9 expands the Sequoia AMD decoder compatibility subset from 13 to 18 patches.

macOS	AMD decoder patches
Sonoma 14	13
Sequoia 15	18
Tahoe 26	18

FairPlay clients are identified using the com.apple.private.fpsd.client entitlement rather than process names.

Native AppleGVA and video-encoder behavior is preserved for these clients.

DRM remains unresolved

This release does not fix FairPlay-protected video playback.

Previous Cezanne testing showed normal Apple Music playback, while protected music videos produced audio and advancing playback progress but displayed a black video area.

The FairPlay firmware certificate request failure remains unresolved.

The Sequoia compatibility improvements do not constitute a DRM bypass or a confirmed protected-video playback fix.

6. Current macOS Compatibility

Feature	Sonoma 14	Sequoia 15	Tahoe 26
LegacyBlend	Experimental	Tested on 15.8.1	Previously tested
Shared SRD	Not ported	Tested on 15.8.1	Previously tested
ComputeScratch	Not ported	Tested on 15.8.1	Previously tested
SubmitGuard	Reference profile	Dynamic matching	Existing implementation
VCN 2.2	Experimental	Expanded, hardware-tested configuration	Previously tested on Cezanne
Dynamic userspace matching	No	Yes	Yes

Sonoma 14 retains its verified reference-cache restrictions.

Sequoia 15 and Tahoe 26 use their respective dynamic matching implementations, subject to full compatibility validation.

Sequoia 15.8.1 (24H32) has been validated on real hardware. Other Sequoia builds and APU combinations may require additional validation.

No new GPU families or discrete GPU support have been added.

7. Boot Arguments

The boot arguments remain unchanged from pre-release.8.

Display and rendering fixes:

-NRedDisplayFix

Experimental VCN hardware acceleration:

-NRedVideoFix

Enable both rendering and video fixes:

-NRedDisplayFix -NRedVideoFix

Optional EC backlight control:

NRedECFix=1

Do not enable NRedECFix=1 if your laptop's native brightness adjustment already works correctly.

Older experimental arguments such as -NRedComputeScratch, -NRedVCN, and NRedECBacklight=1 are no longer supported.

8. Validation

The Sequoia changes have passed:

• Real-hardware validation on macOS Sequoia 15.8.1 (24H32).
• 25 regression test groups.
• Debug, Research Release, and Release builds.
• Static analysis across all three configurations.
• Final kext packaging checks.
• Sequoia-specific patch-data generation.
• Full-function dynamic resolver tests.
• Shared SRD and ComputeScratch regression tests.
• Video pitch, swizzle, and encoder feedback tests.
• SubmitGuard matching and safety checks.
• Memory-protection, rollback, and compatibility rejection tests.

The new patch data is generated from verified Sequoia reference functions.

Together with the completed real-hardware testing, these results provide validation for the tested Sequoia 15.8.1 configuration.

This does not imply complete compatibility with every Sequoia build, AMD APU, or application workload.

9. Known Limitations and Feedback

This remains an experimental pre-release.

• Sequoia 15.8.1 has been tested on real hardware; other builds may require additional validation.
• Dynamic cache matching cannot support arbitrary dri...

NootedRed 0.9.0 Pre-release.8

NootedRed 0.9.0 Pre-release.8

Experimental pre-release — Stability Hotfix

This is an unofficial development fork of NootedRed. This update focuses on improving startup stability and userspace patch safety.

Pre-release.8 builds on pre-release.7 and addresses two issues affecting the display and video patching infrastructure:

• Excessive kernel stack usage when display and video hooks are enabled together.
• Incomplete error handling when restoring maximum memory-page protections.

No new hardware capabilities or boot arguments are introduced in this release.

Source commit:

7a81e78

Changes since pre-release.7:

v0.9.0-pre-release.7...7a81e78

1. Fixed Excessive Kernel Stack Usage

When -NRedDisplayFix and -NRedVideoFix are enabled together, both modules hook the same macOS shared-region initialization function.

Previously, large temporary patch buffers could remain allocated on the kernel stack while the original hook chain was executing.

This could significantly increase stack usage and potentially contribute to early boot failures.

The updated implementation:

• Separates the original hook call from the actual patch-processing routine.
• Moves large display-patching workspaces from the kernel stack to per-call heap allocations.
• Adds allocation-failure handling and automatic cleanup.
• Preserves the original native return values and patch validation behavior.
• Adds bounded diagnostic tracing for the first eight calls per module.

The previous Release binary contained local stack reservations of approximately 6,040 bytes and 1,640 bytes in the two shared-region wrappers.

In the tested candidate, each entry wrapper uses approximately 24 bytes of local stack space, excluding saved registers and called functions.

Hardware testing

A contributor reported that enabling both display and video fixes caused early boot failures on a ThinkBook 14p Gen2-ACH with a Ryzen 7 5800H, running macOS Tahoe 26.7.1.

Either feature worked individually, but enabling both could prevent the system from reaching the desktop.

The contributor confirmed that a tested build containing the stack-usage changes could boot and operate with both features enabled.

This is a positive hardware result for the tested candidate, not a guarantee that all early boot failures are resolved.

Special thanks to Kingtous for investigating this issue, contributing the fix, and providing testing results.

Related pull request:

#4

2. Improved Memory Protection Restoration

This release also fixes an error-handling issue in the shared userspace patching infrastructure.

Previously, restoring a page's current protection could succeed while restoring its maximum protection failed.

The operation could still be treated as successful, leaving the maximum protection restoration incomplete.

The updated implementation now:

• Treats maximum-protection restoration failures as actual failures.
• Tracks pages that still require maximum-protection restoration.
• Supports retrying incomplete protection restoration.
• Preserves the distinction between writable pages and pages awaiting maximum-protection restoration.
• Prevents a failed protection transaction from being reported as a successfully applied patch.

Additional regression tests cover protection failures, retries, rollback preparation, and multi-page recovery scenarios.

These changes improve patch transaction safety for both Metal rendering and VCN userspace patches.

3. Existing Features

The functionality introduced in earlier releases remains available:

• Rendering: LegacyBlend, Shared SRD, ComputeScratch, and SubmitGuard fixes where supported.
• Video: Experimental VCN 2.2 H.264/HEVC hardware decoding and encoding.
• macOS: Experimental compatibility paths for Sonoma 14, Sequoia 15, and Tahoe 26.
• Backlight: Optional firmware-based EC brightness control.
• FairPlay: Experimental client and PSP compatibility adjustments.

The latest rendering implementation continues to preserve native deferred synchronization.

FairPlay-protected video playback and complete DRM support remain unresolved.

4. Boot Arguments

The boot arguments remain unchanged.

For display and video fixes:

-NRedDisplayFix -NRedVideoFix

For optional EC backlight control:

NRedECFix=1

Do not enable EC backlight control if your laptop's native brightness adjustment already works correctly.

The older experimental arguments, including -NRedComputeScratch, -NRedVCN, and NRedECBacklight=1, are no longer supported.

5. Testing and Known Limitations

The shared-region hook changes passed regression tests covering hook chaining, native return values, bounded tracing, allocation failures, and rollback behavior.

The memory-protection update adds regression coverage for maximum-protection failures and recovery.

The contributor's tested stack-fix candidate also passed Debug, Research Release, and Release builds and static analysis.

However, the final combined pre-release.8 source has not yet been independently confirmed through real-hardware acceptance testing.

Please report any remaining startup failures, GPU resets, rendering corruption, or hardware acceleration issues.

Keep a backup of your working EFI and NootedRed.kext before testing.

Acknowledgements

Special thanks to Kingtous for contributing the shared-region stack usage fix and testing the combined display/video configuration.

Thanks also to weachy/NootedRed for their multi-macOS compatibility research, the original ChefKissInc/NootedRed developers, and everyone providing feedback and testing results.

---

This is an experimental stability update. It does not introduce new hardware support or claim that all boot, rendering, or DRM issues have been resolved.

NootedRed 0.9.0 Pre-release.7

NootedRed 0.9.0 Pre-release.7

Experimental pre-release

This is an unofficial development fork of NootedRed. The latest changes have passed automated validation, but real-hardware acceptance testing is still pending.

This update builds on pre-release.6, focusing on FairPlay client compatibility, native Metal synchronization, and safer userspace patch infrastructure.

The main changes include:

• A unified FairPlay client policy across macOS Sonoma, Sequoia, and Tahoe.
• Experimental AMD video-decoder and PSP compatibility adjustments for protected-media clients.
• Preservation of native AppleGVA and video-encoder behavior in FairPlay clients.
• Restoration of native deferred synchronization on Tahoe.
• Shared memory-protection and rollback helpers for Metal and VCN userspace patches.
• Faster legacy-cache validation without weakening existing safety checks.

Latest source commit:

27e75c8

Changes since pre-release.6:

v0.9.0-pre-release.6...27e75c8

1. Unified FairPlay Client Compatibility

This release introduces a unified compatibility policy for FairPlay-related processes on:

• macOS Sonoma 14 / Darwin 23
• macOS Sequoia 15 / Darwin 24
• macOS Tahoe 26 / Darwin 25

Previously, FairPlay-related handling differed between macOS versions and some experimental paths depended on individual process names or separate configuration.

The new implementation identifies FairPlay clients through their actual entitlement:

com.apple.private.fpsd.client

This means the policy is no longer limited to processes named Music or TV.

Any supported process holding this entitlement can enter the same compatibility path when -NRedVideoFix is enabled.

Processes without the entitlement do not receive the FairPlay-specific policy simply because their names match a known application.

Selective AMD decoder patching

Instead of applying the complete experimental video patch set to FairPlay clients, the new implementation selects only the required AMD driver-side decoding patches.

The AppleGVA and video-encoder code remains native.

The patch selection depends on the macOS version:

macOS	AMD decoder patches	Patch mask
Sonoma 14	13	0x1FFF
Sequoia 15	13	0x1FFF
Tahoe 26	18	0x7F87FE

This allows the AMD decoder compatibility work to be evaluated without unnecessarily modifying other parts of the protected-media pipeline.

Each selected patch must pass the existing cache, code-content, and memory-protection checks.

2. PSP Content Protection Factory Compatibility

Pre-release.7 also extends the native content-protection factory compatibility logic for the supported AMD APU path.

The relevant factory is:

VACPFactory::createCP

The native implementation originally accepts PSP family values from 1 through 4.

The compatibility patch extends that range to include PSP family 5, which is used by the experimental APU identification path.

The change is deliberately minimal:

Original: PSP family 1–4
Patched:  PSP family 1–5

Existing behavior for other family values remains unchanged.

The implementation preserves:

• The original SAMU path for family 0.
• Native object initialization and cleanup behavior.
• Native error propagation.
• Existing kernel-extension error handling.
• Unrelated content-protection operations.

For Sonoma and Sequoia, the original factory functions are validated against complete reference-function data before changing the relevant comparison.

Important: DRM is not fixed

This change does not mean FairPlay DRM is working.

It only extends a specific driver compatibility condition and preserves the surrounding native implementation.

On the previously tested Ryzen 7 5800H / Cezanne system running macOS 26.7.1:

• Normal Apple Music playback worked.
• FairPlay-protected music videos produced continuous audio.
• Playback progress advanced normally.
• The protected video area remained black.

Further investigation identified a failure in the FairPlay firmware certificate request path.

The tested firmware/PSP configuration still does not successfully complete that certificate request.

Pre-release.7 does not implement missing firmware certificates, bypass FairPlay authentication, or provide a complete protected-video decoder.

Whether the new unified policy improves application behavior must be established through new hardware tests.

3. Native Metal Synchronization Restored

This release changes the Tahoe rendering-fix strategy.

Previous experimental builds included an ImmediateSync modification intended to address rendering corruption and synchronization problems.

Further refinement has now separated the required rendering and resource-layout corrections from the synchronization behavior itself.

Pre-release.7 preserves the original driver's deferred synchronization behavior instead of forcing the earlier ImmediateSync modification.

The Tahoe display-fix path continues to include:

• Shared SRD handling.
• LegacyBlend corrections.
• ComputeScratch allocation corrections.
• SubmitGuard command-buffer protection.

The Shared SRD patch still addresses the relevant allocation and resource-layout behavior, but now preserves native synchronization semantics.

This reduces unnecessary interference with Apple's original Metal command scheduling and synchronization logic.

The current configuration is identified by:

NRedDisplayFixVersion = 2
NRedImmediateSyncDisabled = 1

Existing diagnostic properties may still contain the NRedImmediateSync prefix for historical reasons. Their presence does not mean ImmediateSync is enabled.

This change has passed regression testing, but real-hardware rendering and stability validation is still required.

4. Shared Userspace Patch Infrastructure

The Metal and VCN userspace patching paths now share common memory-management helpers.

The shared implementation covers:

• Memory-region queries.
• Patch-page collection and deduplication.
• Copy-on-write page preparation.
• Writable-page transitions.
• Original protection restoration.
• Rollback preparation after partial failures.

The implementation preserves each module's existing patch order, validation rules, diagnostics, and failure handling.

This reduces duplicated code while keeping the same safety requirements.

Executable memory pages are still restored to their original protection after successful patching.

If a required operation fails, the corresponding transaction follows the established rejection or rollback path.

5. Faster Legacy Cache Validation

Sonoma and Sequoia userspace patches continue to require verified reference-cache layouts.

Pre-release.7 improves the validation process by comparing unchanged portions of reference pages in larger blocks.

Only differing bytes require additional checks against the known patch ranges.

The validation still enforces:

• The expected dyld shared-cache UUID.
• Complete reference-page verification.
• Exact original or approved patched bytes.
• Rejection of unexpected modifications.
• Support for detecting already-applied patches.
• Memory-boundary and page-protection checks.

This is a validation optimization, not a relaxation of compatibility requirements.

Unknown or incompatible Sonoma and Sequoia cache layouts remain unsupported.

6. macOS Compatibility

The multi-OS support introduced in pre-release.6 remains available.

macOS	Display fixes	Experimental VCN	FairPlay compatibility policy
Sonoma 14	LegacyBlend + SubmitGuard	Version-specific bridge	13-patch AMD subset + PSP compatibility
Sequoia 15	LegacyBlend + SubmitGuard	Version-specific bridge	13-patch AMD subset + PSP compatibility
Tahoe 26	Shared SRD + LegacyBlend + ComputeScratch + SubmitGuard	Existing Tahoe bridge	18-patch AMD subset + PSP compatibility

ImmediateSync is disabled across these display-fix profiles.

For Sonoma and Sequoia, the verified reference configurations remain:

Version	Build	Reference cache UUID
Sonoma 14.8.9	23J631	4C1441FD-8A54-3DC2-863D-49110B946A25
Sequoia 15.8.1	24H32	42EC2890-BC40-317E-BB27-45142BFF7F26

Support for Darwin 23/24/25 does not guarantee compatibility with every minor macOS update.

The VCN 2.2 device range remains:

1002:15E7
1002:1636
1002:1638
1002:164C

VCN 1.x devices remain unsupported.

7. Boot Arguments

The unified boot arguments from pre-release.6 remain unchanged.

For rendering fixes:

-NRedDisplayFix

For experimental VCN hardware acceleration and the associated FairPlay compatibility policy:

-NRedVideoFix

For optional EC backlight control:

NRedECFix=1

A typical rendering and video configuration is:

-NRedDisplayFix -NRedVideoFix

If your laptop also requires EC brightness control:

-NRedDisplayFix -NRedVideoFix NRedECFix=1

If native brightness adjustment already works normally, do not enable NRedECFix=1.

The EC backlight workaround is intended only for affected laptops.

No separate FairPlay or DRM boot argument is required. The compatibility policy is automatically selected for eligible FairPlay clients when -NRedVideoFix is enabled.

Previous experimental arguments such as -NRedVCN, -NRedComputeScratch, and NRedECBacklight=1 are no longer supported.

8. Validation

The latest changes have passed:

• Debug build.
• Research Release build.
• Release build.
  ...

NootedRed 0.9.0 Pre-release.6

NootedRed 0.9.0 Pre-release.6

Experimental pre-release

This is an unofficial development fork of NootedRed. The new multi-OS compatibility paths are experimental and have not yet completed real-hardware validation.

This release builds on pre-release.5 and expands the experimental rendering and VCN compatibility paths beyond macOS Tahoe.

The main focus is macOS Sonoma 14, Sequoia 15, and Tahoe 26 compatibility, with version-specific driver validation, safer patching, and simplified boot arguments.

Special thanks to weachy/NootedRed for the multi-OS compatibility research and reference patch data that helped make this update possible.

Source commit:

128b980

Changes since pre-release.5:

v0.9.0-pre-release.5...128b980

1. Expanded macOS Compatibility

Previous releases primarily focused on macOS Tahoe.

Pre-release.6 introduces separate compatibility profiles for:

macOS	Darwin	Current status
Sonoma 14	23.x	Experimental, verified reference cache required
Sequoia 15	24.x	Experimental, verified reference cache required
Tahoe 26	25.x	Existing compatibility path retained

The new implementation selects the appropriate patch data, kernel ABI checks, and driver call sites according to the running macOS version.

This avoids applying Tahoe-specific offsets or driver assumptions to older macOS versions.

Important compatibility restrictions

Sonoma and Sequoia currently have verified reference profiles for:

Version	Build	Reference cache UUID
macOS 14.8.9	23J631	4C1441FD-8A54-3DC2-863D-49110B946A25
macOS 15.8.1	24H32	42EC2890-BC40-317E-BB27-45142BFF7F26

Other Sonoma and Sequoia builds are not automatically supported.

The patching system verifies the cache UUID, complete expected code pages, driver ABI, and required call sites before applying changes.

If verification fails, the corresponding patch is rejected.

Tahoe retains its existing reference-cache fast path and compatible dynamic userspace cache resolution.

This compatibility expansion does not guarantee that every Sonoma, Sequoia, or Tahoe update will work.

2. Unified Boot Arguments

Pre-release.6 introduces a new set of public boot arguments. Previous experimental fix arguments are no longer recognized.

The new options are:

Boot argument	Function
-NRedDisplayFix	Rendering, blending, and command submission fixes
-NRedVideoFix	Experimental VCN hardware video acceleration
NRedECFix=1	Optional firmware-based EC brightness control

All three features can be enabled independently.

For example, to enable display and video fixes:

-NRedDisplayFix -NRedVideoFix

For all three features:

-NRedDisplayFix -NRedVideoFix NRedECFix=1

Removed boot arguments

The following previous experimental arguments are no longer supported:

-NRedImmediateSync
-NRedSrdShared
-NRedLegacyBlend
-NRedComputeScratch
-NRedTransfer1x1
-NRedVCN
-NRedNoSubmitGuard
-NRedHDRIntegerFilter
NRedECBacklight=1
NRedECBacklight=2

Please remove these arguments from your OpenCore configuration and replace them with the new options where appropriate.

Other upstream or global NootedRed settings are not affected by this renaming.

3. Rendering and Metal Fixes

The new -NRedDisplayFix option provides a unified entry point for the available rendering fixes.

The enabled components depend on the macOS version.

Sonoma 14 / Sequoia 15

The experimental display path includes:

• LegacyBlend / dual-source blending corrections.
• SubmitGuard command-buffer protection.
• Version-specific code and cache validation.

The Tahoe-specific ImmediateSync, shared SRD, and ComputeScratch userspace patches are not enabled on these older systems.

Tahoe 26

The existing rendering corrections are retained:

• ImmediateSync.
• Shared SRD handling.
• LegacyBlend.
• ComputeScratch.
• SubmitGuard.

These fixes remain subject to device and userspace code validation.

Improved LegacyBlend handling

The Sonoma and Sequoia implementations now apply a more selective correction to the blending capability condition.

Rather than globally disabling dual-quad blending or overriding the complete native decision, the patch modifies the verified hardware capability gate while preserving the remaining native blending conditions.

This is intended to address rendering corruption in affected Metal workloads without unnecessarily disabling native optimizations.

The relevant code must pass complete page validation before the patch is applied.

4. SubmitGuard Improvements

The SubmitGuard implementation introduced in pre-release.5 has been adapted to the verified Sonoma and Sequoia reference profiles.

SubmitGuard addresses a command-buffer issue where unused buffer space may contain zero headers or stale commands left by recycled allocations.

The guard fills the safe unused tail with PM4 filler instructions:

0x80000000

The current implementation preserves the valid command region and avoids overwriting other command streams in the same batch.

Pre-release.6 also improves installation and rollback safety:

• Verification of the original method entry.
• Validation of an existing trampoline and its return target.
• Restoration of original code after partial installation failures.
• Safer executable-memory allocation cleanup.
• Protection against releasing memory still referenced by an installed jump.
• Correct restoration of current and maximum page protections.

The updated implementation reports:

NRedSubmitGuardRevision = 6

SubmitGuard is now controlled by -NRedDisplayFix.

It is no longer configured through a separate public boot argument.

These changes aim to improve rendering stability, but they do not guarantee that all GPU resets or application hangs are resolved.

5. Experimental VCN Support on Sonoma and Sequoia

The experimental VCN 2.2 bridge has been adapted to support separate Sonoma, Sequoia, and Tahoe compatibility profiles.

The new -NRedVideoFix argument enables this functionality.

The implementation selects version-specific:

• X5000 / X6000 kernel ABI validation data.
• Verified VCN method and getter layouts.
• Kernel patch locations and relative calls.
• Userspace video-driver patches.
• Device-specific video capability identification.

VCN initialization still requires successful compatibility checks before the bridge is installed.

The current VCN device matrix remains:

PCI ID	VCN generation	Status
1002:15D8	VCN 1.x	Unsupported
1002:15DD	VCN 1.x	Unsupported
1002:15E7	VCN 2.2	Experimental
1002:1636	VCN 2.2	Experimental
1002:1638	VCN 2.2	Experimental
1002:164C	VCN 2.2	Experimental

VCN 1.x remains unsupported.

The existing H.264 / HEVC hardware encoding and decoding work is retained on the Tahoe path.

The Sonoma and Sequoia implementations use their own verified patch data and do not blindly reuse Tahoe-specific video patches.

In particular, not all Tahoe-specific pitch and swizzle corrections are included in the older-system profiles where equivalent implementation evidence is unavailable.

Real-hardware video acceleration on the newly adapted Sonoma and Sequoia paths still requires validation.

6. Optional EC Backlight

The EC brightness-control implementation from pre-release.5 remains available, but its boot argument has changed.

The new option is:

NRedECFix=1

For systems that specifically need to request a firmware switch to EC control, the experimental force mode remains:

NRedECFix=2

The latter should only be used when necessary and does not guarantee that the firmware has actually switched control sources.

When should you enable EC backlight?

If your laptop's original brightness adjustment works normally, do not enable NRedECFix=1.

EC backlight is intended for affected laptops where the macOS brightness slider moves but the physical panel brightness does not change.

For example, on the Lenovo Legion R7000P 2021H, the native AMD backlight path was observed to stop affecting physical brightness after startup.

The laptop also exposes a firmware WMI/EC brightness interface, which has been confirmed to change physical brightness successfully.

The EC implementation routes brightness requests to that firmware interface through a separate workloop instead of mixing EC operations with AMD display callbacks.

The underlying EC implementation remains experimental, and compatibility with other laptops is not guaranteed.

7. FairPlay and DRM

The FairPlay compatibility improvements introduced in pre-release.5 are retained.

Processes identified as protected FairPlay clients continue to use native Apple video-driver behavior instead of receiving the experimental VCN userspace patches.

This previously restored online Apple Music playback on the tested Ryzen 7 5800H system.

However, FairPlay-protected video playback and complete DRM support are not claimed.

This update does not introduce a DRM bypass or a complete protected-video decoding implementation.

8. Validation

The latest source changes passed:

• Debug build.
• Research Release build.
• Release build.
• Static analysis for all three configurations.
• 16 regression checks covering the compatibility changes.
• Reproducible patch-data generation checks.
• Final kext pack...