DPCD Backlight control fails on RTX 5080 / Samsung OLED (ATNA60HU02-0) even with ACPI override

NVIDIA Open GPU Kernel Modules Version

590.48.01 (also tested 595.45.04 beta)

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

Fedora Linux 44 (Workstation Edition Prerelease)

Kernel Release

Linux legion 6.19.6-300.local.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 6 13:26:10 EST 2026 x86_64 GNU/Linux

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

GPU 0: NVIDIA GeForce RTX 5080 Laptop GPU (UUID: GPU-5595536f-d7fa-1a17-43f7-38fa703d5637)

Describe the bug

The hardware brightness controls for my laptop's internal Samsung OLED panel (ATNA60HU02-0) do not work, even when the ACPI NBCI method is overridden to report DPCD Extended control (0x0203).

With the ACPI override, the driver correctly accepts the panel type and creates the /sys/class/backlight/nvidia_0 interface. The values in the sysfs file update when using my keyboard brightness keys or GNOME slider. However, the screen's physical brightness does not change at all.

It seems the driver (or GSP firmware) is failing to send the actual DPCD AUX commands when the nvidia_0 backlight interface is used.

To Reproduce

1. Use a Lenovo Legion with an RTX 5080 and Samsung OLED in dGPU mode.
2. Inject an ACPI SSDT override to set the NBCI backlight type to 0x0203 (DPCD).
3. Change the brightness via GNOME or by echoing a value into /sys/class/backlight/nvidia_0/brightness.
4. Observe that the sysfs file updates, but the physical screen luminance remains unchanged.

Bug Incidence

Always

nvidia-bug-report.log.gz

nvidia-bug-report.log.gz

More Info

To figure out if the panel was just ignoring DPCD commands entirely, I wrote a small user-space C daemon to manually write to the DPCD PANEL_TARGET_LUMINANCE registers (0x734 - 0x736) using the NVIDIA RM API (CMD_DP_AUXCH_CTRL).

This manual workaround succeeds. The screen dims smoothly, proving the hardware is perfectly capable of DPCD backlight control.

I put the source code for my workaround up on GitHub here if it helps (or if other people hit this bug): https://github.com/msteele/nv-bright

Note regarding the proprietary driver checkbox:
The checkbox is worded ambiguously. I checked the box stating this is specific to the open kernel modules because I am currently compiling and running the nvidia-open branch (590.48.01 / 595.45.04 beta) and have not personally verified this against the proprietary blob. However, because the failure seems to occur after the NV0073_CTRL_CMD_SPECIFIC_SET_BACKLIGHT_BRIGHTNESS RM call is dispatched, I assume this bug affects the proprietary driver as well. I am reporting it here because the RM open-source layer allows us to see exactly where the DPCD write is failing.

Start with the attached nvidia-bug-report.log.gz and the nvidia_0 sysfs path; trace the brightness request around NV0073_CTRL_CMD_SPECIFIC_SET_BACKLIGHT_BRIGHTNESS and the DPCD AUX operation described in the report. The nv-bright workaround and CMD_DP_AUXCH_CTRL example provide a reference for the successful write. Done means keyboard, GNOME, or sysfs brightness changes produce physical luminance changes.