On Tue, Nov 01, 2022 at 10:52:03AM +0100, Hans de Goede wrote:
> Hi,
>
> On 10/31/22 23:09, Daniel Dadap wrote:
> > Thanks, Hans:
> >
> > On Mon, Oct 31, 2022 at 10:25:56PM +0100, Hans de Goede wrote:
> >> The Dell G15 5515 has the WMI interface (and WMI call returns) expected
> >> by the nvidia-wmi-ec-backlight interface. But the backlight class device
> >> registered by the nvidia-wmi-ec-backlight driver does not actually work.
> >>
> >> The amdgpu_bl0 native GPU backlight class device does actually work,
> >> add a backlight=native DMI quirk for this.
> >
> > I'm not certain whether you have direct access to the system, but I am
> > curious as to what mode the system is in when it exposes a non-working
> > WMI backlight interface. The expectation is that the WMI EC backlight
> > interface should only be exposed when the system is in dynamic mode
> > (different vendors may call this differeint things in the EFI setup
> > menus), and the native backlight interfaces for the GPUs, be they
> > discrete or integrated, should only be exposed when a mode that keeps
> > only one of the GPUs connected to the panel; i.e., in discrete-only mode
> > the discrete GPU should have a working native backlight interface, and
> > in integrated-only mode, or a hybrid mode which does not allow dynamic
> > mux switching, the integrated GPU should have a working native backlight
> > interface.
> >
> > For this notebook the AMD GPU would be the integrated one, so if the
> > system is *not* in dynamic switch mode, and the WMI interface is
> > reporting that the backlight should be handled by the EC, then that is
> > certainly a bug in the system, and this would be the correct workaround,
> > when the system is operating in an iGPU-only or non-dynamic hybrid mode.
> > However, if the system is switched to a dynamic mode, then this would
> > break the EC backlight, which should be the corect backlight interface
> > for that case. Another possible system bug would be if the condition
> > described in the change description occurs when the system *is* in a
> > dynamic mode, but is routing backlight control to the iGPU anyway. That
> > would be a messier bug to deal with, since it would also be necessary to
> > determine which backlight interface is functional when the display is
> > switched over to the dGPU.
> >
> > If it's not too much trouble could you (or the reporter, if you don't
> > have the system) check which backlight interfaces are exposed, and which
> > of those actually work, for each of the different hybrid GPU modes? I am
> > not certain what they would be called on the setup screen, but the
> > possible modes should be:
> >
> > * Integrated only
> > * Discrete only
> > * Hybrid, without dynamic switching
> > * Hybrid, with dynamic switching
> >
> > , or a subset thereof. Usually I would expect the minimal subset to be
> > discrete only plus one or both of the hybrid modes. Since we're not sure
> > what these are called on the setup screen it is probably best to simply
> > report the names of the mode as they are listed in the UI.
>
> Isn't the whole idea behind nvidia-wmi-ec-backlight that the backlight's
> pwm input is connected to the EC (it is sorta in the name) and then always
> is controlled by the EC independent of the mode ?
>
> At least I was under the impression that that was the whole idea?
Almost, but not quite. The idea is that the PWM is connected to and
controlled by the EC when the system is in a dynamic mux switching mode.
Then, when the display is muxed from one GPU to the other, the backlight
level remains consistent because it's not under control of whichever GPU
it happens to be connected to at the moment. If the system is not in
dynamic mux mode, then there is only ever one GPU connected for the
entire time the system is powered on, so there's no need for the EC to
act as a GPU-agnostic backlight control. Querying the WMI-wrapped ACPI
method labeled WMI_BRIGHTNESS_METHOD_SOURCE by enum wmi_brightness_method
is supposed to tell the EC backlight driver who currently owns backlight
control. The most likely possibilities for the bug here are:
1) WMI_BRIGHTNESS_METHOD_SOURCE returns WMI_BRIGHTNESS_SOURCE_EC in a
non-dynamic mux mode, instead of returning the correct value of
WMI_BRIGHTNESS_SOURCE_GPU
2) The system really is in a dynamic mux mode, but backlight control is
incorrectly routed to the GPU which is muxed to at boot time.
If we're looking at case (1), then the proposed quirk is fine, because
the display will not switch which GPU it is connected to, so whichever
native backlight driver comes online is the correct one. If it's case
(2), then the correct workaround would depend upon what happens when the
mux is switched to the other GPU. If backlight control switches to the
other GPU, then the below quirk should work under the future backlight
subsystem where there's one backlight interface per display connector,
as long as both GPU drivers register their native backlight controllers.
Userspace would have to deal with coordinating the level across switches
and scaling it, if necessary. If switching the mux does end up making
the EC backlight control like it's supposed to (possibly even after
switching back to the original muxed-at-boot GPU), then the below quirk
would break backlight control after the mux is switched.
I suppose this is all moot at the moment, because we don't actually have
support for dynamic mux switching on Linux, yet. I have a proposal for
that which I've been meaning to send out to dri-devel; I'll try to do
that soon. So in the meantime, this quirk is a "good enough" workaround.
It would be helpful to add a comment to the quirk that we will need to
figure out what the correct way to deal with this system is once dynamic
mux switching support is available.
> I will forward your email to the reporter and ask them to get
> in touch with you and then lets see from there.
>
> Regards,
>
> Hans
>
>
>
> >
> >> Cc: Daniel Dadap <ddadap@xxxxxxxxxx>
> >> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> >> ---
> >> drivers/acpi/video_detect.c | 10 ++++++++++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> >> index 841f6213b4de..88acc09773bb 100644
> >> --- a/drivers/acpi/video_detect.c
> >> +++ b/drivers/acpi/video_detect.c
> >> @@ -645,6 +645,16 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
> >> },
> >> },
> >>
> >> + /* Models which have nvidia-ec-wmi support, but should not use it. */
> >> + {
> >> + .callback = video_detect_force_native,
> >> + /* Dell G15 5515 */
> >> + .matches = {
> >> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> >> + DMI_MATCH(DMI_PRODUCT_NAME, "Dell G15 5515"),
> >> + },
> >> + },
> >> +
> >> /*
> >> * Desktops which falsely report a backlight and which our heuristics
> >> * for this do not catch.
> >> --
> >> 2.37.3
> >>
> >
>
