[Bug 221430] New: nvidia_wmi_ec_backlight: brightness writes silently dropped on HP OMEN 16 (2025)

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221430

            Bug ID: 221430
           Summary: nvidia_wmi_ec_backlight: brightness writes silently
                    dropped on HP OMEN 16 (2025)
           Product: Drivers
           Version: 2.5
    Kernel Version: 6.19.14
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Platform_x86
          Assignee: drivers_platform_x86@kernel-bugs.osdl.org
          Reporter: floquimaurice@gmail.com
        Regression: No

Created attachment 309992
  --> https://bugzilla.kernel.org/attachment.cgi?id=309992&action=edit
ACPI tables (DSDT + all SSDTs, raw .dat and disassebled .dsl)

Reporting a backlight issue on a recent HP OMEN 16 with hybrid Optimus.

# System

- HP OMEN by HP Gaming Laptop 16 (2024/2025)
- Intel Meteor Lake + NVIDIA RTX 5070 Mobile, NVIDIA driver 595.x
- Fedora 44, kernel 6.19.14-300.fc44.x86_64
- Hybrid graphics mode (BIOS)

# Symptom

nvidia_wmi_ec_backlight loads, sysfs is created, writes to brightness are
accepted, but the panel does not respond and actual_brightness returns
"No data available".

  $ echo 50 | sudo tee /sys/class/backlight/nvidia_wmi_ec_backlight/brightness
  $ cat /sys/class/backlight/nvidia_wmi_ec_backlight/actual_brightness
  cat: actual_brightness: No data available

The AE_AML_OPERAND_VALUE errors visible in dmesg come from hp_bioscfg
against \_SB.WMID.* and are unrelated to the backlight path.

# What the firmware does

The NVIDIA-bound WMAA is at \_SB.PC00.AWMI.WMAA, GUID
603E9613-EF25-4338-A3D0-C46177516DB7. Its write path declares LEDB as the
new brightness value from Arg2[4], but never reads it:

    ElseIf ((MODF == One))
    {
        Sleep (0x64)
        Local1 = \_SB.PC00.GFX0.CBL1     /* reads existing value */
        Local3 = (Local1 * 0x02)
        If ((Local3 == Zero)) { Local3 += 0x02 }
        \_SB.PC00.LPCB.ECPW = Local3
        Return (Zero)
    }

The firmware propagates \_SB.PC00.GFX0.CBL1 (which the Windows display
driver populates before invoking WMI) to the EC PWM register, instead of
using the value the OS driver passed in. Under Linux nothing populates
CBL1, so the WMI call returns success but is effectively a no-op.

# Attachments

- dmesg-clean.txt
- dmidecode-clean.txt
- acpi-tables-omen16.tar.gz (DSDT + all SSDTs, raw and disassembled)
- lspci-full.txt

Happy to test patches or provide additional traces.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.