Plan to fix nvidia_wmi_ec backlight issues, help wanted

Plan to fix nvidia_wmi_ec backlight issues, help wanted

[Hans de Goede]

Hi All,

A while ago Nvidia introduced a new Nvidia specific firmware method
for controlling the backlight on laptops with runtime switchable
Nvidia hybrid graphics.

This is supported through the nvidia-wmi-ec-backlight driver, but has
never worked 100%.

The new WMI firmware interface has a method to ask the firmware if
the backlight is controlled though the EC and this the new WMI interface
should be used; or if it is directly controlled by the GPU and the GPU
driver's native backlight support should be used.

There are several bugs in the implementation of this on various laptops:

1. The method to get the backlight control source sometimes does not
report the correct value.

2. On some laptop models which method (native-gpu vs nvidia-wmi) works
changes at runtime, e.g. when plugging in a charger.

Known affected laptop models/bug reports about this:
- Acer Predator PH315-55: needs acpi_backlight=native
- Dell G15 5515 with RTX 3050: *needs* acpi_backlight=native
- Dell G15 5515 with RTX 3060: *breaks* with acpi_backlight=native
- Lenovo Legion Slim 7 2021
- https://bugzilla.kernel.org/show_bug.cgi?id=217026
- https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/work_items/784
- https://gitlab.freedesktop.org/drm/amd/-/issues/4512
- https://bugzilla.suse.com/show_bug.cgi?id=1217750

It turns out that under Windows both a WMI backlight driver and a GPU
native backlight driver get installed and Windows simply always calls
both when the backlight changes working around these kind of firmware
bugs.

When this first came up, about 2 years ago, I came up with the below
plan to fix this. Nvidia was supposed to work in implementing this,
but so far an implementation of this plan has not happened.

Note I do not have time to work on this myself. I'm posting this here
in the hope that either Nvidia will pick this up after all; or that
someone else can make this happen.

I'm more then happy to help answering any questions which may come up
while implementing this; and to review the resulting patches.


The plan
========

1. Modify the core backlight code to allow registering a backlight-device
for in kernel use only, disabling the registering of a class device under
/sys/class/backlight .

2. Add a new backlight-aggregate.c backlight driver, which exports a
devm_backlight_aggregate_register_or_add() function. Drivers can call
this passing in an existing backlight-device (with its sysfs interface
disabled). This either creates a singleton /sys/class/backlight/aggregate
device, or adds the passed in backlight to the existing singleton instance
if it already exists.

This new driver always exposes a range of 0-255 to userspace. This acts
as a proxie for any backlight-devices registered to be part of
the aggregate, forwarding any brightness set calls to all backlights,
scaled to their actual range. For reads this will report the last set
brightness value (starting with the value of the first registered
backlight-device).

3. Add a new nvidia_wmi_ec_and_native type to drivers/acpi/video_detect.c
for both DMI quirks and commandline handling.

4. Modify acpi_video_backlight_use_native() to also return true if
the __acpi_video_get_backlight_type() call there returns the new
acpi_backlight_nvidia_wmi_ec_and_native.

5. Add a new devm_backlight_device_register_native() helper which
calls __acpi_video_get_backlight_type(true, NULL) and if that returns
the new nvidia_wmi_ec_and_native type then registers the passed in
backlight with the flag to not register a sysfs class interface and
then on success calls the new devm_backlight_aggregate_register_or_add()
with the just registered backlight device; and if the returned type
instead is acpi_backlight_native register the passed in backlight
normally through devm_backlight_device_register()

5. Modify the i915 and amdgpu drivers to use the new
devm_backlight_device_register_native() helper. Since this new helper
checks the backlight-type itself, drop acpi_video_backlight_use_native()
checks *if* the registration is the only thing guarded by that check.

6. drivers/platform/x86/nvidia-wmi-ec-backlight.c to not return
early from probe when acpi_video_get_backlight_type() returns
the new nvidia_wmi_ec_and_native type and for that type make it
registers its backlight with the flag to not register a sysfs class
interface and then on success calls the new
devm_backlight_aggregate_register_or_add().

Regards,

Hans

Plan to fix nvidia_wmi_ec backlight issues, help wanted

[Hans de Goede]

<resend adding pdx86 list, sorry>

Hi All,

A while ago Nvidia introduced a new Nvidia specific firmware method
for controlling the backlight on laptops with runtime switchable
Nvidia hybrid graphics.

This is supported through the nvidia-wmi-ec-backlight driver, but has
never worked 100%.

