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

[Test report] XPS 15 7590 GTX 1650 on Sequoia 15.8.1: verified Metal compute, Intel displays, one lid-reopen backlight incident

Open
#170 0 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
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, rust

Research direction

Start by reading the pinned driver README and setup script linked in the report, then inspect the wake and backlight behavior around the reported Clamshell Sleep, DarkWake, and FullWake transitions. The report identifies a backlight value of 0 after lid reopen and a successful runtime brightness reset, but does not establish the cause or provide a persistent fix. Done means reproducing and isolating the wake-time backlight failure and documenting a reliable recovery or fix.

Written by the indexing model from the issue text.

Description

Diagnostic report ID

Not generated: installation and verification were performed through the release CLI package, not the 1401 Mac app. The observations below are a manual report, with precise limits. No general laptop compatibility qualification is claimed.

Dell XPS 15 7590 GTX 1650 Metal compute test on macOS Sequoia

Tested October 12, 2026. NullMoth 1.14.7 installed and loaded on a Dell XPS 15 7590 running macOS Sequoia 15.8.1. Both Intel UHD 630 and the NVIDIA GTX 1650 appeared as Metal devices. A repeated NVIDIA compute workload returned the expected results, with an Intel control test also passing. This is a basic compute result, not general game, rendering, or laptop compatibility qualification.

Hardware and software

Item Tested configuration
Laptop Dell XPS 15 7590, BIOS 1.12.0
CPU Intel Core i7-9750H
Memory 16 GB
Integrated GPU Intel UHD 630, PCI ID 8086:3e9b
NVIDIA GPU GTX 1650 Mobile TU117, PCI ID 10de:1f91, 4 GB VRAM
OS macOS Sequoia 15.8.1, build 24H32
Bootloader OpenCore 1.0.8, external USB EFI
NVIDIA package NullMoth 1.14.7; release archive and internal payload checksums verified
Internal display 1920 x 1080, native Intel graphics
HDMI display 1920 x 1080 at 60 Hz, reported under Intel UHD 630

Boot configuration and display corruption

The initial working configuration disabled the discrete GPU using SSDT-DGPU.aml and its paired _WAK-to-ZWAK ACPI patch, plus WhateverGreen's -wegnoegpu boot argument and the Intel disable-external-gpu device property.

For NVIDIA detection, SSDT-DGPU.aml and its paired wake patch were disabled, -wegnoegpu was removed, and disable-external-gpu was removed. The NVIDIA PCI device became visible, but the login screen showed extensive colored corruption. No NVIDIA driver had been installed at that point. Restoring the original configuration restored the normal display.

A narrower test disabled only the ACPI power-off mechanism while retaining the GPU-hiding settings. Intel graphics worked, but NVIDIA remained absent from the PCI listing.

The next test exposed NVIDIA again and added an OpenCore Kernel Block entry:

Identifier: com.apple.iokit.IONDRVSupport
Strategy: Exclude
Enabled: true
Arch: Any
MinKernel and MaxKernel: empty

With this entry, the NVIDIA device was visible and the user confirmed a normal screen. Intel's native framebuffer configuration and WhateverGreen remained enabled. The earlier boot log contained getPixelInformation for framebuffer 0 failed. Together, these observations are consistent with a firmware-framebuffer conflict, but do not independently establish its full root cause.

All staged configurations passed OpenCore 1.0.8's ocvalidate. Existing GPU BAR settings were preserved; no desktop RTX-specific forced BAR size was applied.

Installation

The package's CHECK=1 preflight passed NVIDIA detection, payload checksums, userland runtime requirements, and a test kernel collection containing all four NVIDIA components.

The first actual installation stopped during kernel-collection backup with Operation not permitted while SIP was enabled, before the driver installation stage. After applying the explicitly approved security settings and rebooting, installation completed with exit status 0 and a saved rollback backup.

The driver test used:

csr-active-config: 430A0000 (Data)
SecureBootModel: Disabled
AMFIPass: 1.4.1, loaded after Lilu
boot-args:
-v keepsyms=1 debug=0x100 -igfxblt nvfb=1 nvaccel=1 nvfbheads=4
-nvkmsnosmooth nvrmsettle=10000 amfi_get_out_of_my_way=0x1
amfi=0x80 ipc_control_port_options=0

