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

[P3] Black screen just before the login window — the cursor is visible on it (WindowServer up, no composited frame)

Open
#101 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
desktop

Research direction

Start in kexts/NVRMFB/fb/nvrm-fb.cpp at nvFlipToSurfacePure and trace the home flip through flipToMemory(). The reporter can reproduce the black frame by logging out and offers to run “Record the flicker”; first check whether that capture or an existing counter can establish whether fSurf was ready at the flip. Done means identifying the cause of the transient black frame or gathering enough measurements to narrow it down.

Written by the indexing model from the issue text.

Description

A black frame just before the login window — and logging out reproduces it

RTX 3080 10 GB (Ampere), macOS 15.8.1, driver 1.10.0. The machine is the one that has been reporting
#73 / #74 / #24.

The symptom: a sub-second black frame right as the login window appears. On boot it looks like
progress bar completes → black → login window. It is not a display dropout — the backlight stays on and
the panel never loses sync
; only the content goes black for a moment.

The useful part: it is not boot-specific. Logging out reproduces it — the same black frame appears
when the login window comes back. So it can be triggered on demand, without rebooting.


What the log shows at that moment
01:59:28.134  NVRM-fb: home flip #1: pure (head 0 already lit, no modeset)
01:59:32.621  NVRM-fb: home flip #2: pure (head 0 already lit, no modeset)

and during boot, for reference:

01:57:47.463  NVRM-fb: boot screen: head 0 painted the 1920x1080 boot image (pitch 8192) centred on 1920x1080
01:57:48.286  NVRM-fb: setDetailedTimings: boot raster 1920x1080@60 is dt 0x10000 -- that is the current mode now (no modeset)
01:57:48.286  NVRM-fb: fb0 setDetailedTimings: 53 timing(s) installed (27 from macOS, 26 refresh rates from NVKMS; 0 malformed, 27 offered), current 0x10000, EDID matches so far 39
Where I think it comes from

kexts/NVRMFB/fb/nvrm-fb.cpp:2121 (nvFlipToSurfacePure):

const bool home = (f->flags & 1u) != 0;
const bool pureHome = home && fModeSet;
if (pureHome) { fHomePure++; if (fHomePure <= 4) FBLOG("home flip #%u: pure (head %u already lit, no modeset)", fHomePure, fHead); }
bool ok = flipToMemory(home ? nullptr : (struct NvKmsKapiMemory *)f->kapiMemory,
                       f->width, f->height, f->pitch, &rc, !home || pureHome, f->allocationCookie);

A home flip passes mem = nullptr, so flipToMemory() takes the surf = fSurf branch — it flips the
scan-out back to the framebuffer's own surface. The log says no modeset, i.e. the timing is untouched,
which matches what is seen: the panel keeps scanning, and the frame it scans is black.

So the guess is that at the moment of the home flip, fSurf does not hold a ready frame yet, and that
single flip is what is visible. I cannot confirm that from outside — which is why I am sending the numbers
below rather than a patch.


What I ruled out first (all measured on this machine)
tried result
-nvrmnobootscreen removed boot-screen snapshot now works (copied 1920x1080 pitch 8192 (8640 KB) … in 1864 ms + painted), black frame unchanged
-nvkmsnosmooth removed no change
-v removed no change (it only made the flash more obvious)
desktop 60 Hz instead of 75 Hz no change — boot raster and desktop mode both 60 Hz now (IOFBCurrentPixelClock = 148500000)
-nvrmnoflip removed no change to this; zero-copy now auto-enables 60 s after the release as intended

Current boot-args: nvfb=1 nvaccel=1 nvfbheads=4 amfi_get_out_of_my_way=0x1 amfi=0x80 -wegnoigpu nvrmsettle=1500

What would help

I can run Record the flicker while logging out, so the capture covers the flash. If there is a counter
that counts a flip whose target surface was not ready — or that would say whether fSurf had been written
when the home flip happened — I will run it and send the number.


中文版(Chinese version)
登录窗口出现前的一帧黑 —— 注销也能复现它

RTX 3080 10 GB(Ampere),macOS 15.8.1,驱动 1.10.0。 本机就是一直在报 #73 / #74 / #24 的那台。

症状: 登录窗口出现的那一刻,有一帧亚秒级的黑。启动时看起来像 进度条走完 → 黑 → 登录窗口。它不是显示掉线——背光一直亮着,面板也从未失去同步;只是内容黑了一瞬。

有用的部分:它不是启动特有的。 注销也能复现——登录窗口回来时出现同样的黑帧。所以它可以按需触发,不用重启。


那一刻日志显示什么
01:59:28.134  NVRM-fb: home flip #1: pure (head 0 already lit, no modeset)
01:59:32.621  NVRM-fb: home flip #2: pure (head 0 already lit, no modeset)

以及启动期间,供参考:

01:57:47.463  NVRM-fb: boot screen: head 0 painted the 1920x1080 boot image (pitch 8192) centred on 1920x1080
01:57:48.286  NVRM-fb: setDetailedTimings: boot raster 1920x1080@60 is dt 0x10000 -- that is the current mode now (no modeset)
01:57:48.286  NVRM-fb: fb0 setDetailedTimings: 53 timing(s) installed (27 from macOS, 26 refresh rates from NVKMS; 0 malformed, 27 offered), current 0x10000, EDID matches so far 39
我认为它来自哪

kexts/NVRMFB/fb/nvrm-fb.cpp:2121(nvFlipToSurfacePure):

const bool home = (f->flags & 1u) != 0;
const bool pureHome = home && fModeSet;
if (pureHome) { fHomePure++; if (fHomePure <= 4) FBLOG("home flip #%u: pure (head %u already lit, no modeset)", fHomePure, fHead); }
bool ok = flipToMemory(home ? nullptr : (struct NvKmsKapiMemory *)f->kapiMemory,
                       f->width, f->height, f->pitch, &rc, !home || pureHome, f->allocationCookie);

home 翻转传 mem = nullptr,于是 flipToMemory() 走 surf = fSurf 分支——它把扫描输出翻回 framebuffer 自己的 surface。日志说 no modeset,即时序没被改动,这与观察一致:面板继续扫描,而它扫的那一帧是黑的。

所以猜测是:home 翻转发生的那一刻,fSurf 里还没有一帧就绪的内容,而那一次翻转就是可见的东西。我在外部无法确认这一点——这也是为什么我发的是下面的数字而不是补丁。


我先排除掉的(都在本机测过)
试过 结果
移除 -nvrmnobootscreen 开机画面快照现在能用了(copied 1920x1080 pitch 8192 (8640 KB) … in 1864 ms + painted),黑帧不变
移除 -nvkmsnosmooth 无变化
移除 -v 无变化(它只是让那一下更明显)
桌面用 60 Hz 而非 75 Hz 无变化 —— 现在 boot raster 和桌面模式都是 60 Hz(IOFBCurrentPixelClock = 148500000)
移除 -nvrmnoflip 对此无变化;零拷贝现在如预期在 release 后 60 秒自动启用

当前 boot-args:nvfb=1 nvaccel=1 nvfbheads=4 amfi_get_out_of_my_way=0x1 amfi=0x80 -wegnoigpu nvrmsettle=1500

什么会有帮助

我可以在注销时跑 Record the flicker,让采样覆盖到那一闪。如果有某个计数器会统计「目标 surface 尚未就绪的翻转」,或者能说明 home 翻转发生时 fSurf 是否已被写入,我就跑它并把数字发过来。

Dominant language
Rust
Stars
2.5k
Forks
233
PR merge metrics
No merged PRs in 30d

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.