The new WMI firmware interface has a method to ask the firmware if
the backlight is controlled though the EC and this the new WMI interface
should be used; or if it is directly controlled by the GPU and the GPU
driver's native backlight support should be used.

There are several bugs in the implementation of this on various laptops:

1. The method to get the backlight control source sometimes does not
report the correct value.

2. On some laptop models which method (native-gpu vs nvidia-wmi) works
changes at runtime, e.g. when plugging in a charger.

Known affected laptop models/bug reports about this:
- Acer Predator PH315-55: needs acpi_backlight=native
- Dell G15 5515 with RTX 3050: *needs* acpi_backlight=native
- Dell G15 5515 with RTX 3060: *breaks* with acpi_backlight=native
- Lenovo Legion Slim 7 2021
- https://bugzilla.kernel.org/show_bug.cgi?id=217026
- https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/work_items/784
- https://gitlab.freedesktop.org/drm/amd/-/issues/4512
- https://bugzilla.suse.com/show_bug.cgi?id=1217750

It turns out that under Windows both a WMI backlight driver and a GPU
native backlight driver get installed and Windows simply always calls
both when the backlight changes working around these kind of firmware
bugs.

When this first came up, about 2 years ago, I came up with the below
plan to fix this. Nvidia was supposed to work in implementing this,
but so far an implementation of this plan has not happened.

Note I do not have time to work on this myself. I'm posting this here
in the hope that either Nvidia will pick this up after all; or that
someone else can make this happen.

I'm more then happy to help answering any questions which may come up
while implementing this; and to review the resulting patches.


The plan
========

1. Modify the core backlight code to allow registering a backlight-device
for in kernel use only, disabling the registering of a class device under
/sys/class/backlight .

2. Add a new backlight-aggregate.c backlight driver, which exports a
devm_backlight_aggregate_register_or_add() function. Drivers can call
this passing in an existing backlight-device (with its sysfs interface
disabled). This either creates a singleton /sys/class/backlight/aggregate
device, or adds the passed in backlight to the existing singleton instance
if it already exists.

This new driver always exposes a range of 0-255 to userspace. This acts
as a proxie for any backlight-devices registered to be part of
the aggregate, forwarding any brightness set calls to all backlights,
scaled to their actual range. For reads this will report the last set
brightness value (starting with the value of the first registered
backlight-device).

3. Add a new nvidia_wmi_ec_and_native type to drivers/acpi/video_detect.c
for both DMI quirks and commandline handling.

4. Modify acpi_video_backlight_use_native() to also return true if
the __acpi_video_get_backlight_type() call there returns the new
acpi_backlight_nvidia_wmi_ec_and_native.

5. Add a new devm_backlight_device_register_native() helper which
calls __acpi_video_get_backlight_type(true, NULL) and if that returns
the new nvidia_wmi_ec_and_native type then registers the passed in
backlight with the flag to not register a sysfs class interface and
then on success calls the new devm_backlight_aggregate_register_or_add()
with the just registered backlight device; and if the returned type
instead is acpi_backlight_native register the passed in backlight
normally through devm_backlight_device_register()

5. Modify the i915 and amdgpu drivers to use the new
devm_backlight_device_register_native() helper. Since this new helper
checks the backlight-type itself, drop acpi_video_backlight_use_native()
checks *if* the registration is the only thing guarded by that check.

6. drivers/platform/x86/nvidia-wmi-ec-backlight.c to not return
early from probe when acpi_video_get_backlight_type() returns
the new nvidia_wmi_ec_and_native type and for that type make it
registers its backlight with the flag to not register a sysfs class
interface and then on success calls the new
devm_backlight_aggregate_register_or_add().

Regards,

Hans

Re: Plan to fix nvidia_wmi_ec backlight issues, help wanted

[Daniel Dadap]

Thanks, Hans -

