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

[Bug]: Internal eDP 240/300 Hz black screen + no HDR (potentialHeadRoom=1) on RTX 4060 Laptop

Open
  • Is something wrong?
#429 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

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

Research direction

Start by reviewing the reported NVKMS mode enumeration and DSC parameter logs, then trace the eDP mode-set and commit path and the brightness probe handling. The report identifies no source files or failing tests, so locating both paths will require familiarity with the driver. Done means the internal panel handles 240/300 Hz without a black screen and exposes HDR headroom, or logs a clear rejection when the mode cannot be committed.

Written by the indexing model from the issue text.

Description

bug
Send logs report ID

NM-DPJJRR5D, NM-8Y6JXEAR, NM-YT829G95, NM-FSQ43ZMF, NM-QY7NDQC3, NM-RQ2B2E2S, NM-TSA0ZR3M, NM-YR5HF2W4, NM-9KJSV49A, NM-FV92C513, NM-48GQRXT7, NM-QGKRV2AW, NM-RYSXPQ77, NM-2451P1JY, NM-K5YPVKW2

Where does it go wrong?

On the desktop (flicker, lag, displays, sleep)

What happens

The following are the findings I have gathered after testing my ASUS TUF Gaming A16 (2024)—model FA607PV (known in China as the TUF TX5 Pro / 天选5 Pro)—for two days. The inner screen goes black as soon as the high refresh rate is enabled, and HDR cannot be turned on either.

Two reproducible display problems on my laptop's internal eDP panel
(BOE NE160QDM-NM9, 2560x1600, 300 Hz — an aftermarket upgrade panel,
see below). 60 Hz works; an external DP 4K 120 Hz display works fine on
the same GPU. The panel runs 300 Hz under Windows on this machine over
the same cable, so panel and eDP link are healthy.

A) No HDR. CoreDisplay says the panel allows HDR but the toggle never
appears. It logs this consistently (116 identical samples over 12 h):

fpSupport_GetVideoRangeForCoreDisplayWithPreference: displayID ...
    potentialHeadRoom=1 wideColorSupported=YES deviceAllowsHDR=YES

and this error about once per minute:

[ERROR] - GetUserBrightness: Set linear-brightness-probe to
    1.000000 failed (0xe00002c7)

0xe00002c7 is kIOReturnUnsupported. corebrightnessd has the
linear-brightness report registered (ReportID 2, max 100), so the
system side is ready — the driver never answers the probe, headroom
falls back to 1.0. Both my EDIDs have HDR static metadata with PQ set,
so EDID is fine. strings on NVRMFB shows no linear/headroom/EDR/HDR/
probe symbols; NVRM does expose backlight get/set commands, so there
is a path the probe could be built on.

B) 240/300 Hz black screen. The modes are enumerated as valid and DSC
parameters are computed:

NVRM-fb: fb0 NVKMS mode 1: 2560x1600 @300 Hz pclk 1370880000 valid 1
NVRM-fb: fb0 2560x1600 pclk 1370880000 needs DSC: 2 slices of 1280, 16.06 bpp
NVRM-fb: fb0 2560x1600 pclk 1096700000 needs DSC: 2 slices of 1280, 16.06 bpp

but switching to 240 Hz or 300 Hz black-screens the internal panel.
External DP commits fine without DSC:

NVRM-fb: switchMode 0x10700: COMMIT 3840x2160 @120000 mHz
    pclk 1066560000 -> 1

Those pclk values need DSC (way past the uncompressed eDP link), and
DSC params are already computed, so I suspect the eDP DSC mode-set /
commit path. No failure line is logged before the screen goes black.
I can attempt a controlled switch with the external display attached
to capture the exact rejection point if that helps.

Expected: A) headroom > 1 and an HDR toggle; B) 240/300 Hz works, or
fails cleanly with a log line instead of a black screen.

Written by you
  • I wrote this report myself. AI-written issues are closed without review (see CONTRIBUTING.md).
App or game (if it is one)

No response

Did you change anything yourself?

Hardware: the internal panel is an aftermarket upgrade — I replaced the
stock panel with a BOE NE160QDM-NM9 (2560x1600, 300 Hz). It runs 300 Hz
fine under Windows on this machine over the same eDP cable.

Software: OpenCore on AMD (Ryzen 9 7940HX) with WhateverGreen. Custom
boot-args: keepsyms=1 -vi2c-force-polling -ibtcompatbeta nvfb=1
nvaccel=1 -nvkmsnosmooth amfi_get_out_of_my_way=0x1 amfi=0x80
ipc_control_port_options=0 gfxrst=4 nvfbheads=4 nvrmacpibl=1 alcid=13
No modifications to the NVIDIA driver or its kexts — installed as
shipped by 1401.

Dominant language
Rust
Stars
2.5k
Forks
233
Avg merge
3d 14h
Merged PRs (30d)
14

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.