Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

GTX 1660 (TU116, 10DE:2184), 1.4.0, BAR1 256 MB, no Above 4G: grey screen — CoreDisplay "Fallback GPU Display Pipe transaction submission failed" after NVMTL "GPUPass / ViewportToNDC has no AIR"

Open
  • Is something wrong?
#75 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, rust
Domain
backend

Research direction

Start by reading the attached kernel-nvrm.txt and windowserver.txt excerpts alongside the NVRMFB and NVMTL paths that publish display-plane gamma capabilities and handle the GPU EOTF pass. Check how the 256 MB BAR1 setup affects that path, then compare the behavior across the reported driver versions. Done means identifying whether this configuration should work or what change enables the display to leave the grey screen.

Written by the indexing model from the issue text.

Description

Title: GTX 1660 (TU116, 10DE:2184), 1.4.0, BAR1 256 MB, no Above 4G: grey screen — CoreDisplay "Fallback GPU Display Pipe transaction submission failed" after NVMTL "GPUPass / ViewportToNDC has no AIR"

Summary

Driver 1.4.0 loads, GSP boots, the display is enumerated with EDID, head 0 keeps the firmware 3840x2160@60 mode, the scanout surface is accepted, NVAccel publishes the pipe and WindowServer reports "Metal compositor activated" (system_profiler: GTX 1660, 6 GB, Metal 3). The screen then stays grey forever. WindowServer does not crash; it loops on:

NVMTLDriver: NullMoth: reflection: GPUPass has no AIR — cannot be reflected
NVMTLDriver: NullMoth: reflection: ViewportToNDC has no AIR — cannot be reflected
CoreDisplay: [ERROR] Fallback GPU Display Pipe transaction submission failed
  Display Pipe Operations: Fetch - Pipe, ..., System Gamma - Unknown, Regamma - None, EOTF - GPU
CoreDisplay: [ERROR] Attempting to get capabilities from plane with no gamma   (repeated)

Also seen once per boot: NVMTLDriver: item 7: surface 3 plane 0: family VRAM import refused (-1000072003) - private image + copies.

Hardware / setup

  • Lenovo IdeaCentre GeekPro-15ICB (OEM B360), i5-9400. BIOS hides Above 4G Decoding, no ReBAR. CSM off, Secure Boot off.
  • GTX 1660 6 GB (TU116, 10DE:2184, subsys 1642:1920). bar1: BAR1 is 256 MB and the card offers no 4-8 GB size — not placing; BAR1 lives at 0x7f80000000.
  • Monitor: LG UltraFine 4K (EDID vid 0x1E6D pid 0x5BC2, HDR10 + BT.2020 advertised), single display.
  • macOS 15.8.1 (24H32), OpenCore REL-109, driver 1.4.0 installed with install.sh (CHECK=1 passed).
  • csr-active-config 430A0000, SecureBootModel Disabled, IONDRVSupport blocked (Exclude), ResizeGpuBars -1 / ResizeAppleGpuBars -1 (13 would not be valid without Above 4G).

What I tried (each one boot, same grey screen and same log lines)

Change Result
HDMI → DisplayPort same
nvhwvbl=0 (#61) same
-nvrmnoflip (#54) same
iGPU (UHD 630) disabled via disable-gpu → WindowServer sees only the NVIDIA GPU same
EDID override: HDR static metadata → SDR only, colorimetry BT.2020 cleared (applied, display name changed) same, still EOTF - GPU
EDID override 8 bpc instead of 10 bpc same
SMBIOS iMac19,1 → iMacPro1,1 same
sudo killall -9 WindowServer same
Driver 1.1.0 (+ chmod 644 nvmtl-allow.txt) WindowServer crash loop vkCreateDevice -> -2 until nvrm610.conf gets CECHAN=0, NVK_CMDPOOL_GPU_UNCACHED=1, NVK_SYSMEM_GPU_UNCACHED=1 (#5); then same grey screen + same reflection error
Driver 1.0.11 (the version #32 used on a GTX 1660 Ti) + the same conf same; only the hardware cursor is visible
iGPU enabled with a display-capable platform-id (00009B3E) next to the NVIDIA driver hard hang during boot, no SSH
OpenCore Resolution 1920x1080@32 + 1080p-only EDID override NVRMFB still keeps a 3840x2160 scanout (DisplaySurface Size: (3840x2160)), same error

boot-args (last run): -v keepsyms=1 debug=0x100 nvfb=1 nvaccel=1 nvfbheads=4 -nvkmsnosmooth amfi_get_out_of_my_way=0x1 amfi=0x80 -nvrmnoflip

So the failure is identical on 1.0.11, 1.1.0 and 1.4.0.

Question

CoreDisplay always takes the GPU fallback path here because the plane reports no gamma, and NVMTL cannot translate Apple's precompiled GPUPass / ViewportToNDC (no AIR). Is this path expected to work with a 256 MB BAR1 (no BAR1 placement), or is there a knob to make NVRMFB publish gamma capabilities so CoreDisplay does not need the GPU EOTF pass?

Kernel (NVRM/NVRMFB/NVAccel) and WindowServer excerpts attached: kernel-nvrm.txt, windowserver.txt.

kernel-nvrm.txt
windowserver.txt

Dominant language
Rust
Stars
2.5k
Forks
233
Avg merge
1h 37m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nullmoth/nvidia-macos-driver

All issues in nullmoth/nvidia-macos-driver

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.