RTX 4060 Laptop: USB-C/DP hot-plug blacks out both displays; unplugging does not restore the internal panel

Aperta
#83 0 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
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
macos, rust
Ambito
desktop-dev

Direzione di ricerca

Start by reading related issues #66, #67, and #38, then identify the driver's display hot-plug and modesetting entry points. The report does not name source files or provide fresh failure logs, so first gather minimal logs and display-state data that distinguish driver behavior from saved WindowServer settings. Done means both displays recover after connecting and disconnecting the USB-C/DP monitor, with a safe way to restore a known display configuration.

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

Descrizione

Summary

On an ASUS ROG Strix G16 with an RTX 4060 Laptop GPU, the internal display currently works when macOS is started with the external monitor disconnected. Connecting the external monitor after login makes both displays go black / show no signal. Disconnecting it does not restore the internal display; restarting with the external monitor disconnected is required.

This is a user-observed report. The installed driver release and fresh failure logs have not yet been verified. I am not claiming reproduction on 1.9.0 or a confirmed driver-only cause: saved display settings may also contribute.

Hardware / OS

  • ASUS ROG Strix G16 G614JVR; Intel Core i9-14900HX; 32 GB RAM.
  • NVIDIA GeForce RTX 4060 Laptop GPU, 8 GB, PCI 10DE:28E0, subsystem 1043:3488; laptop set to dGPU/Ultimate mode.
  • macOS Sequoia 15.8.1 (24H32), OpenCore 1.0.9.
  • Internal panel: NE160QDM-NZ8, native 2560x1600, advertised 240 Hz.
  • External monitor: SG27Q, 2560x1440, connected through a USB-C / Thunderbolt 4 port using a DP adapter/cable. HDMI has not been tested.

Current reproduction / recovery

  1. Boot macOS with the external monitor disconnected; the internal desktop is usable.
  2. Connect the external monitor through USB-C/DP.
  3. Both displays become black / lose signal.
  4. Unplug the external monitor; the internal display remains black.
  5. Restart with the external monitor disconnected; the internal display works again.

Relevant timeline and tests

  • The external monitor previously worked, although display-mode changes were unstable.
  • Changing refresh rate from 60 Hz to higher modes caused flickering. Returning to 60 Hz did not reliably recover output during that session.
  • The sRGB color-profile workaround from #66 allowed the external monitor to run at 120 Hz, but did not resolve the internal-panel problem.
  • Enabling HiDPI in BetterDisplay then caused the external display to become unusable too.
  • Subsequent scaling experiments used CoreGraphics mode-setting calls, including a permanent configuration attempt. A recorded internal-only baseline remained 2560x1600 at 240 Hz with 1x scaling, despite calls returning CGError=0. This does not establish that all saved display configurations remained unchanged.
  • The persistent external-display failure was already present after those scaling experiments. A later SMBIOS test from MacBookPro16,2 to MacBookPro16,1 did not improve UI scaling; that model test has been reverted in the boot configuration. The hot-plug failure predates that model test.
  • Basic acceleration had become usable earlier: scrolling improved and LocalSend could render its window. The previous Metal-device startup failure was reported separately in #38 and should not be conflated with this display-mode problem.

Related reports / request

Related: #66 (refresh-rate/color-profile workaround), #67 (DP hot-plug and multiple displays).

Is this combination of dual-display blackout and failure to recover after unplugging a known modesetting/hot-plug issue? Which minimal logs or display-state data would help distinguish a driver failure from persisted WindowServer display settings? A safe way to restore both displays to a known configuration would also be useful.

No EFI identity values, account details, Wi-Fi credentials, or unredacted logs are included.

Lingua principale
Rust
Stelle
2.5k
Fork
233
Merge medio
3g 14h
PR unite (30g)
14

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.