On Tue, May 05, 2026 at 11:52:55AM +0200, Hans de Goede wrote:
> <resend adding pdx86 list, sorry>
> 
> Hi All,
> 
> A while ago Nvidia introduced a new Nvidia specific firmware method
> for controlling the backlight on laptops with runtime switchable
> Nvidia hybrid graphics.
> 
> This is supported through the nvidia-wmi-ec-backlight driver, but has
> never worked 100%.
> 
> The new WMI firmware interface has a method to ask the firmware if
> the backlight is controlled though the EC and this the new WMI interface
> should be used; or if it is directly controlled by the GPU and the GPU
> driver's native backlight support should be used.
> 
> There are several bugs in the implementation of this on various laptops:
> 
> 1. The method to get the backlight control source sometimes does not
> report the correct value.
> 
> 2. On some laptop models which method (native-gpu vs nvidia-wmi) works
> changes at runtime, e.g. when plugging in a charger.
> 
> Known affected laptop models/bug reports about this:
> - Acer Predator PH315-55: needs acpi_backlight=native
> - Dell G15 5515 with RTX 3050: *needs* acpi_backlight=native
> - Dell G15 5515 with RTX 3060: *breaks* with acpi_backlight=native
> - Lenovo Legion Slim 7 2021
> - https://bugzilla.kernel.org/show_bug.cgi?id=217026
> - https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/work_items/784
> - https://gitlab.freedesktop.org/drm/amd/-/issues/4512
> - https://bugzilla.suse.com/show_bug.cgi?id=1217750

