[Bug] Muxless Tiger Lake laptop, panel on the Intel GPU: NVRMFBClaim holds the IOFramebuffer category on the IGPU, so no framebuffer is ever published and there is no desktop

Start by reading kexts/NVRMFB/fb/nvrm-fb.cpp around lines 270–285, where NVRMFBClaim matches display class devices, and inspect the reported connector detection path. Compare its behavior on a GPU with no connectors to the -nvoff boot, where IONDRVFramebuffer publishes. Done means the built-in Intel panel retains a framebuffer while the NVIDIA driver cannot drive any displays; verify the driver’s active boot logs and display tracker.

Send logs report ID

NM-WDYNE75T, NM-6FFHS8AN, NM-4XM6GS3C, NM-3AFMMP9E, NM-K2JN0CQ0, NM-MYM8NG54, NM-G9EXMBBB, NM-G9EXMBBB, NM-SNKXYCSW, NM-885TFGWF, NM-469AVK5H, NM-AXZXP5Z9, NM-FWB9G3ES, NM-R8MTCYRB, NM-740NS3E0, NM-1EBP436X

Where does it go wrong?

Booting macOS after the driver (black / grey screen, restarts)

What happens

No GUI at all: the built-in panel runs on an Intel GPU macOS has no driver for, and NVRMFBClaim keeps IONDRVFramebuffer from attaching to it

Hardware

• Dell Inspiron 16 7610, i7-11800H (Tiger Lake-H)
• Intel UHD [8086:9A60] + GeForce RTX 3050 Mobile [10DE:25A2] (GA107M, PCI class 03:02, no display connectors — the mobile vBIOS has none)
• No MUX switch. The internal eDP panel is wired to the Intel GPU; HDMI is wired to the Intel GPU too. There is no port physically wired to the NVIDIA card that I can see.

Software

• macOS 26.7.1 (25G241), OpenCore (rEFInd → EFI/OC/OpenCore.efi), SMBIOS MacBookPro16,2
• 1401 Mac 1.13.0 with driver package 1.13.0; kexts/26 installed, /Library/NullMoth/os-major = 26
• SIP 0x0A43, SecureBootModel Disabled, Lilu + AMFIPass + WhateverGreen present, no disable-gpu, no AAPL,ig-platform-id
• boot-args (exactly what setup wrote): nvfb=1 nvaccel=1 nvfbheads=4 -nvkmsnosmooth amfi_get_out_of_my_way=0x1 amfi=0x80 ipc_control_port_options=0

What I see

The driver loads and the machine boots, but there is no GUI anywhere: the screen shows the kernel's verbose console scrolling forever (not hung — no panic, no freeze, WindowServer keeps running) and the login window never appears. WindowServer is running on a virtual display:

WindowServer[971] [com.apple.CoreDisplay] [ERROR] - Setting offline display 0x41dc9d00 main in CGXVFBSelectOnlineState
    0 CoreDisplay::AddMainOfflineBreadcrumb(bool, char const*, ...)
    1 CGXVFBSelectOnlineState
    2 CGXDisplayDriverInitialize
    3 WS::Displays::CoreDisplayManager::initialize()
    4 WSInitialize

The driver's own display tracker agrees — no display, no head, ever:

-- current mode per framebuffer (fb: WxH? pclk/total = Hz) --
-- displays / heads (newest first) --

The whole difference is one boot argument

Same config.plist, only -nvoff present or absent:

	driver active	with -nvoff
NVRMFBClaim holds the IOFramebuffer match category on IGPU - IONDRVFramebuffer blocked	present	absent
(IOPCIFamily) child IONDRVFramebuffer(0x1000004e1) published	absent	present
desktop	none (CGXVFB)	works

Kernel log, driver active:

15:58:48.157 kernel: (NVRMFB) NVRMFB: NVRMFBClaim holds the IOFramebuffer match category on IGPU - IONDRVFramebuffer blocked
15:58:48.158 kernel: (NVRMFB) NVRMFB: NVRMFBClaim holds the IOFramebuffer match category on GFX0 - IONDRVFramebuffer blocked
15:58:58.194 kernel: (NVRM)   NVRM: GPU 0000:01:00.0: Successfully mapped framebuffer and registers
15:58:58.240 kernel: (NVRM)   NVRM-xnu: firmware loaded: 84310168 bytes          (gsp_ga10x.bin)
15:58:58.370 kernel: (NVAccel) NVAccel: MetalPluginName withheld -- nothing will load the Metal plugin
                               until `sysctl -w debug.nvaccelfb=1` puts it back
15:59:01.403 kernel: (NVRMFB) NVRM-fb: BAR1 metadata: 4096 MB at 0x7e00000000; normal surface budget 2048 MB
15:59:01.403 kernel: (NVRMFB) NVRM-fb: device: heads 0 connectors 0 pitchAlignment 1 hasVideoMemory 1 max 0x0
15:59:01.403 kernel: (NVRMFB) NVRM-fb: vtFb (NVKMS's view of the console fb): base 0x0 size 0
15:59:01.403 kernel: (NVRMFB) NVRM-fb: primary layer: formats 0x0 ... *** NOT SUPPORTED ***
15:59:01.403 kernel: (NVRMFB) NVRM-fb: getDisplays: none
15:59:01.403 kernel: (NVRMFB) NVRM-fb: kapiInit failed -- refusing to start. super::start() was NOT called,
                               so there is nothing half-registered to unwind and the machine stays up without a display
                               (all four nubs: index 0/1/2/3)
15:59:21.476 kernel: (NVAccel) NVAccel: registerFramebuffer(1): no framebuffer has published yet    (11 times, ~1/s)
15:59:32.182 kernel: (NVRM)   NVRM-xnu: auto-go: accelerator level 1 NEVER took after 11 tries — not arming further
15:59:32.238 kernel: (NVRM)   NVRM-xnu: auto-go: display stack: heads 0x0 accel 0 agdc -99 k5 -99 iop -99
15:59:32.267 kernel: (NVRM)   NVRM-xnu: boot hold RELEASED (display PARTIAL) — WindowServer's IOKitWaitQuiet may return

Kernel log, driver parked (-nvoff added — everything else identical):

16:24:52.846 kernel: (IOPCIFamily) [childPublished()] child IONDRVFramebuffer(0x1000004e1) published
16:24:52.854 kernel: (IOPCIFamily) [childPublished()] child IONDRVFramebuffer(0x1000004e9) published
16:24:54.000 kernel: (IONDRVSupport) GFX0: Not usable

Why

NVRMFBClaim (kexts/NVRMFB/fb/nvrm-fb.cpp:270-285) matches every display-class PCI device and holds the IOFramebuffer match category, which is higher scoring than IONDRVFramebuffer:

NVRMFBClaim:
  IOClass         = NVRMFBClaim
  IOProviderClass = IOPCIDevice
  IONameMatch     = display          # every display-class GPU, including the Intel IGPU
  IOMatchCategory = IOFramebuffer
  IOProbeScore    = 30000

bool start(IOService *provider) override
{
    // With the driver off, leave the slot to IONDRVFramebuffer so the firmware's display stays lit while the
    // removal runs. WAS: the claim held it anyway and the screen stayed dark until the second restart.
    if (nvrm_driver_off()) return false;      // only -nvoff / nullmoth-remove
    ...
}

On this machine that claim is pure harm. NVRMFB cannot start anyway (the NVIDIA card reports heads 0 connectors 0, so there is nothing to drive), but the claim still removes the only framebuffer the machine can have — the firmware framebuffer on the Intel GPU — and then:

• no IOFramebuffer exists anywhere → WindowServer creates/uses the virtual display (CGXVFB),
• NVAccel waits forever for a framebuffer (registerFramebuffer(1): no framebuffer has published yet),
• MetalPluginName stays withheld → not even the headless Metal device appears.

This also defeats the 1.12 change: setup no longer excludes com.apple.iokit.IONDRVSupport when the panel is on the Intel GPU (nullmoth-setup.sh:738-753, "panel-on-Intel keeps IONDRVSupport"), but the kext-level claim blocks IONDRVFramebuffer regardless. So the 1.12.0 release note — "On 11th generation and newer Intel (Tiger Lake, Alder Lake, Raptor Lake and later), macOS has no Intel driver: the built-in screen shows macOS without acceleration, and apps still get the NVIDIA GPU for Metal" — does not hold on this machine.

What I would ask for

1. Do not claim the IOFramebuffer category when this GPU has nothing to drive — i.e. when it reports 0 connectors / getDisplays: none. The claim exists so the firmware framebuffer cannot compete with NVRMFB; with nothing to drive it only removes the machine's only display.
2. Or: skip the claim on GPUs other than the one NVRM drives (here: skip the Intel IGPU whose panel macOS cannot drive).
3. Or, fastest for users: gate the claim behind a boot argument / sysctl (e.g. -nvrmfbnoigpu), so an affected machine can opt out without a rebuild.
4. And/or ship NMIntelFB. The source tree has it (kexts/NMIntelFB, "built-in panel framebuffer for Intel display versions 12-20"), but both installers still list KEXTS="NVRM NVAccel NVRMFB NVRMAGDC" (app/Resources/nullmoth-install.sh:8, package/install.sh:8), so 1.13.0 installs four kexts and /Library/Extensions has no NMIntelFB. A driver-provided framebuffer for the Intel panel would make the claim harmless exactly where it now breaks.

What works on this machine today (for anyone who finds this)

Keep the firmware-screen BAR values — UEFI -> Quirks -> ResizeGpuBars = -1, Booter -> Quirks -> ResizeAppleGpuBars = 0 — and boot with the driver off (-nvoff). The desktop then comes up on the firmware framebuffer (IONDRVFramebuffer publishes) and the machine is usable, but the NVIDIA GPU is unused. Note that Booter -> ResizeAppleGpuBars = -1 (the value setup writes) leaves this machine with nothing usable on screen at all; 0 is required here.

Evidence I can provide

Full log show --last boot --info --debug --predicate 'process == "kernel"' (both boots, ~3.7 MB), the OpenCore config.plist (before/after), the driver's own /Library/NullMoth/display-trace/* (kernel.txt, trace.txt, ws.txt) and wsreset.log, and ioreg/system_profiler SPDisplaysDataType from the parked boot.

App or game (if it is one)

No response

Did you change anything yourself?

1. UEFI -> Quirks -> ResizeGpuBars: 13 → -1
Booter -> Quirks -> ResizeAppleGpuBars: -1 → 0
   Reason: on this laptop the only display is the firmware framebuffer on the Intel GPU. With the values setup writes, the panel showed nothing usable at all; with -1 / 0 the firmware console is alive (the desktop still does not appear, because of the claim described above). This is also the pair your own "prepare" step writes (nullmoth-setup.sh:592), which is why I tried it.

2. boot-args: added / removed -nvoff only, to switch the driver off/on. Everything else in boot-args is exactly what setup wrote.

3. Kernel -> Block: empty. I also tried one entry, com.nullmoth.NVRMFB with Strategy Exclude, hoping to keep the kext from loading — it had no effect (same result as the driver being active), which matches the OpenCore documentation ("remove kexts from the prelinked kernel"): this kext lives in the auxiliary kernel collection.

No DeviceProperties for either GPU, no disable-gpu, no AAPL,ig-platform-id, no WhateverGreen agdpmod, no nv_disable=1, no -wegnoegpu. Lilu, AMFIPass (added by setup), WhateverGreen and the usual laptop kexts are present. SIP 0x0A43, SecureBootModel Disabled, csr-active-config untouched by me.