Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

close

Chiusa
  • Qualcosa non va?
#101 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 是否已被写入，我就跑它并把数字发过来。

Lingua principale
Rust
Stelle
2.5k
Fork
233
Merge medio
1h 37m
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nullmoth/nvidia-macos-driver

Tutte le issue di nullmoth/nvidia-macos-driver

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.