These settings reduce SIP and AMFI protections and persist across reboots. They are part of this explicitly approved lab test, not a recommendation for a default installation.

After reboot, kmutil confirmed these loaded components:

com.nullmoth.NVRM
com.nullmoth.NVAccel
com.nullmoth.NVRMFB
com.nullmoth.NVRMAGDC

System Profiler reported NVIDIA GeForce GTX 1650, 4 GB VRAM, and Metal 3 support. IORegistry showed NVAccel active and NVAccelHeadless = Yes. The laptop display and HDMI monitor remained attached to Intel UHD 630.

Compute verification and corrected test

A first Metal buffer-fill command completed on NVIDIA. That established command submission and completion, but did not verify the returned bytes.

A subsequent JavaScript for Automation compute test initially returned all zeros on NVIDIA. The identical Intel test also returned zeros. Intel buffer-fill readback correctly returned repeated 0x5A bytes, pointing to the compute dispatch harness rather than a demonstrated NVIDIA failure.

The JXA bridge exposed MTLSize with unnamed fields, so passing JavaScript objects containing width, height, and depth did not provide a valid test dispatch. The harness was corrected to invoke dispatchThreadgroups:threadsPerThreadgroup: through NSInvocation with explicit 24-byte MTLSize arguments: three little-endian 64-bit integers for each size.

The corrected workload compiled this Metal kernel:

#include <metal_stdlib>
using namespace metal;
kernel void verify(device uint *out [[buffer(0)]],
                   uint i [[thread_position_in_grid]]) {
    out[i] = i * 3 + 7;
}

For each GPU, the test submitted 20 sequential dispatches, each with one group of 64 threads. It used a 256-byte managed buffer, explicit resource synchronization, and waited for command completion. The final 64 unsigned 32-bit values were independently decoded and compared against i * 3 + 7.

intel: PASS, 64/64 correct values after 20 compute dispatches
nvidia: PASS, 64/64 correct values after 20 compute dispatches

The earlier all-zero result was a test-harness error and must not be reported as a confirmed NVIDIA compute failure.

Driver warnings and limits

The driver reported BAR1 at 256 MB and VRAM at 4096 MB. Logs included VK_ERROR_UNKNOWN, a failed copy-engine queue creation followed by use of a graphics channel, and SET_LG_SECTOR_PROMOTION 64B rc 0x56. The corrected small compute workload passed despite these warnings.

Application rendering, games, video decode/encode, extended stress, performance comparisons, full suspend/resume reliability, and long-term stability remain unqualified. Neither the internal screen nor HDMI was driven directly by NVIDIA. Cross-GPU presentation has not been demonstrated.

Lid reopen backlight issue

After the compute tests, the user closed and reopened the lid and reported that the internal screen was extremely dim. Power-management logs recorded Clamshell Sleep into DarkWake, followed by a lid-triggered transition to FullWake. The machine remained accessible remotely. Intel and NVIDIA still appeared as Metal devices.

IORegistry's AppleBacklightDisplay IODisplayParameters showed bklt with min 0, max 65535, and value 0. A runtime IODisplaySetFloatParameter call setting bklt to 1.0 returned success, and a subsequent IORegistry read showed value 65535. The user confirmed normal brightness was restored without rebooting.

This is an observed backlight restoration problem during the NVIDIA-enabled test configuration. The user subsequently reported that it did not seem to be happening again; recurrence is not established. It has not been reproduced with NVIDIA removed or isolated from the laptop ACPI, Intel backlight, and firmware-framebuffer changes. The runtime brightness adjustment is a recovery action, not a persistent wake fix.

The known-working Intel/Wi-Fi EFI was preserved separately and on USB partition 2. An installer rollback backup was also retained. The system still boots through external USB OpenCore; internal EFI installation was not part of this test.

Upstream references

This report concerns one physical laptop and one driver release. It does not qualify all GTX 1650 laptops or all macOS 15 systems.

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.