I believe there were also a couple of cases where different builds of the
same notebook (as far as DMI quirks tables could detect) would be driven
by different methods, exacerbating problem (1) because adding a quirtk to
fix one notebook would break other versions of the "same" notebook. (Oh,
maybe that's the two G15 5515 bugs linked above.)

> 
> It turns out that under Windows both a WMI backlight driver and a GPU
> native backlight driver get installed and Windows simply always calls
> both when the backlight changes working around these kind of firmware
> bugs.
> 

Yes, it's frustrating that so many notebooks have implementations of this
interface that have bugs that get masked by Windows always using both of
the interfaces. I wonder whether Windows behaves this way because bugs of
this type are so prevalent, or if the bugs are prevalent because Windows
always behaved that way so nobody noticed.

> When this first came up, about 2 years ago, I came up with the below
> plan to fix this. Nvidia was supposed to work in implementing this,
> but so far an implementation of this plan has not happened.
> 
> Note I do not have time to work on this myself. I'm posting this here
> in the hope that either Nvidia will pick this up after all; or that
> someone else can make this happen.
> 
> I'm more then happy to help answering any questions which may come up
> while implementing this; and to review the resulting patches.
>

Sorry about that - I totally forgot about this proposal. I'm still happy
to help here, although if someone else is especially eager to implement
these changes, I'm also happy to answer questions, test, review, and help
in other ways as bandwidth allows. I have some clarifying questions about
the plan - it's been some time since we talked about this, so I apologize
if I've already asked these questions and you've already answered them.
 
> 
> The plan
> ========
> 
> 1. Modify the core backlight code to allow registering a backlight-device
> for in kernel use only, disabling the registering of a class device under
> /sys/class/backlight .
> 
> 2. Add a new backlight-aggregate.c backlight driver, which exports a
> devm_backlight_aggregate_register_or_add() function. Drivers can call
> this passing in an existing backlight-device (with its sysfs interface
> disabled). This either creates a singleton /sys/class/backlight/aggregate
> device, or adds the passed in backlight to the existing singleton instance
> if it already exists.
> 
> This new driver always exposes a range of 0-255 to userspace. This acts
> as a proxie for any backlight-devices registered to be part of
> the aggregate, forwarding any brightness set calls to all backlights,
> scaled to their actual range. For reads this will report the last set
> brightness value (starting with the value of the first registered
> backlight-device).
> 
> 3. Add a new nvidia_wmi_ec_and_native type to drivers/acpi/video_detect.c
> for both DMI quirks and commandline handling.
> 

So by default both the native and GPU drivers would register a "normal"
backlight handler, and if the "both" quirk is set (or if requested via
kernel command line) they'll register with the aggregate device?

Would it make sense to make this more generic, with a parameter which
can be set via command line or quirks for which backlight devices to
aggregate? And then maybe instead of a new "nvidia_wmi_ec_and_native"
backlight type in video_detect.c, it could be called "aggregate" or
something else along those lines, used in combination with the list of
backlight types to aggregate.

Have we seen systems where both the iGPU and dGPU register their own
native handlers? I vaguely recall seeing such a system, but I do not
keep careful notes about this sort of thing, so I'm not certain. If
there are indeed such systems, then "native" might not be specific
enough, and it may be necessary to explicitly name backlight drivers
individually in order to aggregate them.

> 
> 4. Modify acpi_video_backlight_use_native() to also return true if
> the __acpi_video_get_backlight_type() call there returns the new
> acpi_backlight_nvidia_wmi_ec_and_native.

> 5. Add a new devm_backlight_device_register_native() helper which
> calls __acpi_video_get_backlight_type(true, NULL) and if that returns
> the new nvidia_wmi_ec_and_native type then registers the passed in
> backlight with the flag to not register a sysfs class interface and
> then on success calls the new devm_backlight_aggregate_register_or_add()
> with the just registered backlight device; and if the returned type
> instead is acpi_backlight_native register the passed in backlight
> normally through devm_backlight_device_register()
> 
> 5. Modify the i915 and amdgpu drivers to use the new
> devm_backlight_device_register_native() helper. Since this new helper
> checks the backlight-type itself, drop acpi_video_backlight_use_native()
> checks *if* the registration is the only thing guarded by that check.
> 
> 6. drivers/platform/x86/nvidia-wmi-ec-backlight.c to not return
> early from probe when acpi_video_get_backlight_type() returns
> the new nvidia_wmi_ec_and_native type and for that type make it
> registers its backlight with the flag to not register a sysfs class
> interface and then on success calls the new
> devm_backlight_aggregate_register_or_add().
> 

There still isn't anything tying a particular sysfs backlight interface
node to a specific display panel, right? Is there a plan to eventually
support this? How would this interact with that plan? I'm just a little
worried about designing ourselves into a corner that makes things harder
to untangle individual devices later if the need arises.

> Regards,
> 
> Hans
> 

Re: Plan to fix nvidia_wmi_ec backlight issues, help wanted

[Armin Wolf]

Am 05.05.26 um 17:51 schrieb Daniel Dadap:
> Thanks, Hans -
> 
> On Tue, May 05, 2026 at 11:52:55AM +0200, Hans de Goede wrote:
>> <resend adding pdx86 list, sorry>
>>
>> Hi All,
>>
>> A while ago Nvidia introduced a new Nvidia specific firmware method
>> for controlling the backlight on laptops with runtime switchable
>> Nvidia hybrid graphics.
>>
>> This is supported through the nvidia-wmi-ec-backlight driver, but has
>> never worked 100%.
>>
>> The new WMI firmware interface has a method to ask the firmware if
>> the backlight is controlled though the EC and this the new WMI interface
>> should be used; or if it is directly controlled by the GPU and the GPU
>> driver's native backlight support should be used.
>>
>> There are several bugs in the implementation of this on various laptops:
>>
>> 1. The method to get the backlight control source sometimes does not
>> report the correct value.
>>
>> 2. On some laptop models which method (native-gpu vs nvidia-wmi) works
>> changes at runtime, e.g. when plugging in a charger.
>>
>> Known affected laptop models/bug reports about this:
>> - Acer Predator PH315-55: needs acpi_backlight=native
>> - Dell G15 5515 with RTX 3050: *needs* acpi_backlight=native
>> - Dell G15 5515 with RTX 3060: *breaks* with acpi_backlight=native
>> - Lenovo Legion Slim 7 2021
>> - https://bugzilla.kernel.org/show_bug.cgi?id=217026
>> - https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/work_items/784
>> - https://gitlab.freedesktop.org/drm/amd/-/issues/4512
>> - https://bugzilla.suse.com/show_bug.cgi?id=1217750
> 
> I believe there were also a couple of cases where different builds of the
> same notebook (as far as DMI quirks tables could detect) would be driven
> by different methods, exacerbating problem (1) because adding a quirtk to
> fix one notebook would break other versions of the "same" notebook. (Oh,
> maybe that's the two G15 5515 bugs linked above.)
> 
>>
>> It turns out that under Windows both a WMI backlight driver and a GPU
>> native backlight driver get installed and Windows simply always calls
>> both when the backlight changes working around these kind of firmware
>> bugs.
>>
> 
> Yes, it's frustrating that so many notebooks have implementations of this
> interface that have bugs that get masked by Windows always using both of
> the interfaces. I wonder whether Windows behaves this way because bugs of
> this type are so prevalent, or if the bugs are prevalent because Windows
> always behaved that way so nobody noticed.

I suspect that both scenarios apply :(

That being said, i am asking myself if "both interfaces" also includes 
the backlight interface from the iGPU. If not then we could simply use a 
notifier to dynamically tie the WMI device to the Nvidia GPU backlight 
interface.

>> When this first came up, about 2 years ago, I came up with the below
>> plan to fix this. Nvidia was supposed to work in implementing this,
>> but so far an implementation of this plan has not happened.
>>
>> Note I do not have time to work on this myself. I'm posting this here
>> in the hope that either Nvidia will pick this up after all; or that
>> someone else can make this happen.
>>
>> I'm more then happy to help answering any questions which may come up
>> while implementing this; and to review the resulting patches.
>>
> 
> Sorry about that - I totally forgot about this proposal. I'm still happy
> to help here, although if someone else is especially eager to implement
> these changes, I'm also happy to answer questions, test, review, and help
> in other ways as bandwidth allows. I have some clarifying questions about
> the plan - it's been some time since we talked about this, so I apologize
> if I've already asked these questions and you've already answered them.
>   
>>
>> The plan
>> ========
>>
>> 1. Modify the core backlight code to allow registering a backlight-device
>> for in kernel use only, disabling the registering of a class device under
>> /sys/class/backlight .
>>
>> 2. Add a new backlight-aggregate.c backlight driver, which exports a
>> devm_backlight_aggregate_register_or_add() function. Drivers can call
>> this passing in an existing backlight-device (with its sysfs interface
>> disabled). This either creates a singleton /sys/class/backlight/aggregate
>> device, or adds the passed in backlight to the existing singleton instance
>> if it already exists.
>>
>> This new driver always exposes a range of 0-255 to userspace. This acts
>> as a proxie for any backlight-devices registered to be part of
>> the aggregate, forwarding any brightness set calls to all backlights,
>> scaled to their actual range. For reads this will report the last set
>> brightness value (starting with the value of the first registered
>> backlight-device).
>>
>> 3. Add a new nvidia_wmi_ec_and_native type to drivers/acpi/video_detect.c
>> for both DMI quirks and commandline handling.
>>
> 
> So by default both the native and GPU drivers would register a "normal"
> backlight handler, and if the "both" quirk is set (or if requested via
> kernel command line) they'll register with the aggregate device?
> 
> Would it make sense to make this more generic, with a parameter which
> can be set via command line or quirks for which backlight devices to
> aggregate? And then maybe instead of a new "nvidia_wmi_ec_and_native"
> backlight type in video_detect.c, it could be called "aggregate" or
> something else along those lines, used in combination with the list of
> backlight types to aggregate.
> 
> Have we seen systems where both the iGPU and dGPU register their own
> native handlers? I vaguely recall seeing such a system, but I do not
> keep careful notes about this sort of thing, so I'm not certain. If
> there are indeed such systems, then "native" might not be specific
> enough, and it may be necessary to explicitly name backlight drivers
> individually in order to aggregate them.
>>
>> 4. Modify acpi_video_backlight_use_native() to also return true if
>> the __acpi_video_get_backlight_type() call there returns the new
>> acpi_backlight_nvidia_wmi_ec_and_native.
> 
>> 5. Add a new devm_backlight_device_register_native() helper which
>> calls __acpi_video_get_backlight_type(true, NULL) and if that returns
>> the new nvidia_wmi_ec_and_native type then registers the passed in
>> backlight with the flag to not register a sysfs class interface and
>> then on success calls the new devm_backlight_aggregate_register_or_add()
>> with the just registered backlight device; and if the returned type
>> instead is acpi_backlight_native register the passed in backlight
>> normally through devm_backlight_device_register()
>>
>> 5. Modify the i915 and amdgpu drivers to use the new
>> devm_backlight_device_register_native() helper. Since this new helper
>> checks the backlight-type itself, drop acpi_video_backlight_use_native()
>> checks *if* the registration is the only thing guarded by that check.
>>
>> 6. drivers/platform/x86/nvidia-wmi-ec-backlight.c to not return
>> early from probe when acpi_video_get_backlight_type() returns
>> the new nvidia_wmi_ec_and_native type and for that type make it
>> registers its backlight with the flag to not register a sysfs class
>> interface and then on success calls the new
>> devm_backlight_aggregate_register_or_add().
>>
> 
> There still isn't anything tying a particular sysfs backlight interface
> node to a specific display panel, right? Is there a plan to eventually
> support this? How would this interact with that plan? I'm just a little
> worried about designing ourselves into a corner that makes things harder
> to untangle individual devices later if the need arises.

Good point. I think it would be better if the GPU drivers themself 
figure out if a given DRM connector belongs to the internal panel.
They could then register with a notifier that notifies the WMI driver 
whenever the "official" backlight interface was changed to update the EC 
state as needed.

If only the Nvidia GPU is supposed to interact with this WMI device, 
then we could implement this as a private interface inside nova/noveau. 
Otherwise we might need to come up with a more generic API.

Thanks,
Armin Wolf

>> Regards,
>>
>> Hans
>>
>