# WhateverGreen: the Lilu plugin that makes unsupported GPUs behave on macOS > WhateverGreen is a kernel extension that patches graphics drivers on Apple hardware, and it depends on Lilu rather than shipping on its own. The feature list is long, the configuration is boot arguments, and the documentation is a folder of FAQs rather than a tutorial. **acidanthera/WhateverGreen** — Various patches necessary for certain ATI/AMD/Intel/Nvidia GPUs - Repository: https://github.com/acidanthera/WhateverGreen - Stars: 3,387 · Forks: 652 - Language: C++ - License: BSD-3-Clause - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/acidanthera-whatevergreen ## A Lilu plugin, which means it is not a standalone driver patch The first line of the README sets the ground rules: WhateverGreen is a Lilu plugin providing patches to select GPUs on macOS, and it requires Lilu 1.5.6 or newer. That dependency is the single most important fact about the project, and it changes what installing it involves. Lilu is the patching framework that loads kexts into the kernel and gives them a place to hook; WhateverGreen is a payload that runs inside it. A machine with WhateverGreen and no Lilu, or an old Lilu, does not get partial functionality. It gets nothing. That architecture explains the shape of the repository. There is `WhateverGreen/` for the code and `WhateverGreen.xcodeproj/` for the build, `Resources/` for data compiled into the binary, and `Manual/` for documentation. Two more directories are unusual and worth naming: `Prebuilt/`, which is where release binaries live so users do not need Xcode to install the thing, and `ResourceConverter/`, which is the tooling that turns resources into a compiled form. `Tools/` sits alongside them. `Changelog.md` and `LICENSE.txt` at the root complete a project that is, in build terms, one C++ target plus its data. The language is C++ and the licence is BSD-3-Clause, which is a low-friction licence for something people redistribute in built kext form. The repository has 2 open issues at 3,383 stars, and the last recorded push to `master` was on 2026-08-12. ## The feature list reads as a bug tracker for a decade of GPU problems There are more than thirty items under Features in the README, and they are not features in the marketing sense. Read as a list, they are a chronology of specific failures: fixes boot to black screen on AMD and NVIDIA, fixes sleep wake to black screen on AMD, fixes boot screen distortion in certain cases, fixes black screen on Intel HD since 10.15.5, fixes choppy video playback on Intel Kaby Lake and newer. Some entries are more revealing than others. There is a fix for the kernel panic caused by an invalid link rate reported by DPCD on some laptops with Intel integrated graphics, and another for a panic caused by an incorrectly calculated amount of DVMT pre-allocated memory on Ice Lake platforms. A panic fix tells you the maintainer has hardware to reproduce panics on, which is not a complaint anyone makes about a graphics kext. The Apple-specific entries show how much of this is really about defeating Apple's own compatibility checks. One patches `AppleGraphicsDevicePolicy.kext` so a Mac Pro board-id and model combination can be used without the usual hang, by disabling the board check with the `agdpmod=ignore` boot argument. Another modifies macOS so that NVIDIA's web drivers count as platform binaries, which fixes transparent empty windows in Metal applications such as iBooks and Little Snitch Network Monitor when Library Validation is on. That second one is a good example of the project's real subject: not making a GPU faster, but removing an obstacle Apple put in its way. The Intel list runs the longest because integrated graphics is where the failures are most varied: backlight registers, PWM backlight control on machines wired directly to an AMD Radeon RX 5000 card, DVMT memory allocation, LSPCON chips for DisplayPort to HDMI 2.0, an infinite loop on HDMI connections at higher pixel clocks on Skylake, Kaby Lake and Coffee Lake. ## Configuration is boot arguments and device properties, not a config file There is no configuration file. The README's documentation for configuration is a set of tables, one per vendor, mapping a boot argument in the left column to an optional device property in the middle and an effect in the right. That is unusual enough to be worth stating plainly: you configure this by editing the bootloader. The global table is the smallest and the most useful starting point. `-wegbeta` enables the kext on macOS versions it does not officially target, and the description says versions 26 and below are enabled by default, so most people will not need it. `-wegdbg` turns on debug printing in DEBUG builds. `-wegoff` disables WhateverGreen entirely, which is the argument you reach for when a suspected problem turns out to be here. ```text +| `-wegbeta` | N/A | Enable WhateverGreen on unsupported macOS versions (26 and below are enabled by default) | | `-wegoff` | N/A | Disable WhateverGreen | ``` The GPU-switching table is the part most relevant to anyone running an iGPU plus a discrete card, since it covers disabling external GPUs with `-wegnoegpu`, disabling the internal GPU with `-wegnoigpu`, and the automatic case with `-wegswitchgpu`, which disables the internal GPU when an external one is installed. Each pairs a boot argument with a device property applied to a specific GFX node, which is why the tables have three columns. This is also the project's hard edge. Every flag here is a promise about behaviour the README describes, and most are described conditionally: enable DVI transmitter correction is marked as required for 290X, 370 and similar parts, and `radpg=15` is marked as required for Cape Verde GPUs including the HD 7730, 7750, 7770, R7 250 and R7 250X. The README does not tell you how to find out whether your card is in that list. ## Three vendor tables that share nothing, which is the point The AMD, Nvidia and Intel tables are effectively three separate projects sharing a build. An AMD user reads about `aty_config`, board-id spoofing and `AMDRadeonVADriver` and finds nothing about Metal; an Nvidia user reads about `NVDAStartupWeb` and the gfx-submit fix and finds nothing about backlight registers. The AMD table offers the most aggressive spoofing. `agdpmod=pikera` replaces `board-id` with `board-ix`, and `agdpmod=vit9696` disables the board-id check outright, while `agdpmod=ignore` disables the AGDP patches themselves with the `vit9696,pikera` value implied for external GPUs. There are also flags for forcing 24-bit output on unsupported displays with `-rad24`, disabling ATI or AMD acceleration entirely with `-radvesa`, and allowing non-supported cards to use the hardware video encoder with `-radcodec`. ```text +| `-raddvi` | N/A | Enable DVI transmitter correction (required for 290X, 370, etc.) | | `radpg=15` | N/A | Disable several power-gating modes | ``` The Nvidia table is short and mostly about turning features off. `ngfxgl=1` disables Metal support, `ngfxcompat=1` ignores the compatibility check in `NVDAStartupWeb` via the `force-compat` property, `ngfxsubmit=0` disables the interface stuttering fix, and `-ngfxdbg` turns on NVIDIA driver error logging. ```text +| `ngfxgl=1` | `disable-metal` | Disable Metal support on NVIDIA | | `ngfxsubmit=0` | `disable-gfx-submit` | Disable interface stuttering fix on 10.13 | ``` The Intel table is the one where most users end up, because integrated graphics is the common case on a Hackintosh: ```text +| `-igfxblr` | `enable-backlight-registers-fix` property on IGPU | Fix backlight registers on KBL, CFL and ICL platforms | | `-igfxcdc` | `enable-cdclk-frequency-fix` property on IGPU | Support all valid Core Display Clock (CDCLK) frequencies on ICL platforms | ``` `-igfxblr` targets the backlight registers on Kaby Lake, Coffee Lake and Ice Lake. `-igfxblt` is documented as an alternative to it, added for platforms on macOS 13.4 or later, and the README links straight to the FAQ entry about the three-minute black screen on CFL. `-igfxbls` enables a backlight smoother that applies to Ivy Bridge and newer and links to its own FAQ section. The pattern is consistent: the flag table tells you the name, the manual explains the condition. ## The Manual directory is the documentation, and the README says so bluntly The Documentation section is two sentences: read the FAQs in `./Manual/` and avoid asking any questions, because no support is provided for the time being. The links scattered through the boot argument tables confirm it, pointing at `./Manual/FAQ.Radeon.en.md` and `./Manual/FAQ.IntelHD.en.md` with anchors as specific as the three-minute black screen issue on CFL platforms running macOS 13.4 or later. So the real documentation is a set of per-vendor FAQ markdown files, and the README is an index into them. That is a deliberate choice for a project whose questions are almost entirely of the form my specific card does this specific thing. A feature list cannot answer that, and a forum thread usually cannot either. A file that says here are the conditions under which `-igfxblt` is the flag you want, rather than `-igfxblr`, is a better answer than either. The maintenance question has a clear answer here too. The release history is three entries: version 1.6.8 in October 2024, fixed loading on macOS 10.10 and older because of a MacKernelSDK regression, version 1.6.9 in December 2024, which added Alder Lake, Raptor Lake and Arrow Lake CPU detection, and version 1.7.0 in July 2025, which added constants for macOS 26 support. The last recorded push was on 2026-08-12. Two build signals are worth noting for anyone deciding how much to trust a kext. The README carries a GitHub Actions build badge for the `master` branch and a Coverity Scan badge, so the project is built in CI and statically analysed. The 1.6.8 fix is itself a good sign: a regression caused by a change in Apple's SDK was found and corrected rather than left until someone reported a failure. ## What this project is not, and when to leave it alone The comparison worth making is not against another kext, because there is no real substitute for the specific patches in this list. It is between installing it and not installing it on a given machine. On a Mac Apple shipped support for, WhateverGreen has nothing to add, and adding it means adding a Lilu dependency, a boot argument set, and a kext loaded early in boot for no benefit. Against the alternative of native support, the honest framing is that macOS is closed, so unsupported hardware cannot be fixed by contributing a driver upstream. WhateverGreen exists because the alternative is a black screen. That is a real and legitimate project, but it also means the thing you are installing is a workaround for a platform decision rather than a missing open source component. Against leaving the machine broken, the cost calculus changes. Every flag you add is a claim about hardware behaviour that you are verifying by observation rather than by test. The README's own structure admits this: many descriptions end in a caveat about which cards need the flag, and several flags exist to disable a fix that made things worse on a specific machine. There is a related project in the same ecosystem worth naming, because the related searches surface it constantly: AppleALC, another Lilu plugin, handles audio rather than graphics. If you are assembling a Hackintosh you will encounter both, and the pattern is the same for each: the project provides the mechanism and the `Manual/` files provide the judgement. WhateverGreen makes the mechanism unusually well documented and unusually opinionated, and asks you to supply the hardware knowledge. ## Conclusion WhateverGreen is worth installing if macOS is running on hardware Apple never shipped support for, and worth ignoring entirely on a supported Mac, where it has nothing to patch and one more kext to trust. The project's own position is unusually clear about this. Configuration lives in boot arguments and device properties, the README says no support is provided for the time being, and the `Manual/` directory is where the real answers are rather than the README. Start by identifying which of the three vendor branches applies to your machine, because the AMD, Nvidia and Intel tables share no flags, then read the matching FAQ file under `Manual/` before changing anything. Lilu 1.5.6 or newer is the prerequisite, and version 1.7.0 is the release that added macOS 26 constants. ## FAQ ### What is the WhateverGreen kext and what does it do? It is a Lilu kernel extension that patches graphics drivers on macOS for hardware Apple did not ship support for. The README lists more than thirty specific fixes, including boot to black screen on AMD and Nvidia, sleep wake failures on AMD, Intel backlight register problems and DVMT memory panics on Ice Lake. It requires Lilu 1.5.6 or newer. ### How do I configure WhateverGreen? Through boot arguments and device properties, not a config file. The README documents a global set including `-wegoff` to disable the kext and `-wegbeta` to enable it on unsupported macOS versions, plus separate tables for AMD, Nvidia and Intel graphics. Each argument can be paired with a device property applied to a specific GPU node, which is why the tables have three columns. ### What is the latest WhateverGreen version and what did it add? Version 1.7.0, published in July 2025, added constants for macOS 26 support. Before that, 1.6.9 in December 2024 added Alder Lake, Raptor Lake and Arrow Lake CPU detection, and 1.6.8 in October 2024 fixed loading on macOS 10.10 and older after a MacKernelSDK regression. ### Do I need WhateverGreen on a Mac that Apple supports? The patches target GPUs Apple never shipped support for, so on supported hardware there is nothing to patch. The README says macOS versions 26 and below are enabled by default, which means it loads without a boot argument, but that is a default rather than a recommendation. The project also states that no support is provided, so the questions a supported machine raises are not ones the maintainer is answering. ## Sources - [acidanthera/WhateverGreen on GitHub](https://github.com/acidanthera/WhateverGreen) - [Issues](https://github.com/acidanthera/WhateverGreen/issues) - [License: BSD-3-Clause](https://github.com/acidanthera/WhateverGreen/blob/master/LICENSE) - [README](https://github.com/acidanthera/WhateverGreen/blob/master/README.md) - [Releases](https://github.com/acidanthera/WhateverGreen/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/acidanthera-whatevergreen