[REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Aly]

Hello,

The backlight control has been broken on Dell G15 5515 since 6.1, it
is always at full brightness, this is only the case in hybrid (mux)
graphics mode.

As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
nvidia_wmi_ec_backlight    16384  0
video                  61440  5
nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
wmi                    36864  7
video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor

but it is not present in /sys/class/backlight, only amdgpu_bl1 is
present which is not functional
contents of /sys/class/backlight
total 0
lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/

this is the content on 6.0.12
total 0
lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/

Distro: Endeavour OS
Kernel: 6.1.4-arch1-1
GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01

#regzbot introduced v6.1..v6.1.4

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

Hi Youssef,

On 1/9/23 17:18, Youssef Aly wrote:
> Hello,
> 
> The backlight control has been broken on Dell G15 5515 since 6.1, it
> is always at full brightness, this is only the case in hybrid (mux)
> graphics mode.
> 
> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
> nvidia_wmi_ec_backlight    16384  0
> video                  61440  5
> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
> wmi                    36864  7
> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
> 
> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
> present which is not functional
> contents of /sys/class/backlight
> total 0
> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> 
> this is the content on 6.0.12
> total 0
> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
> 
> Distro: Endeavour OS
> Kernel: 6.1.4-arch1-1
> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
> 
> #regzbot introduced v6.1..v6.1.4

Hmm, this is likely caused by:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6

Which was added because according to the reporter on their G15 5515
backlight control only works in native mode ...

I'm getting the feeling that we need to detect the BIOS setting
and use a different backlight device depending on the setting...

Daniel, any ideas?

For now can you try building a kernel with the attached patch
(which I've also just submitted upstream) and with:

acpi_backlight=nvidia_wmi_ec

added to your kernel commandline. That should work around this
for now...

Regards,

Hans

[-- Attachment #2: 0001-ACPI-video-Allow-selecting-NVidia-WMI-EC-or-Apple-GM.patch --]
[-- Type: text/x-patch, Size: 1561 bytes --]

From c2fabe40c2088ecc1c3d1500df591dede5671154 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Mon, 9 Jan 2023 19:58:38 +0100
Subject: [PATCH] ACPI: video: Allow selecting NVidia-WMI-EC or Apple GMUX
 backlight from the cmdline

The patches adding NVidia-WMI-EC and Apple GMUX backlight detection
support to acpi_video_get_backlight_type(), forgot to update
acpi_video_parse_cmdline() to allow manually selecting these from
the commandline.

Add support for these to acpi_video_parse_cmdline().

Fixes: fe7aebb40d42 ("ACPI: video: Add Nvidia WMI EC brightness control detection (v3)")
Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/video_detect.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 1b78c7434492..8a541efc5675 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -50,6 +50,10 @@ static void acpi_video_parse_cmdline(void)
 		acpi_backlight_cmdline = acpi_backlight_video;
 	if (!strcmp("native", acpi_video_backlight_string))
 		acpi_backlight_cmdline = acpi_backlight_native;
+	if (!strcmp("nvidia_wmi_ec", acpi_video_backlight_string))
+		acpi_backlight_cmdline = acpi_backlight_nvidia_wmi_ec;
+	if (!strcmp("apple_gmux", acpi_video_backlight_string))
+		acpi_backlight_cmdline = acpi_backlight_apple_gmux;
 	if (!strcmp("none", acpi_video_backlight_string))
 		acpi_backlight_cmdline = acpi_backlight_none;
 }
-- 
2.39.0

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Aly]

Hello Hans,

Ok, I'll try building with the patch you provided, and report back.

Thanks,

Youssef

On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi Youssef,
>
> On 1/9/23 17:18, Youssef Aly wrote:
> > Hello,
> >
> > The backlight control has been broken on Dell G15 5515 since 6.1, it
> > is always at full brightness, this is only the case in hybrid (mux)
> > graphics mode.
> >
> > As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
> > nvidia_wmi_ec_backlight    16384  0
> > video                  61440  5
> > nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
> > wmi                    36864  7
> > video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
> >
> > but it is not present in /sys/class/backlight, only amdgpu_bl1 is
> > present which is not functional
> > contents of /sys/class/backlight
> > total 0
> > lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
> > ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >
> > this is the content on 6.0.12
> > total 0
> > lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
> > ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> > lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
> > ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
> >
> > Distro: Endeavour OS
> > Kernel: 6.1.4-arch1-1
> > GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
> >
> > #regzbot introduced v6.1..v6.1.4
>
> Hmm, this is likely caused by:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
>
> Which was added because according to the reporter on their G15 5515
> backlight control only works in native mode ...
>
> I'm getting the feeling that we need to detect the BIOS setting
> and use a different backlight device depending on the setting...
>
> Daniel, any ideas?
>
> For now can you try building a kernel with the attached patch
> (which I've also just submitted upstream) and with:
>
> acpi_backlight=nvidia_wmi_ec
>
> added to your kernel commandline. That should work around this
> for now...
>
> Regards,
>
> Hans

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Hans de Goede]

Hi,

On 1/10/23 02:07, Youssef Aly wrote:
> Hello,
> 
> Just reporting back, building with the patch fixed the issue.

I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
the kernel commandline for the patched kernel, right ?

If you have time, can you please also check the other BIOS
(hybrid / discrete / ...) modes in the BIOS?

Based on the previous bug report, I would expect you to need
to pass "acpi_backlight=native" in at least some of the other
modes ...

Regards,

Hans



> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
>>
>> Hello Hans,
>>
>> Ok, I'll try building with the patch you provided, and report back.
>>
>> Thanks,
>>
>> Youssef
>>
>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> Hi Youssef,
>>>
>>> On 1/9/23 17:18, Youssef Aly wrote:
>>>> Hello,
>>>>
>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
>>>> is always at full brightness, this is only the case in hybrid (mux)
>>>> graphics mode.
>>>>
>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
>>>> nvidia_wmi_ec_backlight    16384  0
>>>> video                  61440  5
>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
>>>> wmi                    36864  7
>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
>>>>
>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
>>>> present which is not functional
>>>> contents of /sys/class/backlight
>>>> total 0
>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>
>>>> this is the content on 6.0.12
>>>> total 0
>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
>>>>
>>>> Distro: Endeavour OS
>>>> Kernel: 6.1.4-arch1-1
>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
>>>>
>>>> #regzbot introduced v6.1..v6.1.4
>>>
>>> Hmm, this is likely caused by:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
>>>
>>> Which was added because according to the reporter on their G15 5515
>>> backlight control only works in native mode ...
>>>
>>> I'm getting the feeling that we need to detect the BIOS setting
>>> and use a different backlight device depending on the setting...
>>>
>>> Daniel, any ideas?
>>>
>>> For now can you try building a kernel with the attached patch
>>> (which I've also just submitted upstream) and with:
>>>
>>> acpi_backlight=nvidia_wmi_ec
>>>
>>> added to your kernel commandline. That should work around this
>>> for now...
>>>
>>> Regards,
>>>
>>> Hans
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Hans de Goede]

Hi,

On 1/10/23 16:19, Youssef Aly wrote:
> Hi Hans,
> 
> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> the kernel commandline for the patched kernel, it doesn't work without it.
> 
> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> the modes with "acpi_backlight=nvidia_wmi_ec" and
> "acpi_backlight=native" using the patched kernel (v6.1.4):
> 
> Hybrid:
> "acpi_backlight=native": Does not work, /sys/class/backlight contains
> amdgpu_bl1.
> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> 
> Discrete:
> "acpi_backlight=native": Works but when brightness from 0-10 is the
> same as 0-100, for example 10 is full brightness like 100, 8 is the
> same as 80, etc... ,
> /sys/class/backlight contains nvidia_0.
> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> contains nvidia_wmi_ec_backlight.

Thank you for testing!

Ok so it seems there are 2 issues at play here:

1. Depending on the BIOS setting we need to use either native (discrete mode)
   or nvidia_wmi_ec (hybrid mode)

2. There is a bug in the nvidia binary drivers backlight control in native
   mode on this system causing the range to be wrong

Daniel, we really need help from NVidia with fixing 1. can you see if
there is a way to check the BIOS setting/mode from inside the kernel ?

Regards,

Hans

p.s.

Youssef, for your next email please use reply to all. You keep dropping
Daniel and the regressions-list from the To/Cc, using reply-to-all should
keep these in the To/Cc.




> On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 1/10/23 02:07, Youssef Aly wrote:
>>> Hello,
>>>
>>> Just reporting back, building with the patch fixed the issue.
>>
>> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
>> the kernel commandline for the patched kernel, right ?
>>
>> If you have time, can you please also check the other BIOS
>> (hybrid / discrete / ...) modes in the BIOS?
>>
>> Based on the previous bug report, I would expect you to need
>> to pass "acpi_backlight=native" in at least some of the other
>> modes ...
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
>>>>
>>>> Hello Hans,
>>>>
>>>> Ok, I'll try building with the patch you provided, and report back.
>>>>
>>>> Thanks,
>>>>
>>>> Youssef
>>>>
>>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>
>>>>> Hi Youssef,
>>>>>
>>>>> On 1/9/23 17:18, Youssef Aly wrote:
>>>>>> Hello,
>>>>>>
>>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
>>>>>> is always at full brightness, this is only the case in hybrid (mux)
>>>>>> graphics mode.
>>>>>>
>>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
>>>>>> nvidia_wmi_ec_backlight    16384  0
>>>>>> video                  61440  5
>>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
>>>>>> wmi                    36864  7
>>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
>>>>>>
>>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
>>>>>> present which is not functional
>>>>>> contents of /sys/class/backlight
>>>>>> total 0
>>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>>
>>>>>> this is the content on 6.0.12
>>>>>> total 0
>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
>>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
>>>>>>
>>>>>> Distro: Endeavour OS
>>>>>> Kernel: 6.1.4-arch1-1
>>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
>>>>>>
>>>>>> #regzbot introduced v6.1..v6.1.4
>>>>>
>>>>> Hmm, this is likely caused by:
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
>>>>>
>>>>> Which was added because according to the reporter on their G15 5515
>>>>> backlight control only works in native mode ...
>>>>>
>>>>> I'm getting the feeling that we need to detect the BIOS setting
>>>>> and use a different backlight device depending on the setting...
>>>>>
>>>>> Daniel, any ideas?
>>>>>
>>>>> For now can you try building a kernel with the attached patch
>>>>> (which I've also just submitted upstream) and with:
>>>>>
>>>>> acpi_backlight=nvidia_wmi_ec
>>>>>
>>>>> added to your kernel commandline. That should work around this
>>>>> for now...
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans
>>>
>>
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Aly]

Hi,

Happy to test anytime, thanks for the p.s.

I would like to mention something probably unrelated, but thought I
would mention it just in case. The backlight control has been broken
on windows 10/11 on hybrid mode since Nvidia driver 526.47, this issue
only affects the 3060 models (They have a mux switch). This is a link
to the forum discussing the issue
https://www.dell.com/community/Inspiron/G15-5515-Ryzen-Edition-Display-Brightness-Slider-not-Working/m-p/8301504#M154120
.

Hope that is of some help.

Thanks,

Youssef



On Tue, 10 Jan 2023 at 17:28, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 1/10/23 16:19, Youssef Aly wrote:
> > Hi Hans,
> >
> > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > the kernel commandline for the patched kernel, it doesn't work without it.
> >
> > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > "acpi_backlight=native" using the patched kernel (v6.1.4):
> >
> > Hybrid:
> > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > amdgpu_bl1.
> > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> >
> > Discrete:
> > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > same as 80, etc... ,
> > /sys/class/backlight contains nvidia_0.
> > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > contains nvidia_wmi_ec_backlight.
>
> Thank you for testing!
>
> Ok so it seems there are 2 issues at play here:
>
> 1. Depending on the BIOS setting we need to use either native (discrete mode)
>    or nvidia_wmi_ec (hybrid mode)
>
> 2. There is a bug in the nvidia binary drivers backlight control in native
>    mode on this system causing the range to be wrong
>
> Daniel, we really need help from NVidia with fixing 1. can you see if
> there is a way to check the BIOS setting/mode from inside the kernel ?
>
> Regards,
>
> Hans
>
> p.s.
>
> Youssef, for your next email please use reply to all. You keep dropping
> Daniel and the regressions-list from the To/Cc, using reply-to-all should
> keep these in the To/Cc.
>
>
>
>
> > On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> On 1/10/23 02:07, Youssef Aly wrote:
> >>> Hello,
> >>>
> >>> Just reporting back, building with the patch fixed the issue.
> >>
> >> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
> >> the kernel commandline for the patched kernel, right ?
> >>
> >> If you have time, can you please also check the other BIOS
> >> (hybrid / discrete / ...) modes in the BIOS?
> >>
> >> Based on the previous bug report, I would expect you to need
> >> to pass "acpi_backlight=native" in at least some of the other
> >> modes ...
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>
> >>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
> >>>>
> >>>> Hello Hans,
> >>>>
> >>>> Ok, I'll try building with the patch you provided, and report back.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Youssef
> >>>>
> >>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>
> >>>>> Hi Youssef,
> >>>>>
> >>>>> On 1/9/23 17:18, Youssef Aly wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
> >>>>>> is always at full brightness, this is only the case in hybrid (mux)
> >>>>>> graphics mode.
> >>>>>>
> >>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
> >>>>>> nvidia_wmi_ec_backlight    16384  0
> >>>>>> video                  61440  5
> >>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
> >>>>>> wmi                    36864  7
> >>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
> >>>>>>
> >>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
> >>>>>> present which is not functional
> >>>>>> contents of /sys/class/backlight
> >>>>>> total 0
> >>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
> >>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>>
> >>>>>> this is the content on 6.0.12
> >>>>>> total 0
> >>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
> >>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
> >>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
> >>>>>>
> >>>>>> Distro: Endeavour OS
> >>>>>> Kernel: 6.1.4-arch1-1
> >>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
> >>>>>>
> >>>>>> #regzbot introduced v6.1..v6.1.4
> >>>>>
> >>>>> Hmm, this is likely caused by:
> >>>>>
> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
> >>>>>
> >>>>> Which was added because according to the reporter on their G15 5515
> >>>>> backlight control only works in native mode ...
> >>>>>
> >>>>> I'm getting the feeling that we need to detect the BIOS setting
> >>>>> and use a different backlight device depending on the setting...
> >>>>>
> >>>>> Daniel, any ideas?
> >>>>>
> >>>>> For now can you try building a kernel with the attached patch
> >>>>> (which I've also just submitted upstream) and with:
> >>>>>
> >>>>> acpi_backlight=nvidia_wmi_ec
> >>>>>
> >>>>> added to your kernel commandline. That should work around this
> >>>>> for now...
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Hans
> >>>
> >>
> >
>

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 1/10/23 16:19, Youssef Aly wrote:
> > Hi Hans,
> > 
> > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > the kernel commandline for the patched kernel, it doesn't work without it.
> > 
> > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > 
> > Hybrid:
> > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > amdgpu_bl1.
> > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > 
> > Discrete:
> > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > same as 80, etc... ,
> > /sys/class/backlight contains nvidia_0.
> > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > contains nvidia_wmi_ec_backlight.
> 
> Thank you for testing!
> 
> Ok so it seems there are 2 issues at play here:
> 
> 1. Depending on the BIOS setting we need to use either native (discrete mode)
>    or nvidia_wmi_ec (hybrid mode)
> 
> 2. There is a bug in the nvidia binary drivers backlight control in native
>    mode on this system causing the range to be wrong
> 
> Daniel, we really need help from NVidia with fixing 1. can you see if
> there is a way to check the BIOS setting/mode from inside the kernel ?

Yes, the ACPI MXDM method should be able to do this. However, querying
WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
determine whether the backlight is supposed to be EC-driven, since there
are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
be orthogonal to whether or not the EC driver should be used. It sounds
like the BIOS is possibly reporting a wrong value for that query.

I guess we could wire up a quirk that checks MXDM and overrides the
WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
mux operation mode. Then that quirk could be applied to this system.
I can put together a patch for that.

As for the native range bug, that does sound like a scaling issue. I'll
take a look at how the NVIDIA driver determines the range of possible
backlight values and see if Ican find an obvious way that might fail on
a particular system.
 
> Regards,
> 
> Hans
> 
> p.s.
> 
> Youssef, for your next email please use reply to all. You keep dropping
> Daniel and the regressions-list from the To/Cc, using reply-to-all should
> keep these in the To/Cc.
> 
> 
> 
> 
> > On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> On 1/10/23 02:07, Youssef Aly wrote:
> >>> Hello,
> >>>
> >>> Just reporting back, building with the patch fixed the issue.
> >>
> >> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
> >> the kernel commandline for the patched kernel, right ?
> >>
> >> If you have time, can you please also check the other BIOS
> >> (hybrid / discrete / ...) modes in the BIOS?
> >>
> >> Based on the previous bug report, I would expect you to need
> >> to pass "acpi_backlight=native" in at least some of the other
> >> modes ...
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>
> >>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
> >>>>
> >>>> Hello Hans,
> >>>>
> >>>> Ok, I'll try building with the patch you provided, and report back.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Youssef
> >>>>
> >>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>
> >>>>> Hi Youssef,
> >>>>>
> >>>>> On 1/9/23 17:18, Youssef Aly wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
> >>>>>> is always at full brightness, this is only the case in hybrid (mux)
> >>>>>> graphics mode.
> >>>>>>
> >>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
> >>>>>> nvidia_wmi_ec_backlight    16384  0
> >>>>>> video                  61440  5
> >>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
> >>>>>> wmi                    36864  7
> >>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
> >>>>>>
> >>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
> >>>>>> present which is not functional
> >>>>>> contents of /sys/class/backlight
> >>>>>> total 0
> >>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
> >>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>>
> >>>>>> this is the content on 6.0.12
> >>>>>> total 0
> >>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
> >>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
> >>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
> >>>>>>
> >>>>>> Distro: Endeavour OS
> >>>>>> Kernel: 6.1.4-arch1-1
> >>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
> >>>>>>
> >>>>>> #regzbot introduced v6.1..v6.1.4
> >>>>>
> >>>>> Hmm, this is likely caused by:
> >>>>>
> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
> >>>>>
> >>>>> Which was added because according to the reporter on their G15 5515
> >>>>> backlight control only works in native mode ...
> >>>>>
> >>>>> I'm getting the feeling that we need to detect the BIOS setting
> >>>>> and use a different backlight device depending on the setting...
> >>>>>
> >>>>> Daniel, any ideas?
> >>>>>
> >>>>> For now can you try building a kernel with the attached patch
> >>>>> (which I've also just submitted upstream) and with:
> >>>>>
> >>>>> acpi_backlight=nvidia_wmi_ec
> >>>>>
> >>>>> added to your kernel commandline. That should work around this
> >>>>> for now...
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Hans
> >>>
> >>
> > 
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

On Tue, Jan 10, 2023 at 07:03:02PM +0200, Youssef Aly wrote:
> Hi,
> 
> Happy to test anytime, thanks for the p.s.
> 
> I would like to mention something probably unrelated, but thought I
> would mention it just in case. The backlight control has been broken
> on windows 10/11 on hybrid mode since Nvidia driver 526.47, this issue
> only affects the 3060 models (They have a mux switch). This is a link
> to the forum discussing the issue
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dell.com%2Fcommunity%2FInspiron%2FG15-5515-Ryzen-Edition-Display-Brightness-Slider-not-Working%2Fm-p%2F8301504%23M154120&data=05%7C01%7Cddadap%40nvidia.com%7Cc5ba4337bec048cc9ec908daf32c9029%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638089669973715824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A7zkgMfX1Vbucho27pQSrW6dgIULEbIsFeEpekA9IfQ%3D&reserved=0
> .
> 
> Hope that is of some help.


Thanks, Youssef. Knowing that this is also broken on Windows will help.
 
> Thanks,
> 
> Youssef
> 
> 
> 
> On Tue, 10 Jan 2023 at 17:28, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> > Hi,
> >
> > On 1/10/23 16:19, Youssef Aly wrote:
> > > Hi Hans,
> > >
> > > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > the kernel commandline for the patched kernel, it doesn't work without it.
> > >
> > > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > >
> > > Hybrid:
> > > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > amdgpu_bl1.
> > > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > >
> > > Discrete:
> > > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > same as 80, etc... ,
> > > /sys/class/backlight contains nvidia_0.
> > > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > contains nvidia_wmi_ec_backlight.
> >
> > Thank you for testing!
> >
> > Ok so it seems there are 2 issues at play here:
> >
> > 1. Depending on the BIOS setting we need to use either native (discrete mode)
> >    or nvidia_wmi_ec (hybrid mode)
> >
> > 2. There is a bug in the nvidia binary drivers backlight control in native
> >    mode on this system causing the range to be wrong
> >
> > Daniel, we really need help from NVidia with fixing 1. can you see if
> > there is a way to check the BIOS setting/mode from inside the kernel ?
> >
> > Regards,
> >
> > Hans
> >
> > p.s.
> >
> > Youssef, for your next email please use reply to all. You keep dropping
> > Daniel and the regressions-list from the To/Cc, using reply-to-all should
> > keep these in the To/Cc.
> >
> >
> >
> >
> > > On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 1/10/23 02:07, Youssef Aly wrote:
> > >>> Hello,
> > >>>
> > >>> Just reporting back, building with the patch fixed the issue.
> > >>
> > >> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
> > >> the kernel commandline for the patched kernel, right ?
> > >>
> > >> If you have time, can you please also check the other BIOS
> > >> (hybrid / discrete / ...) modes in the BIOS?
> > >>
> > >> Based on the previous bug report, I would expect you to need
> > >> to pass "acpi_backlight=native" in at least some of the other
> > >> modes ...
> > >>
> > >> Regards,
> > >>
> > >> Hans
> > >>
> > >>
> > >>
> > >>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
> > >>>>
> > >>>> Hello Hans,
> > >>>>
> > >>>> Ok, I'll try building with the patch you provided, and report back.
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Youssef
> > >>>>
> > >>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
> > >>>>>
> > >>>>> Hi Youssef,
> > >>>>>
> > >>>>> On 1/9/23 17:18, Youssef Aly wrote:
> > >>>>>> Hello,
> > >>>>>>
> > >>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
> > >>>>>> is always at full brightness, this is only the case in hybrid (mux)
> > >>>>>> graphics mode.
> > >>>>>>
> > >>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
> > >>>>>> nvidia_wmi_ec_backlight    16384  0
> > >>>>>> video                  61440  5
> > >>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
> > >>>>>> wmi                    36864  7
> > >>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
> > >>>>>>
> > >>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
> > >>>>>> present which is not functional
> > >>>>>> contents of /sys/class/backlight
> > >>>>>> total 0
> > >>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
> > >>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> > >>>>>>
> > >>>>>> this is the content on 6.0.12
> > >>>>>> total 0
> > >>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
> > >>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> > >>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
> > >>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
> > >>>>>>
> > >>>>>> Distro: Endeavour OS
> > >>>>>> Kernel: 6.1.4-arch1-1
> > >>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
> > >>>>>>
> > >>>>>> #regzbot introduced v6.1..v6.1.4
> > >>>>>
> > >>>>> Hmm, this is likely caused by:
> > >>>>>
> > >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3Df46acc1efd4b5846de9fa05f966e504f328f34a6&data=05%7C01%7Cddadap%40nvidia.com%7Cc5ba4337bec048cc9ec908daf32c9029%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638089669973715824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uWiblfqPL%2BrX9MmIGbzTyFTAkcdD1KXT2SSFxWKJ01M%3D&reserved=0
> > >>>>>
> > >>>>> Which was added because according to the reporter on their G15 5515
> > >>>>> backlight control only works in native mode ...
> > >>>>>
> > >>>>> I'm getting the feeling that we need to detect the BIOS setting
> > >>>>> and use a different backlight device depending on the setting...
> > >>>>>
> > >>>>> Daniel, any ideas?
> > >>>>>
> > >>>>> For now can you try building a kernel with the attached patch
> > >>>>> (which I've also just submitted upstream) and with:
> > >>>>>
> > >>>>> acpi_backlight=nvidia_wmi_ec
> > >>>>>
> > >>>>> added to your kernel commandline. That should work around this
> > >>>>> for now...
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> Hans
> > >>>
> > >>
> > >
> >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 7884 bytes --]

Hi,

On 1/11/23 01:40, Daniel Dadap wrote:
> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 1/10/23 16:19, Youssef Aly wrote:
>>> Hi Hans,
>>>
>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>>> the kernel commandline for the patched kernel, it doesn't work without it.
>>>
>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>>>
>>> Hybrid:
>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
>>> amdgpu_bl1.
>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>>>
>>> Discrete:
>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
>>> same as 80, etc... ,
>>> /sys/class/backlight contains nvidia_0.
>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
>>> contains nvidia_wmi_ec_backlight.
>>
>> Thank you for testing!
>>
>> Ok so it seems there are 2 issues at play here:
>>
>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
>>    or nvidia_wmi_ec (hybrid mode)
>>
>> 2. There is a bug in the nvidia binary drivers backlight control in native
>>    mode on this system causing the range to be wrong
>>
>> Daniel, we really need help from NVidia with fixing 1. can you see if
>> there is a way to check the BIOS setting/mode from inside the kernel ?
> 
> Yes, the ACPI MXDM method should be able to do this. However, querying
> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> determine whether the backlight is supposed to be EC-driven, since there
> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> be orthogonal to whether or not the EC driver should be used. It sounds
> like the BIOS is possibly reporting a wrong value for that query.
> 
> I guess we could wire up a quirk that checks MXDM and overrides the
> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> mux operation mode. Then that quirk could be applied to this system.
> I can put together a patch for that.

If you can write a patch for this that would be great, thank you,
but I think we first need to root-cause this better:

Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
to always use the native backlight. So I've gone back to the original email
thread which lead to me adding that quirk.

We (I forwarded a mail from you to the reporter this was not on the list)
did ask to test with different BIOS settings their to and the reporter's
reply was:

"Daniel wanted me to check different GPU modes, but my BIOS has no options
for GPU. It's always in hybrid mode with PRIME render offload."

And perhaps even more interesting in their case with acpi_backlight=native
to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
in Youssef's case when running in discrete mode there is an nvidia backlight
device and in Youssef's case the amdgpu_bl# device never works.

The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)

While the dGPU can be one of:
NVIDIA GeForce RTX 3060
NVIDIA GeForce GTX 3050 Ti
NVIDIA GeForce GTX 3050

I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
be relevant to the model with the 3060 and that nvidia-wmi-ec should
maybe not load at all on the model with the 3050 versions.

Maybe the Windows Nvidia drivers only even try to use the WMI EC
interface with certain generations of GPUs ?

Daniel might that be what is going on here ?


Youssef, can you try/test 2 things for us please? :

1. Provide the output of running "lspci -nn"

2. Try a kernel with the attached patch (can be applied on top
   of the previous patch). This removes the quirk, so that we
   can let the nvidia_wmi_ec auto-detect code do its thing,
   because maybe it does work on your model G15 5515.
   When testing this you should *not* have any acpi_backlight=xxx
   argument on your kernel commandline.

> As for the native range bug, that does sound like a scaling issue. I'll
> take a look at how the NVIDIA driver determines the range of possible
> backlight values and see if Ican find an obvious way that might fail on
> a particular system.

Ok.

Regards,

Hans



>>> On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 1/10/23 02:07, Youssef Aly wrote:
>>>>> Hello,
>>>>>
>>>>> Just reporting back, building with the patch fixed the issue.
>>>>
>>>> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
>>>> the kernel commandline for the patched kernel, right ?
>>>>
>>>> If you have time, can you please also check the other BIOS
>>>> (hybrid / discrete / ...) modes in the BIOS?
>>>>
>>>> Based on the previous bug report, I would expect you to need
>>>> to pass "acpi_backlight=native" in at least some of the other
>>>> modes ...
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>>
>>>>
>>>>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
>>>>>>
>>>>>> Hello Hans,
>>>>>>
>>>>>> Ok, I'll try building with the patch you provided, and report back.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Youssef
>>>>>>
>>>>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>
>>>>>>> Hi Youssef,
>>>>>>>
>>>>>>> On 1/9/23 17:18, Youssef Aly wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
>>>>>>>> is always at full brightness, this is only the case in hybrid (mux)
>>>>>>>> graphics mode.
>>>>>>>>
>>>>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
>>>>>>>> nvidia_wmi_ec_backlight    16384  0
>>>>>>>> video                  61440  5
>>>>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
>>>>>>>> wmi                    36864  7
>>>>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
>>>>>>>>
>>>>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
>>>>>>>> present which is not functional
>>>>>>>> contents of /sys/class/backlight
>>>>>>>> total 0
>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>>>>
>>>>>>>> this is the content on 6.0.12
>>>>>>>> total 0
>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
>>>>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
>>>>>>>>
>>>>>>>> Distro: Endeavour OS
>>>>>>>> Kernel: 6.1.4-arch1-1
>>>>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
>>>>>>>>
>>>>>>>> #regzbot introduced v6.1..v6.1.4
>>>>>>>
>>>>>>> Hmm, this is likely caused by:
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
>>>>>>>
>>>>>>> Which was added because according to the reporter on their G15 5515
>>>>>>> backlight control only works in native mode ...
>>>>>>>
>>>>>>> I'm getting the feeling that we need to detect the BIOS setting
>>>>>>> and use a different backlight device depending on the setting...
>>>>>>>
>>>>>>> Daniel, any ideas?
>>>>>>>
>>>>>>> For now can you try building a kernel with the attached patch
>>>>>>> (which I've also just submitted upstream) and with:
>>>>>>>
>>>>>>> acpi_backlight=nvidia_wmi_ec
>>>>>>>
>>>>>>> added to your kernel commandline. That should work around this
>>>>>>> for now...
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Hans
>>>>>
>>>>
>>>
>>
> 

[-- Attachment #2: 0001-ACPI-video-Drop-DMI-quirk-for-Dell-G15-5515.patch --]
[-- Type: text/x-patch, Size: 1397 bytes --]

From 814f66124e524b5128af7a2483eb68f66c158b0d Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 11 Jan 2023 10:48:00 +0100
Subject: [PATCH] ACPI: video: Drop DMI quirk for Dell G15 5515

Forcing the use of native causes issues on some variants
of the Dell G15 5515.

FIXME: we first need a way to ensure native is used on models
where we do need it before dropping this.

FIXME: Add more details once proper fix is available.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/acpi/video_detect.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 8a541efc5675..d4edd64dcc2f 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -690,20 +690,6 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
 		},
 	},
 
-	/*
-	 * Models which have nvidia-ec-wmi support, but should not use it.
-	 * Note this indicates a likely firmware bug on these models and should
-	 * be revisited if/when Linux gets support for dynamic mux mode.
-	 */
-	{
-	 .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.39.0

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Aly]

Hello,

Testing with no "acpi_backlight" in the kernel commandline. Hybrid
mode works, "nvidia_wmi_ec_backlight" is used. Discrete mode also
works with the range issue mentioned earlier, "nvidia_0" is used.

The output of "lspci -nn":

00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne Root Complex [1022:1630]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne IOMMU [1022:1631]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir
PCIe Dummy Host Bridge [1022:1632]
00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir
PCIe GPP Bridge [1022:1633]
00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne PCIe GPP Bridge [1022:1634]
00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne PCIe GPP Bridge [1022:1634]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir
PCIe Dummy Host Bridge [1022:1632]
00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne PCIe GPP Bridge [1022:1634]
00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne PCIe GPP Bridge [1022:1634]
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir
PCIe Dummy Host Bridge [1022:1632]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir
Internal PCIe GPP Bridge to Bus [1022:1635]
00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir
Internal PCIe GPP Bridge to Bus [1022:1635]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:790b] (rev 51)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC
Bridge [1022:790e] (rev 51)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 0 [1022:166a]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 1 [1022:166b]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 2 [1022:166c]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 3 [1022:166d]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 4 [1022:166e]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 5 [1022:166f]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 6 [1022:1670]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Cezanne
Data Fabric; Function 7 [1022:1671]
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M
[GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GA106 High Definition
Audio Controller [10de:228e] (rev a1)
02:00.0 Non-Volatile memory controller [0108]: SK hynix Gold P31/PC711
NVMe Solid State Drive [1c5c:174a]
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8125 2.5GbE Controller [10ec:8125] (rev 05)
04:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200
[8086:2723] (rev 1a)
05:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co
Ltd NVMe SSD Controller 980 [144d:a809]
- Hybrid: 06:00.0 VGA compatible controller [0300]: Advanced Micro
Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega
Mobile Series] [1002:1638] (rev c5)
- Discrete: 06:00.0 Non-Essential Instrumentation [1300]: Advanced
Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function
[1022:145a] (rev c5)
06:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc.
[AMD] Family 17h (Models 10h-1fh) Platform Security Processor
[1022:15df]
06:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne USB 3.1 [1022:1639]
06:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD]
Renoir/Cezanne USB 3.1 [1022:1639]
06:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc.
[AMD] ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2] (rev 01)
06:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family
17h/19h HD Audio Controller [1022:15e3]
07:00.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH
SATA Controller [AHCI mode] [1022:7901] (rev 81)
07:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH
SATA Controller [AHCI mode] [1022:7901] (rev 81)

Regards,

Youssef





On Wed, 11 Jan 2023 at 11:52, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 1/11/23 01:40, Daniel Dadap wrote:
> > On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 1/10/23 16:19, Youssef Aly wrote:
> >>> Hi Hans,
> >>>
> >>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> >>> the kernel commandline for the patched kernel, it doesn't work without it.
> >>>
> >>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> >>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> >>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> >>>
> >>> Hybrid:
> >>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
> >>> amdgpu_bl1.
> >>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> >>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> >>>
> >>> Discrete:
> >>> "acpi_backlight=native": Works but when brightness from 0-10 is the
> >>> same as 0-100, for example 10 is full brightness like 100, 8 is the
> >>> same as 80, etc... ,
> >>> /sys/class/backlight contains nvidia_0.
> >>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> >>> contains nvidia_wmi_ec_backlight.
> >>
> >> Thank you for testing!
> >>
> >> Ok so it seems there are 2 issues at play here:
> >>
> >> 1. Depending on the BIOS setting we need to use either native (discrete mode)
> >>    or nvidia_wmi_ec (hybrid mode)
> >>
> >> 2. There is a bug in the nvidia binary drivers backlight control in native
> >>    mode on this system causing the range to be wrong
> >>
> >> Daniel, we really need help from NVidia with fixing 1. can you see if
> >> there is a way to check the BIOS setting/mode from inside the kernel ?
> >
> > Yes, the ACPI MXDM method should be able to do this. However, querying
> > WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > determine whether the backlight is supposed to be EC-driven, since there
> > are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > be orthogonal to whether or not the EC driver should be used. It sounds
> > like the BIOS is possibly reporting a wrong value for that query.
> >
> > I guess we could wire up a quirk that checks MXDM and overrides the
> > WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > mux operation mode. Then that quirk could be applied to this system.
> > I can put together a patch for that.
>
> If you can write a patch for this that would be great, thank you,
> but I think we first need to root-cause this better:
>
> Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> to always use the native backlight. So I've gone back to the original email
> thread which lead to me adding that quirk.
>
> We (I forwarded a mail from you to the reporter this was not on the list)
> did ask to test with different BIOS settings their to and the reporter's
> reply was:
>
> "Daniel wanted me to check different GPU modes, but my BIOS has no options
> for GPU. It's always in hybrid mode with PRIME render offload."
>
> And perhaps even more interesting in their case with acpi_backlight=native
> to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> in Youssef's case when running in discrete mode there is an nvidia backlight
> device and in Youssef's case the amdgpu_bl# device never works.
>
> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
>
> While the dGPU can be one of:
> NVIDIA GeForce RTX 3060
> NVIDIA GeForce GTX 3050 Ti
> NVIDIA GeForce GTX 3050
>
> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> be relevant to the model with the 3060 and that nvidia-wmi-ec should
> maybe not load at all on the model with the 3050 versions.
>
> Maybe the Windows Nvidia drivers only even try to use the WMI EC
> interface with certain generations of GPUs ?
>
> Daniel might that be what is going on here ?
>
>
> Youssef, can you try/test 2 things for us please? :
>
> 1. Provide the output of running "lspci -nn"
>
> 2. Try a kernel with the attached patch (can be applied on top
>    of the previous patch). This removes the quirk, so that we
>    can let the nvidia_wmi_ec auto-detect code do its thing,
>    because maybe it does work on your model G15 5515.
>    When testing this you should *not* have any acpi_backlight=xxx
>    argument on your kernel commandline.
>
> > As for the native range bug, that does sound like a scaling issue. I'll
> > take a look at how the NVIDIA driver determines the range of possible
> > backlight values and see if Ican find an obvious way that might fail on
> > a particular system.
>
> Ok.
>
> Regards,
>
> Hans
>
>
>
> >>> On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 1/10/23 02:07, Youssef Aly wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Just reporting back, building with the patch fixed the issue.
> >>>>
> >>>> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
> >>>> the kernel commandline for the patched kernel, right ?
> >>>>
> >>>> If you have time, can you please also check the other BIOS
> >>>> (hybrid / discrete / ...) modes in the BIOS?
> >>>>
> >>>> Based on the previous bug report, I would expect you to need
> >>>> to pass "acpi_backlight=native" in at least some of the other
> >>>> modes ...
> >>>>
> >>>> Regards,
> >>>>
> >>>> Hans
> >>>>
> >>>>
> >>>>
> >>>>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
> >>>>>>
> >>>>>> Hello Hans,
> >>>>>>
> >>>>>> Ok, I'll try building with the patch you provided, and report back.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Youssef
> >>>>>>
> >>>>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>>>
> >>>>>>> Hi Youssef,
> >>>>>>>
> >>>>>>> On 1/9/23 17:18, Youssef Aly wrote:
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
> >>>>>>>> is always at full brightness, this is only the case in hybrid (mux)
> >>>>>>>> graphics mode.
> >>>>>>>>
> >>>>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
> >>>>>>>> nvidia_wmi_ec_backlight    16384  0
> >>>>>>>> video                  61440  5
> >>>>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
> >>>>>>>> wmi                    36864  7
> >>>>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
> >>>>>>>>
> >>>>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
> >>>>>>>> present which is not functional
> >>>>>>>> contents of /sys/class/backlight
> >>>>>>>> total 0
> >>>>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
> >>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>>>>
> >>>>>>>> this is the content on 6.0.12
> >>>>>>>> total 0
> >>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
> >>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
> >>>>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
> >>>>>>>>
> >>>>>>>> Distro: Endeavour OS
> >>>>>>>> Kernel: 6.1.4-arch1-1
> >>>>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
> >>>>>>>>
> >>>>>>>> #regzbot introduced v6.1..v6.1.4
> >>>>>>>
> >>>>>>> Hmm, this is likely caused by:
> >>>>>>>
> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
> >>>>>>>
> >>>>>>> Which was added because according to the reporter on their G15 5515
> >>>>>>> backlight control only works in native mode ...
> >>>>>>>
> >>>>>>> I'm getting the feeling that we need to detect the BIOS setting
> >>>>>>> and use a different backlight device depending on the setting...
> >>>>>>>
> >>>>>>> Daniel, any ideas?
> >>>>>>>
> >>>>>>> For now can you try building a kernel with the attached patch
> >>>>>>> (which I've also just submitted upstream) and with:
> >>>>>>>
> >>>>>>> acpi_backlight=nvidia_wmi_ec
> >>>>>>>
> >>>>>>> added to your kernel commandline. That should work around this
> >>>>>>> for now...
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> Hans
> >>>>>
> >>>>
> >>>
> >>
> >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Hans de Goede]

Hi,

On 1/11/23 11:42, Youssef Aly wrote:
> Hello,
> 
> Testing with no "acpi_backlight" in the kernel commandline. Hybrid
> mode works, "nvidia_wmi_ec_backlight" is used. Discrete mode also
> works with the range issue mentioned earlier, "nvidia_0" is used.

Great so without the quirk for you everything works, and from
your lspci output I see you have a GTX 3060:

> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M
> [GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1)

I suspect that the reporter for who the quirk was added has a 3050
and that to fix this we need to ignore nvidia-wmi-ec support
on laptops with a 3050.

I'm waiting for the report for who the quirk was added to provide
lspci output on their laptop. I'll report the results of that
once I have them.

Daniel, 2 questions:

1. Can you confirm that nvidia-wmi-ec should not be used with
the 3050 (mobile) GPU generation ?

2. Any nice and clean ideas for checking for the presence
of a 3050 for the drivers/acpi/video_detect.c code ?
Note I think it is probably better to check for a 3050 (variant)
then for the newer models since the newer models is going to
be an ever growing list of models.

Regards,

Hans







> On Wed, 11 Jan 2023 at 11:52, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 1/11/23 01:40, Daniel Dadap wrote:
>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 1/10/23 16:19, Youssef Aly wrote:
>>>>> Hi Hans,
>>>>>
>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>>>>> the kernel commandline for the patched kernel, it doesn't work without it.
>>>>>
>>>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>>>>>
>>>>> Hybrid:
>>>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
>>>>> amdgpu_bl1.
>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>>>>>
>>>>> Discrete:
>>>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
>>>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
>>>>> same as 80, etc... ,
>>>>> /sys/class/backlight contains nvidia_0.
>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
>>>>> contains nvidia_wmi_ec_backlight.
>>>>
>>>> Thank you for testing!
>>>>
>>>> Ok so it seems there are 2 issues at play here:
>>>>
>>>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
>>>>    or nvidia_wmi_ec (hybrid mode)
>>>>
>>>> 2. There is a bug in the nvidia binary drivers backlight control in native
>>>>    mode on this system causing the range to be wrong
>>>>
>>>> Daniel, we really need help from NVidia with fixing 1. can you see if
>>>> there is a way to check the BIOS setting/mode from inside the kernel ?
>>>
>>> Yes, the ACPI MXDM method should be able to do this. However, querying
>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
>>> determine whether the backlight is supposed to be EC-driven, since there
>>> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
>>> be orthogonal to whether or not the EC driver should be used. It sounds
>>> like the BIOS is possibly reporting a wrong value for that query.
>>>
>>> I guess we could wire up a quirk that checks MXDM and overrides the
>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
>>> mux operation mode. Then that quirk could be applied to this system.
>>> I can put together a patch for that.
>>
>> If you can write a patch for this that would be great, thank you,
>> but I think we first need to root-cause this better:
>>
>> Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
>> to always use the native backlight. So I've gone back to the original email
>> thread which lead to me adding that quirk.
>>
>> We (I forwarded a mail from you to the reporter this was not on the list)
>> did ask to test with different BIOS settings their to and the reporter's
>> reply was:
>>
>> "Daniel wanted me to check different GPU modes, but my BIOS has no options
>> for GPU. It's always in hybrid mode with PRIME render offload."
>>
>> And perhaps even more interesting in their case with acpi_backlight=native
>> to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
>> in Youssef's case when running in discrete mode there is an nvidia backlight
>> device and in Youssef's case the amdgpu_bl# device never works.
>>
>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
>>
>> While the dGPU can be one of:
>> NVIDIA GeForce RTX 3060
>> NVIDIA GeForce GTX 3050 Ti
>> NVIDIA GeForce GTX 3050
>>
>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
>> be relevant to the model with the 3060 and that nvidia-wmi-ec should
>> maybe not load at all on the model with the 3050 versions.
>>
>> Maybe the Windows Nvidia drivers only even try to use the WMI EC
>> interface with certain generations of GPUs ?
>>
>> Daniel might that be what is going on here ?
>>
>>
>> Youssef, can you try/test 2 things for us please? :
>>
>> 1. Provide the output of running "lspci -nn"
>>
>> 2. Try a kernel with the attached patch (can be applied on top
>>    of the previous patch). This removes the quirk, so that we
>>    can let the nvidia_wmi_ec auto-detect code do its thing,
>>    because maybe it does work on your model G15 5515.
>>    When testing this you should *not* have any acpi_backlight=xxx
>>    argument on your kernel commandline.
>>
>>> As for the native range bug, that does sound like a scaling issue. I'll
>>> take a look at how the NVIDIA driver determines the range of possible
>>> backlight values and see if Ican find an obvious way that might fail on
>>> a particular system.
>>
>> Ok.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>>>> On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 1/10/23 02:07, Youssef Aly wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Just reporting back, building with the patch fixed the issue.
>>>>>>
>>>>>> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
>>>>>> the kernel commandline for the patched kernel, right ?
>>>>>>
>>>>>> If you have time, can you please also check the other BIOS
>>>>>> (hybrid / discrete / ...) modes in the BIOS?
>>>>>>
>>>>>> Based on the previous bug report, I would expect you to need
>>>>>> to pass "acpi_backlight=native" in at least some of the other
>>>>>> modes ...
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hello Hans,
>>>>>>>>
>>>>>>>> Ok, I'll try building with the patch you provided, and report back.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Youssef
>>>>>>>>
>>>>>>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Youssef,
>>>>>>>>>
>>>>>>>>> On 1/9/23 17:18, Youssef Aly wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
>>>>>>>>>> is always at full brightness, this is only the case in hybrid (mux)
>>>>>>>>>> graphics mode.
>>>>>>>>>>
>>>>>>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
>>>>>>>>>> nvidia_wmi_ec_backlight    16384  0
>>>>>>>>>> video                  61440  5
>>>>>>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
>>>>>>>>>> wmi                    36864  7
>>>>>>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
>>>>>>>>>>
>>>>>>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
>>>>>>>>>> present which is not functional
>>>>>>>>>> contents of /sys/class/backlight
>>>>>>>>>> total 0
>>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
>>>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>>>>>>
>>>>>>>>>> this is the content on 6.0.12
>>>>>>>>>> total 0
>>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
>>>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
>>>>>>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
>>>>>>>>>>
>>>>>>>>>> Distro: Endeavour OS
>>>>>>>>>> Kernel: 6.1.4-arch1-1
>>>>>>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
>>>>>>>>>>
>>>>>>>>>> #regzbot introduced v6.1..v6.1.4
>>>>>>>>>
>>>>>>>>> Hmm, this is likely caused by:
>>>>>>>>>
>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
>>>>>>>>>
>>>>>>>>> Which was added because according to the reporter on their G15 5515
>>>>>>>>> backlight control only works in native mode ...
>>>>>>>>>
>>>>>>>>> I'm getting the feeling that we need to detect the BIOS setting
>>>>>>>>> and use a different backlight device depending on the setting...
>>>>>>>>>
>>>>>>>>> Daniel, any ideas?
>>>>>>>>>
>>>>>>>>> For now can you try building a kernel with the attached patch
>>>>>>>>> (which I've also just submitted upstream) and with:
>>>>>>>>>
>>>>>>>>> acpi_backlight=nvidia_wmi_ec
>>>>>>>>>
>>>>>>>>> added to your kernel commandline. That should work around this
>>>>>>>>> for now...
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Hans
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

On Wed, Jan 11, 2023 at 01:45:53PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 1/11/23 11:42, Youssef Aly wrote:
> > Hello,
> > 
> > Testing with no "acpi_backlight" in the kernel commandline. Hybrid
> > mode works, "nvidia_wmi_ec_backlight" is used. Discrete mode also
> > works with the range issue mentioned earlier, "nvidia_0" is used.
> 
> Great so without the quirk for you everything works, and from
> your lspci output I see you have a GTX 3060:
> 
> > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M
> > [GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1)
> 
> I suspect that the reporter for who the quirk was added has a 3050
> and that to fix this we need to ignore nvidia-wmi-ec support
> on laptops with a 3050.
> 
> I'm waiting for the report for who the quirk was added to provide
> lspci output on their laptop. I'll report the results of that
> once I have them.
> 
> Daniel, 2 questions:
> 
> 1. Can you confirm that nvidia-wmi-ec should not be used with
> the 3050 (mobile) GPU generation ?

3050 and 3060 are both from the same GPU generation. From what I recall
about the original reason this quirk was added, there was an apparent
system firmware bug where the ACPI interface for querying the backlight
source was reporting that the backlight was EC-controlled even though it
was actually GPU-controlled. AFAIK either the 3050 or the 3060 could be
configured for either GPU or EC backlight control, so I am not certain
whether checking to see which particular GPU is present would help.
 
> 2. Any nice and clean ideas for checking for the presence
> of a 3050 for the drivers/acpi/video_detect.c code ?
> Note I think it is probably better to check for a 3050 (variant)
> then for the newer models since the newer models is going to
> be an ever growing list of models.

I'm hoping that the difference between the system that this quirk was
added for (let's call it quirk-fix) and the system that is broken by
this quirk (quirk-break) that leads to the quirk being needed on the
quirk-fix system and anti-needed on the quirk-break system is that the
two systems are operating in different mux modes. On a dynamic mux
system, there are up to four possible modes:

* dGPU-only (iGPU is disabled; mux is fixed on dGPU)
* iGPU-only (dGPU is disabled; mux is fixed on iGPU)
* Hybrid (Both iGPU and dGPU are enabled; mux is fixed on iGPU)
* Dynamic (Both iGPU and dGPU are enabled; mux can be switched)

IIUC OEMs can choose which of these modes is available on a particular
system, and whether it can be switched by the user. My hypothesis is
that the quirk-fix system is operating in either iGPU-only or Hybrid
mode, either of which is most likely to have iGPU-driven native
backlight, but is incorrectly reporting that the backlight is under EC
control. On the quirk-break system, I suspect that the ACPI method is
correctly reporting EC vs native backlight control when switching
between the various mux modes, but gets forced by the quirk to native
backlight control, even though it should be EC-controlled in dynamic
mode.

If my hypothesis is correct, then I think to make the quirk work
properly, we should check the mux mode and only force backlight control
to native if the system is not runnin in dynamic mode. I think in theory
it should be technically possible to design a system which is always
EC-controlled even when the mux is not in dynamic mode, but I in
practice it is highly unlikely that anybody does that. So it's probably
best to only apply this check in the quirk for now, rather than
asserting that EC backlight is supported IFF the mux is in dynamic mode.
The opposite situation, namely that the brightness is not EC-controlled
when the mux is in dynamic mode, should be more common: in particular my
understanding is that EC brightness control doesn't make sense with HDR
panels, so systems with an HDR panel would need to have brightness
controlled by the relevant GPU driver's native backlight handler or via
DP AUX from the relevant GPU.

Anyway, I guess in addition to a patch to make the quirk more reliable,
it would be good to have a simple kernel module that can be used to
query the current mux mode, which would help for troubleshooting. I'll
get the patch and the module written up and cleared for public release.

> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> 
> 
> > On Wed, 11 Jan 2023 at 11:52, Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> On 1/11/23 01:40, Daniel Dadap wrote:
> >>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> >>>> Hi,
> >>>>
> >>>> On 1/10/23 16:19, Youssef Aly wrote:
> >>>>> Hi Hans,
> >>>>>
> >>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> >>>>> the kernel commandline for the patched kernel, it doesn't work without it.
> >>>>>
> >>>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> >>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> >>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> >>>>>
> >>>>> Hybrid:
> >>>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
> >>>>> amdgpu_bl1.
> >>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> >>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> >>>>>
> >>>>> Discrete:
> >>>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
> >>>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
> >>>>> same as 80, etc... ,
> >>>>> /sys/class/backlight contains nvidia_0.
> >>>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> >>>>> contains nvidia_wmi_ec_backlight.
> >>>>
> >>>> Thank you for testing!
> >>>>
> >>>> Ok so it seems there are 2 issues at play here:
> >>>>
> >>>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
> >>>>    or nvidia_wmi_ec (hybrid mode)
> >>>>
> >>>> 2. There is a bug in the nvidia binary drivers backlight control in native
> >>>>    mode on this system causing the range to be wrong
> >>>>
> >>>> Daniel, we really need help from NVidia with fixing 1. can you see if
> >>>> there is a way to check the BIOS setting/mode from inside the kernel ?
> >>>
> >>> Yes, the ACPI MXDM method should be able to do this. However, querying
> >>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> >>> determine whether the backlight is supposed to be EC-driven, since there
> >>> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> >>> be orthogonal to whether or not the EC driver should be used. It sounds
> >>> like the BIOS is possibly reporting a wrong value for that query.
> >>>
> >>> I guess we could wire up a quirk that checks MXDM and overrides the
> >>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> >>> mux operation mode. Then that quirk could be applied to this system.
> >>> I can put together a patch for that.
> >>
> >> If you can write a patch for this that would be great, thank you,
> >> but I think we first need to root-cause this better:
> >>
> >> Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> >> to always use the native backlight. So I've gone back to the original email
> >> thread which lead to me adding that quirk.
> >>
> >> We (I forwarded a mail from you to the reporter this was not on the list)
> >> did ask to test with different BIOS settings their to and the reporter's
> >> reply was:
> >>
> >> "Daniel wanted me to check different GPU modes, but my BIOS has no options
> >> for GPU. It's always in hybrid mode with PRIME render offload."
> >>
> >> And perhaps even more interesting in their case with acpi_backlight=native
> >> to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> >> in Youssef's case when running in discrete mode there is an nvidia backlight
> >> device and in Youssef's case the amdgpu_bl# device never works.
> >>
> >> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> >>
> >> While the dGPU can be one of:
> >> NVIDIA GeForce RTX 3060
> >> NVIDIA GeForce GTX 3050 Ti
> >> NVIDIA GeForce GTX 3050
> >>
> >> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> >> be relevant to the model with the 3060 and that nvidia-wmi-ec should
> >> maybe not load at all on the model with the 3050 versions.
> >>
> >> Maybe the Windows Nvidia drivers only even try to use the WMI EC
> >> interface with certain generations of GPUs ?
> >>
> >> Daniel might that be what is going on here ?
> >>
> >>
> >> Youssef, can you try/test 2 things for us please? :
> >>
> >> 1. Provide the output of running "lspci -nn"
> >>
> >> 2. Try a kernel with the attached patch (can be applied on top
> >>    of the previous patch). This removes the quirk, so that we
> >>    can let the nvidia_wmi_ec auto-detect code do its thing,
> >>    because maybe it does work on your model G15 5515.
> >>    When testing this you should *not* have any acpi_backlight=xxx
> >>    argument on your kernel commandline.
> >>
> >>> As for the native range bug, that does sound like a scaling issue. I'll
> >>> take a look at how the NVIDIA driver determines the range of possible
> >>> backlight values and see if Ican find an obvious way that might fail on
> >>> a particular system.
> >>
> >> Ok.
> >>
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>
> >>>>> On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 1/10/23 02:07, Youssef Aly wrote:
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> Just reporting back, building with the patch fixed the issue.
> >>>>>>
> >>>>>> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
> >>>>>> the kernel commandline for the patched kernel, right ?
> >>>>>>
> >>>>>> If you have time, can you please also check the other BIOS
> >>>>>> (hybrid / discrete / ...) modes in the BIOS?
> >>>>>>
> >>>>>> Based on the previous bug report, I would expect you to need
> >>>>>> to pass "acpi_backlight=native" in at least some of the other
> >>>>>> modes ...
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Hans
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> Hello Hans,
> >>>>>>>>
> >>>>>>>> Ok, I'll try building with the patch you provided, and report back.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Youssef
> >>>>>>>>
> >>>>>>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi Youssef,
> >>>>>>>>>
> >>>>>>>>> On 1/9/23 17:18, Youssef Aly wrote:
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
> >>>>>>>>>> is always at full brightness, this is only the case in hybrid (mux)
> >>>>>>>>>> graphics mode.
> >>>>>>>>>>
> >>>>>>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
> >>>>>>>>>> nvidia_wmi_ec_backlight    16384  0
> >>>>>>>>>> video                  61440  5
> >>>>>>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
> >>>>>>>>>> wmi                    36864  7
> >>>>>>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
> >>>>>>>>>>
> >>>>>>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
> >>>>>>>>>> present which is not functional
> >>>>>>>>>> contents of /sys/class/backlight
> >>>>>>>>>> total 0
> >>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
> >>>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>>>>>>
> >>>>>>>>>> this is the content on 6.0.12
> >>>>>>>>>> total 0
> >>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
> >>>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
> >>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
> >>>>>>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
> >>>>>>>>>>
> >>>>>>>>>> Distro: Endeavour OS
> >>>>>>>>>> Kernel: 6.1.4-arch1-1
> >>>>>>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
> >>>>>>>>>>
> >>>>>>>>>> #regzbot introduced v6.1..v6.1.4
> >>>>>>>>>
> >>>>>>>>> Hmm, this is likely caused by:
> >>>>>>>>>
> >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
> >>>>>>>>>
> >>>>>>>>> Which was added because according to the reporter on their G15 5515
> >>>>>>>>> backlight control only works in native mode ...
> >>>>>>>>>
> >>>>>>>>> I'm getting the feeling that we need to detect the BIOS setting
> >>>>>>>>> and use a different backlight device depending on the setting...
> >>>>>>>>>
> >>>>>>>>> Daniel, any ideas?
> >>>>>>>>>
> >>>>>>>>> For now can you try building a kernel with the attached patch
> >>>>>>>>> (which I've also just submitted upstream) and with:
> >>>>>>>>>
> >>>>>>>>> acpi_backlight=nvidia_wmi_ec
> >>>>>>>>>
> >>>>>>>>> added to your kernel commandline. That should work around this
> >>>>>>>>> for now...
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>>> Hans
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> > 
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Hans de Goede]

Hi,

On 1/11/23 23:35, Daniel Dadap wrote:
> On Wed, Jan 11, 2023 at 01:45:53PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 1/11/23 11:42, Youssef Aly wrote:
>>> Hello,
>>>
>>> Testing with no "acpi_backlight" in the kernel commandline. Hybrid
>>> mode works, "nvidia_wmi_ec_backlight" is used. Discrete mode also
>>> works with the range issue mentioned earlier, "nvidia_0" is used.
>>
>> Great so without the quirk for you everything works, and from
>> your lspci output I see you have a GTX 3060:
>>
>>> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M
>>> [GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1)
>>
>> I suspect that the reporter for who the quirk was added has a 3050
>> and that to fix this we need to ignore nvidia-wmi-ec support
>> on laptops with a 3050.
>>
>> I'm waiting for the report for who the quirk was added to provide
>> lspci output on their laptop. I'll report the results of that
>> once I have them.
>>
>> Daniel, 2 questions:
>>
>> 1. Can you confirm that nvidia-wmi-ec should not be used with
>> the 3050 (mobile) GPU generation ?
> 
> 3050 and 3060 are both from the same GPU generation.

Ok, so invalidates my theory.

> From what I recall
> about the original reason this quirk was added, there was an apparent
> system firmware bug where the ACPI interface for querying the backlight
> source was reporting that the backlight was EC-controlled even though it
> was actually GPU-controlled.

Correct, iGPU controlled by the AMD APU builtin GPU to be specific.

> AFAIK either the 3050 or the 3060 could be
> configured for either GPU or EC backlight control, so I am not certain
> whether checking to see which particular GPU is present would help.

Ok.

>> 2. Any nice and clean ideas for checking for the presence
>> of a 3050 for the drivers/acpi/video_detect.c code ?
>> Note I think it is probably better to check for a 3050 (variant)
>> then for the newer models since the newer models is going to
>> be an ever growing list of models.
> 
> I'm hoping that the difference between the system that this quirk was
> added for (let's call it quirk-fix) and the system that is broken by
> this quirk (quirk-break) that leads to the quirk being needed on the
> quirk-fix system and anti-needed on the quirk-break system is that the
> two systems are operating in different mux modes. On a dynamic mux
> system, there are up to four possible modes:
> 
> * dGPU-only (iGPU is disabled; mux is fixed on dGPU)
> * iGPU-only (dGPU is disabled; mux is fixed on iGPU)
> * Hybrid (Both iGPU and dGPU are enabled; mux is fixed on iGPU)
> * Dynamic (Both iGPU and dGPU are enabled; mux can be switched)
> 
> IIUC OEMs can choose which of these modes is available on a particular
> system, and whether it can be switched by the user. My hypothesis is
> that the quirk-fix system is operating in either iGPU-only or Hybrid
> mode, either of which is most likely to have iGPU-driven native
> backlight, but is incorrectly reporting that the backlight is under EC
> control. On the quirk-break system, I suspect that the ACPI method is
> correctly reporting EC vs native backlight control when switching
> between the various mux modes, but gets forced by the quirk to native
> backlight control, even though it should be EC-controlled in dynamic
> mode.

It is indeed possible that this is still related to the mux mode.

The reporter of the quirk-fix system did mention that on their
system the mux-mode does not appear to be controllable from
the BIOS. I guess Dell might not have implemented a mux at all
on versions with the lower tier GPU (to save money) which would
explain not having this option in the BIOS.  I wonder if
the BIOS call to detect the mux mode will work correctly then
though ...


> If my hypothesis is correct, then I think to make the quirk work
> properly, we should check the mux mode and only force backlight control
> to native if the system is not runnin in dynamic mode. I think in theory
> it should be technically possible to design a system which is always
> EC-controlled even when the mux is not in dynamic mode, but I in
> practice it is highly unlikely that anybody does that. So it's probably
> best to only apply this check in the quirk for now, rather than
> asserting that EC backlight is supported IFF the mux is in dynamic mode.
> The opposite situation, namely that the brightness is not EC-controlled
> when the mux is in dynamic mode, should be more common: in particular my
> understanding is that EC brightness control doesn't make sense with HDR
> panels, so systems with an HDR panel would need to have brightness
> controlled by the relevant GPU driver's native backlight handler or via
> DP AUX from the relevant GPU.
> 
> Anyway, I guess in addition to a patch to make the quirk more reliable,
> it would be good to have a simple kernel module that can be used to
> query the current mux mode, which would help for troubleshooting. I'll
> get the patch and the module written up and cleared for public release.

Having a little helper module to query the mux mode (or maybe have
video_detect.c log this when the WMI interface is present?) sounds like
it would be good to have, thank you for working on this.

Regards,

Hans



>>> On Wed, 11 Jan 2023 at 11:52, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 1/11/23 01:40, Daniel Dadap wrote:
>>>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 1/10/23 16:19, Youssef Aly wrote:
>>>>>>> Hi Hans,
>>>>>>>
>>>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>>>>>>> the kernel commandline for the patched kernel, it doesn't work without it.
>>>>>>>
>>>>>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
>>>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>>>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>>>>>>>
>>>>>>> Hybrid:
>>>>>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
>>>>>>> amdgpu_bl1.
>>>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>>>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>>>>>>>
>>>>>>> Discrete:
>>>>>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
>>>>>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
>>>>>>> same as 80, etc... ,
>>>>>>> /sys/class/backlight contains nvidia_0.
>>>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
>>>>>>> contains nvidia_wmi_ec_backlight.
>>>>>>
>>>>>> Thank you for testing!
>>>>>>
>>>>>> Ok so it seems there are 2 issues at play here:
>>>>>>
>>>>>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
>>>>>>    or nvidia_wmi_ec (hybrid mode)
>>>>>>
>>>>>> 2. There is a bug in the nvidia binary drivers backlight control in native
>>>>>>    mode on this system causing the range to be wrong
>>>>>>
>>>>>> Daniel, we really need help from NVidia with fixing 1. can you see if
>>>>>> there is a way to check the BIOS setting/mode from inside the kernel ?
>>>>>
>>>>> Yes, the ACPI MXDM method should be able to do this. However, querying
>>>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
>>>>> determine whether the backlight is supposed to be EC-driven, since there
>>>>> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
>>>>> be orthogonal to whether or not the EC driver should be used. It sounds
>>>>> like the BIOS is possibly reporting a wrong value for that query.
>>>>>
>>>>> I guess we could wire up a quirk that checks MXDM and overrides the
>>>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
>>>>> mux operation mode. Then that quirk could be applied to this system.
>>>>> I can put together a patch for that.
>>>>
>>>> If you can write a patch for this that would be great, thank you,
>>>> but I think we first need to root-cause this better:
>>>>
>>>> Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
>>>> to always use the native backlight. So I've gone back to the original email
>>>> thread which lead to me adding that quirk.
>>>>
>>>> We (I forwarded a mail from you to the reporter this was not on the list)
>>>> did ask to test with different BIOS settings their to and the reporter's
>>>> reply was:
>>>>
>>>> "Daniel wanted me to check different GPU modes, but my BIOS has no options
>>>> for GPU. It's always in hybrid mode with PRIME render offload."
>>>>
>>>> And perhaps even more interesting in their case with acpi_backlight=native
>>>> to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
>>>> in Youssef's case when running in discrete mode there is an nvidia backlight
>>>> device and in Youssef's case the amdgpu_bl# device never works.
>>>>
>>>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
>>>>
>>>> While the dGPU can be one of:
>>>> NVIDIA GeForce RTX 3060
>>>> NVIDIA GeForce GTX 3050 Ti
>>>> NVIDIA GeForce GTX 3050
>>>>
>>>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
>>>> be relevant to the model with the 3060 and that nvidia-wmi-ec should
>>>> maybe not load at all on the model with the 3050 versions.
>>>>
>>>> Maybe the Windows Nvidia drivers only even try to use the WMI EC
>>>> interface with certain generations of GPUs ?
>>>>
>>>> Daniel might that be what is going on here ?
>>>>
>>>>
>>>> Youssef, can you try/test 2 things for us please? :
>>>>
>>>> 1. Provide the output of running "lspci -nn"
>>>>
>>>> 2. Try a kernel with the attached patch (can be applied on top
>>>>    of the previous patch). This removes the quirk, so that we
>>>>    can let the nvidia_wmi_ec auto-detect code do its thing,
>>>>    because maybe it does work on your model G15 5515.
>>>>    When testing this you should *not* have any acpi_backlight=xxx
>>>>    argument on your kernel commandline.
>>>>
>>>>> As for the native range bug, that does sound like a scaling issue. I'll
>>>>> take a look at how the NVIDIA driver determines the range of possible
>>>>> backlight values and see if Ican find an obvious way that might fail on
>>>>> a particular system.
>>>>
>>>> Ok.
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>>
>>>>
>>>>
>>>>>>> On Tue, 10 Jan 2023 at 10:39, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 1/10/23 02:07, Youssef Aly wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Just reporting back, building with the patch fixed the issue.
>>>>>>>>
>>>>>>>> I assume that you also added "acpi_backlight=nvidia_wmi_ec" to
>>>>>>>> the kernel commandline for the patched kernel, right ?
>>>>>>>>
>>>>>>>> If you have time, can you please also check the other BIOS
>>>>>>>> (hybrid / discrete / ...) modes in the BIOS?
>>>>>>>>
>>>>>>>> Based on the previous bug report, I would expect you to need
>>>>>>>> to pass "acpi_backlight=native" in at least some of the other
>>>>>>>> modes ...
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Mon, 9 Jan 2023 at 22:23, Youssef Aly <youssefaswad@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Hans,
>>>>>>>>>>
>>>>>>>>>> Ok, I'll try building with the patch you provided, and report back.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Youssef
>>>>>>>>>>
>>>>>>>>>> On Mon, 9 Jan 2023 at 21:19, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Youssef,
>>>>>>>>>>>
>>>>>>>>>>> On 1/9/23 17:18, Youssef Aly wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> The backlight control has been broken on Dell G15 5515 since 6.1, it
>>>>>>>>>>>> is always at full brightness, this is only the case in hybrid (mux)
>>>>>>>>>>>> graphics mode.
>>>>>>>>>>>>
>>>>>>>>>>>> As per the output of lsmod the nvidia_wmi_ec_backlight is loaded:
>>>>>>>>>>>> nvidia_wmi_ec_backlight    16384  0
>>>>>>>>>>>> video                  61440  5
>>>>>>>>>>>> nvidia_wmi_ec_backlight,dell_wmi,amdgpu,dell_laptop,nvidia_modeset
>>>>>>>>>>>> wmi                    36864  7
>>>>>>>>>>>> video,nvidia_wmi_ec_backlight,alienware_wmi,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
>>>>>>>>>>>>
>>>>>>>>>>>> but it is not present in /sys/class/backlight, only amdgpu_bl1 is
>>>>>>>>>>>> present which is not functional
>>>>>>>>>>>> contents of /sys/class/backlight
>>>>>>>>>>>> total 0
>>>>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  9 00:49 amdgpu_bl1 ->
>>>>>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>>>>>>>>
>>>>>>>>>>>> this is the content on 6.0.12
>>>>>>>>>>>> total 0
>>>>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 amdgpu_bl1 ->
>>>>>>>>>>>> ../../devices/pci0000:00/0000:00:08.1/0000:06:00.0/backlight/amdgpu_bl1/
>>>>>>>>>>>> lrwxrwxrwx 1 root root 0 Jan  8 20:59 nvidia_wmi_ec_backlight ->
>>>>>>>>>>>> ../../devices/pci0000:00/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/603E9613-EF25-4338-A3D0-C46177516DB7/backlight/nvidia_wmi_ec_backlight/
>>>>>>>>>>>>
>>>>>>>>>>>> Distro: Endeavour OS
>>>>>>>>>>>> Kernel: 6.1.4-arch1-1
>>>>>>>>>>>> GPU: RTX 3060 Using nvidia proprietary drivers version 525.78.01
>>>>>>>>>>>>
>>>>>>>>>>>> #regzbot introduced v6.1..v6.1.4
>>>>>>>>>>>
>>>>>>>>>>> Hmm, this is likely caused by:
>>>>>>>>>>>
>>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46acc1efd4b5846de9fa05f966e504f328f34a6
>>>>>>>>>>>
>>>>>>>>>>> Which was added because according to the reporter on their G15 5515
>>>>>>>>>>> backlight control only works in native mode ...
>>>>>>>>>>>
>>>>>>>>>>> I'm getting the feeling that we need to detect the BIOS setting
>>>>>>>>>>> and use a different backlight device depending on the setting...
>>>>>>>>>>>
>>>>>>>>>>> Daniel, any ideas?
>>>>>>>>>>>
>>>>>>>>>>> For now can you try building a kernel with the attached patch
>>>>>>>>>>> (which I've also just submitted upstream) and with:
>>>>>>>>>>>
>>>>>>>>>>> acpi_backlight=nvidia_wmi_ec
>>>>>>>>>>>
>>>>>>>>>>> added to your kernel commandline. That should work around this
>>>>>>>>>>> for now...
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Hans de Goede]

Hi All,

On 1/11/23 10:51, Hans de Goede wrote:
> Hi,
> 
> On 1/11/23 01:40, Daniel Dadap wrote:
>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 1/10/23 16:19, Youssef Aly wrote:
>>>> Hi Hans,
>>>>
>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>>>> the kernel commandline for the patched kernel, it doesn't work without it.
>>>>
>>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>>>>
>>>> Hybrid:
>>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
>>>> amdgpu_bl1.
>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>>>>
>>>> Discrete:
>>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
>>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
>>>> same as 80, etc... ,
>>>> /sys/class/backlight contains nvidia_0.
>>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
>>>> contains nvidia_wmi_ec_backlight.
>>>
>>> Thank you for testing!
>>>
>>> Ok so it seems there are 2 issues at play here:
>>>
>>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
>>>    or nvidia_wmi_ec (hybrid mode)
>>>
>>> 2. There is a bug in the nvidia binary drivers backlight control in native
>>>    mode on this system causing the range to be wrong
>>>
>>> Daniel, we really need help from NVidia with fixing 1. can you see if
>>> there is a way to check the BIOS setting/mode from inside the kernel ?
>>
>> Yes, the ACPI MXDM method should be able to do this. However, querying
>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
>> determine whether the backlight is supposed to be EC-driven, since there
>> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
>> be orthogonal to whether or not the EC driver should be used. It sounds
>> like the BIOS is possibly reporting a wrong value for that query.
>>
>> I guess we could wire up a quirk that checks MXDM and overrides the
>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
>> mux operation mode. Then that quirk could be applied to this system.
>> I can put together a patch for that.
> 
> If you can write a patch for this that would be great, thank you,
> but I think we first need to root-cause this better:
> 
> Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> to always use the native backlight. So I've gone back to the original email
> thread which lead to me adding that quirk.
> 
> We (I forwarded a mail from you to the reporter this was not on the list)
> did ask to test with different BIOS settings their to and the reporter's
> reply was:
> 
> "Daniel wanted me to check different GPU modes, but my BIOS has no options
> for GPU. It's always in hybrid mode with PRIME render offload."
> 
> And perhaps even more interesting in their case with acpi_backlight=native
> to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> in Youssef's case when running in discrete mode there is an nvidia backlight
> device and in Youssef's case the amdgpu_bl# device never works.
> 
> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> 
> While the dGPU can be one of:
> NVIDIA GeForce RTX 3060
> NVIDIA GeForce GTX 3050 Ti
> NVIDIA GeForce GTX 3050
> 
> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> be relevant to the model with the 3060 and that nvidia-wmi-ec should
> maybe not load at all on the model with the 3050 versions.

A quick status update on this.

Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has 
gotten back to me with lspci output on their G15 and it indeed has
a GTX 3050.

So atm we have the following models which are affected one way
or the other:

  -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 :(

With the models which need acpi_backlight=native being broken
by (false positive) detection of the laptop needing nvidia-wmi-ec
for backlight control while they actually should not be using that.

and with the Dell G15 5515 with RTX 3060 atm being broken because
of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.

Regards,

Hans

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

[-- Attachment #1: Type: text/plain, Size: 7186 bytes --]

Thanks, Hans.

On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> Hi All,
> 
> On 1/11/23 10:51, Hans de Goede wrote:
> > Hi,
> > 
> > On 1/11/23 01:40, Daniel Dadap wrote:
> >> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 1/10/23 16:19, Youssef Aly wrote:
> >>>> Hi Hans,
> >>>>
> >>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> >>>> the kernel commandline for the patched kernel, it doesn't work without it.
> >>>>
> >>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> >>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> >>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> >>>>
> >>>> Hybrid:
> >>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
> >>>> amdgpu_bl1.
> >>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> >>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> >>>>
> >>>> Discrete:
> >>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
> >>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
> >>>> same as 80, etc... ,
> >>>> /sys/class/backlight contains nvidia_0.
> >>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> >>>> contains nvidia_wmi_ec_backlight.
> >>>
> >>> Thank you for testing!
> >>>
> >>> Ok so it seems there are 2 issues at play here:
> >>>
> >>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
> >>>    or nvidia_wmi_ec (hybrid mode)
> >>>
> >>> 2. There is a bug in the nvidia binary drivers backlight control in native
> >>>    mode on this system causing the range to be wrong
> >>>
> >>> Daniel, we really need help from NVidia with fixing 1. can you see if
> >>> there is a way to check the BIOS setting/mode from inside the kernel ?
> >>
> >> Yes, the ACPI MXDM method should be able to do this. However, querying
> >> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> >> determine whether the backlight is supposed to be EC-driven, since there
> >> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> >> be orthogonal to whether or not the EC driver should be used. It sounds
> >> like the BIOS is possibly reporting a wrong value for that query.
> >>
> >> I guess we could wire up a quirk that checks MXDM and overrides the
> >> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> >> mux operation mode. Then that quirk could be applied to this system.
> >> I can put together a patch for that.
> > 
> > If you can write a patch for this that would be great, thank you,
> > but I think we first need to root-cause this better:
> > 
> > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > to always use the native backlight. So I've gone back to the original email
> > thread which lead to me adding that quirk.
> > 
> > We (I forwarded a mail from you to the reporter this was not on the list)
> > did ask to test with different BIOS settings their to and the reporter's
> > reply was:
> > 
> > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > for GPU. It's always in hybrid mode with PRIME render offload."
> > 
> > And perhaps even more interesting in their case with acpi_backlight=native
> > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > in Youssef's case when running in discrete mode there is an nvidia backlight
> > device and in Youssef's case the amdgpu_bl# device never works.
> > 
> > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > 
> > While the dGPU can be one of:
> > NVIDIA GeForce RTX 3060
> > NVIDIA GeForce GTX 3050 Ti
> > NVIDIA GeForce GTX 3050
> > 
> > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > maybe not load at all on the model with the 3050 versions.
> 
> A quick status update on this.
> 
> Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has 
> gotten back to me with lspci output on their G15 and it indeed has
> a GTX 3050.
> 
> So atm we have the following models which are affected one way
> or the other:
> 
>   -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 :(
> 
> With the models which need acpi_backlight=native being broken
> by (false positive) detection of the laptop needing nvidia-wmi-ec
> for backlight control while they actually should not be using that.
> 
> and with the Dell G15 5515 with RTX 3060 atm being broken because
> of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.

I've attached a simple kernel module which adds a debugfs file that
reports the current mux mode. As mentioned elsewhere, I suspect that the
systems which need the quirk may be in one of the non-dynamic modes, and
the systems which are broken by the quirk may be in dynamic mux mode. It
should be pretty straightforward to compile this as an out-of-tree
module using the Kbuild extmod infrastructure, as follows:

1) Change to the directory containing the mxdm-debugfs.c file (you may
   wish to create an empty directory to put it in) and create a file in
   that directory containing the following line:

   obj-m += mxdm-debugfs.o

2) Build the kernel module:

   make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)

   (The "source" and "build" paths under /lib/modules/`uname -r` should
   be the correct paths in almost all cases; if your system uses
   different paths, substitute those. You will need the development
   headers for external kernel modules, and the relevant toolchain bits,
   but if you're already using the NVIDIA proprietary driver you almost
   certainly already have all of that.)

3) Load the kernel module:

   insmod ./mxdm-debugfs.ko

This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
Reading this file should report the current mux operation mode.

While switching mux modes on a dynamic mux system to test this kernel
module, I noticed that the ACPI tables no longer exposed the MXDM method
when the mux mode was set to discrete only on that particular system.
This contradicted the behavior I had previously observed on other
systems; i.e., that MXDM is always available regardless of the currently
set mux mode, so I tried it on another dynamic mux system and observed
that the other system does always expose MXDM regardless of the mux
mode, and the contents of the debugfs file matched the selected mode.

So if the module fails to load with ENODEV and prints the "MXDM not
found" message to the kernel log, the system is most likely configured
to a non-dynamic mux mode. My usual expectation is that it should load
and create the file on most dynamic mux systems. I do not have direct
access to any of the above listed systems at the moment, so I do not
know whether MXDM will be exposed when the system is not in dynamic mux
mode.
 
> Regards,
> 
> Hans
> 

[-- Attachment #2: mxdm-debugfs.c --]
[-- Type: text/plain, Size: 3100 bytes --]

// SPDX-License-Identifier: GPL-2.0-only
/*
 * Copyright (C) 2020 NVIDIA Corporation
 *
 */

#include <linux/acpi.h>
#include <acpi/acoutput.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/debugfs.h>

extern struct dentry *acpi_debugfs_dir;

enum mux_mode {
	MUX_MODE_UNKNOWN = 0,
	MUX_MODE_INTEGRATED = 1, /* iGPU only */
	MUX_MODE_DISCRETE = 2,   /* dGPU only */
	MUX_MODE_HYBRID = 3,     /* Dual GPU, mux switched to iGPU */
	MUX_MODE_DYNAMIC = 4,    /* Dual GPU, dynamic mux switching */
	MUX_MODE_MAX
};

static char * mode_names[] = {
	[MUX_MODE_UNKNOWN] = "unknown\n",
	[MUX_MODE_INTEGRATED] = "integrated\n",
	[MUX_MODE_DISCRETE] = "discrete\n",
	[MUX_MODE_HYBRID] = "hybrid\n",
	[MUX_MODE_DYNAMIC] = "dynamic\n",
};

static struct debugfs_blob_wrapper muxmode_blob;

static void store_mux_mode(acpi_handle handle)
{
	union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
	struct acpi_object_list in = { .count = 1, .pointer = &arg };

	acpi_integer ret;
	acpi_status status;

	status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);

	if (ACPI_FAILURE(status)) {
		acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
		muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
	} else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
		acpi_handle_err(handle, "Mux mode value out of range");
		muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
	} else {
		muxmode_blob.data = mode_names[ret];
	}

	muxmode_blob.size = strlen(muxmode_blob.data);
}

static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
{
	acpi_handle search;

	if (acpi_get_handle(obj, "MXDM", &search) == 0) {
		/* Found the parent object of the MXDM method; pass it back
		 * to the caller and stop searching. */
		*ret = obj;

		return AE_CTRL_TERMINATE;
	}

	/* No MXDM; keep looking */
	return AE_OK;
}

static struct dentry *muxmode_file_dentry;

static int __init mxdm_debugfs_init(void)
{
	acpi_handle mxdm_handle = NULL;
	acpi_status ret;

	ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
					  find_mxdm, NULL, NULL, &mxdm_handle);

	if (ACPI_FAILURE(ret) || !mxdm_handle) {
		pr_err("MXDM not found.\n");
		return -ENODEV;
	}

    /* Populate the blob wrapper: the mux mode cannot change without rebooting
     * so this only needs to be done once. */
	store_mux_mode(mxdm_handle);

	muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
						  acpi_debugfs_dir,
						  &muxmode_blob);

	return muxmode_file_dentry ? 0 : -EIO;
}
module_init(mxdm_debugfs_init);

static void __exit mxdm_debugfs_exit(void)
{
	if (muxmode_file_dentry) {
		debugfs_remove(muxmode_file_dentry);
		muxmode_file_dentry = NULL;
	}
}
module_exit(mxdm_debugfs_exit);

MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("MXDM mux mode test module");
MODULE_AUTHOR("Daniel Dadap <ddadap@nvidia.com>");

/*
 * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
 * the WMI wrapper for the related WMAA method for backlight control.
 */
MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

Hans pointed out a crucial omission in the build instructions in a
different thread where I also shared this test module:

On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> Thanks, Hans.
> 
> On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > Hi All,
> > 
> > On 1/11/23 10:51, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 1/11/23 01:40, Daniel Dadap wrote:
> > >> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > >>> Hi,
> > >>>
> > >>> On 1/10/23 16:19, Youssef Aly wrote:
> > >>>> Hi Hans,
> > >>>>
> > >>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > >>>> the kernel commandline for the patched kernel, it doesn't work without it.
> > >>>>
> > >>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > >>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> > >>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> > >>>>
> > >>>> Hybrid:
> > >>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > >>>> amdgpu_bl1.
> > >>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > >>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > >>>>
> > >>>> Discrete:
> > >>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
> > >>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
> > >>>> same as 80, etc... ,
> > >>>> /sys/class/backlight contains nvidia_0.
> > >>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > >>>> contains nvidia_wmi_ec_backlight.
> > >>>
> > >>> Thank you for testing!
> > >>>
> > >>> Ok so it seems there are 2 issues at play here:
> > >>>
> > >>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > >>>    or nvidia_wmi_ec (hybrid mode)
> > >>>
> > >>> 2. There is a bug in the nvidia binary drivers backlight control in native
> > >>>    mode on this system causing the range to be wrong
> > >>>
> > >>> Daniel, we really need help from NVidia with fixing 1. can you see if
> > >>> there is a way to check the BIOS setting/mode from inside the kernel ?
> > >>
> > >> Yes, the ACPI MXDM method should be able to do this. However, querying
> > >> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > >> determine whether the backlight is supposed to be EC-driven, since there
> > >> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > >> be orthogonal to whether or not the EC driver should be used. It sounds
> > >> like the BIOS is possibly reporting a wrong value for that query.
> > >>
> > >> I guess we could wire up a quirk that checks MXDM and overrides the
> > >> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > >> mux operation mode. Then that quirk could be applied to this system.
> > >> I can put together a patch for that.
> > > 
> > > If you can write a patch for this that would be great, thank you,
> > > but I think we first need to root-cause this better:
> > > 
> > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > to always use the native backlight. So I've gone back to the original email
> > > thread which lead to me adding that quirk.
> > > 
> > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > did ask to test with different BIOS settings their to and the reporter's
> > > reply was:
> > > 
> > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > for GPU. It's always in hybrid mode with PRIME render offload."
> > > 
> > > And perhaps even more interesting in their case with acpi_backlight=native
> > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > device and in Youssef's case the amdgpu_bl# device never works.
> > > 
> > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > > 
> > > While the dGPU can be one of:
> > > NVIDIA GeForce RTX 3060
> > > NVIDIA GeForce GTX 3050 Ti
> > > NVIDIA GeForce GTX 3050
> > > 
> > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > maybe not load at all on the model with the 3050 versions.
> > 
> > A quick status update on this.
> > 
> > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has 
> > gotten back to me with lspci output on their G15 and it indeed has
> > a GTX 3050.
> > 
> > So atm we have the following models which are affected one way
> > or the other:
> > 
> >   -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 :(
> > 
> > With the models which need acpi_backlight=native being broken
> > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > for backlight control while they actually should not be using that.
> > 
> > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> 
> I've attached a simple kernel module which adds a debugfs file that
> reports the current mux mode. As mentioned elsewhere, I suspect that the
> systems which need the quirk may be in one of the non-dynamic modes, and
> the systems which are broken by the quirk may be in dynamic mux mode. It
> should be pretty straightforward to compile this as an out-of-tree
> module using the Kbuild extmod infrastructure, as follows:
> 
> 1) Change to the directory containing the mxdm-debugfs.c file (you may
>    wish to create an empty directory to put it in) and create a file in
>    that directory containing the following line:

The name of this file should be 'Kbuild'. Sorry for the noise.

>    obj-m += mxdm-debugfs.o
> 
> 2) Build the kernel module:
> 
>    make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> 
>    (The "source" and "build" paths under /lib/modules/`uname -r` should
>    be the correct paths in almost all cases; if your system uses
>    different paths, substitute those. You will need the development
>    headers for external kernel modules, and the relevant toolchain bits,
>    but if you're already using the NVIDIA proprietary driver you almost
>    certainly already have all of that.)
> 
> 3) Load the kernel module:
> 
>    insmod ./mxdm-debugfs.ko
> 
> This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> Reading this file should report the current mux operation mode.
> 
> While switching mux modes on a dynamic mux system to test this kernel
> module, I noticed that the ACPI tables no longer exposed the MXDM method
> when the mux mode was set to discrete only on that particular system.
> This contradicted the behavior I had previously observed on other
> systems; i.e., that MXDM is always available regardless of the currently
> set mux mode, so I tried it on another dynamic mux system and observed
> that the other system does always expose MXDM regardless of the mux
> mode, and the contents of the debugfs file matched the selected mode.
> 
> So if the module fails to load with ENODEV and prints the "MXDM not
> found" message to the kernel log, the system is most likely configured
> to a non-dynamic mux mode. My usual expectation is that it should load
> and create the file on most dynamic mux systems. I do not have direct
> access to any of the above listed systems at the moment, so I do not
> know whether MXDM will be exposed when the system is not in dynamic mux
> mode.
>  
> > Regards,
> > 
> > Hans
> > 

> // SPDX-License-Identifier: GPL-2.0-only
> /*
>  * Copyright (C) 2020 NVIDIA Corporation
>  *
>  */
> 
> #include <linux/acpi.h>
> #include <acpi/acoutput.h>
> #include <linux/module.h>
> #include <linux/pci.h>
> #include <linux/debugfs.h>
> 
> extern struct dentry *acpi_debugfs_dir;
> 
> enum mux_mode {
> 	MUX_MODE_UNKNOWN = 0,
> 	MUX_MODE_INTEGRATED = 1, /* iGPU only */
> 	MUX_MODE_DISCRETE = 2,   /* dGPU only */
> 	MUX_MODE_HYBRID = 3,     /* Dual GPU, mux switched to iGPU */
> 	MUX_MODE_DYNAMIC = 4,    /* Dual GPU, dynamic mux switching */
> 	MUX_MODE_MAX
> };
> 
> static char * mode_names[] = {
> 	[MUX_MODE_UNKNOWN] = "unknown\n",
> 	[MUX_MODE_INTEGRATED] = "integrated\n",
> 	[MUX_MODE_DISCRETE] = "discrete\n",
> 	[MUX_MODE_HYBRID] = "hybrid\n",
> 	[MUX_MODE_DYNAMIC] = "dynamic\n",
> };
> 
> static struct debugfs_blob_wrapper muxmode_blob;
> 
> static void store_mux_mode(acpi_handle handle)
> {
> 	union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> 	struct acpi_object_list in = { .count = 1, .pointer = &arg };
> 
> 	acpi_integer ret;
> 	acpi_status status;
> 
> 	status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> 
> 	if (ACPI_FAILURE(status)) {
> 		acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> 		muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> 	} else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> 		acpi_handle_err(handle, "Mux mode value out of range");
> 		muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> 	} else {
> 		muxmode_blob.data = mode_names[ret];
> 	}
> 
> 	muxmode_blob.size = strlen(muxmode_blob.data);
> }
> 
> static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> {
> 	acpi_handle search;
> 
> 	if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> 		/* Found the parent object of the MXDM method; pass it back
> 		 * to the caller and stop searching. */
> 		*ret = obj;
> 
> 		return AE_CTRL_TERMINATE;
> 	}
> 
> 	/* No MXDM; keep looking */
> 	return AE_OK;
> }
> 
> static struct dentry *muxmode_file_dentry;
> 
> static int __init mxdm_debugfs_init(void)
> {
> 	acpi_handle mxdm_handle = NULL;
> 	acpi_status ret;
> 
> 	ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> 					  find_mxdm, NULL, NULL, &mxdm_handle);
> 
> 	if (ACPI_FAILURE(ret) || !mxdm_handle) {
> 		pr_err("MXDM not found.\n");
> 		return -ENODEV;
> 	}
> 
>     /* Populate the blob wrapper: the mux mode cannot change without rebooting
>      * so this only needs to be done once. */
> 	store_mux_mode(mxdm_handle);
> 
> 	muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> 						  acpi_debugfs_dir,
> 						  &muxmode_blob);
> 
> 	return muxmode_file_dentry ? 0 : -EIO;
> }
> module_init(mxdm_debugfs_init);
> 
> static void __exit mxdm_debugfs_exit(void)
> {
> 	if (muxmode_file_dentry) {
> 		debugfs_remove(muxmode_file_dentry);
> 		muxmode_file_dentry = NULL;
> 	}
> }
> module_exit(mxdm_debugfs_exit);
> 
> MODULE_LICENSE("GPL v2");
> MODULE_DESCRIPTION("MXDM mux mode test module");
> MODULE_AUTHOR("Daniel Dadap <ddadap@nvidia.com>");
> 
> /*
>  * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
>  * the WMI wrapper for the related WMAA method for backlight control.
>  */
> MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Aly]

 Hello Daniel,

I tried building the module using the instructions you provided, but
ran into some problems as I didn't have the /lib/modules/$(uname
-r)/source directory on my end.
I created a Makefile in a directory containing mxdm-debugfs.c file and
added the following to it:

obj-m += mxdm-debugfs.o

all:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

I then ran "make" and loaded the module.

1) Hybrid mode set to "Enabled" from the bios settings,
/sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
2) Hybrid mode set to "Disabled" from the bios settings,
/sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.

Regards,

Youssef


On Tue, 17 Jan 2023 at 23:24, Daniel Dadap <ddadap@nvidia.com> wrote:
>
> Hans pointed out a crucial omission in the build instructions in a
> different thread where I also shared this test module:
>
> On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > Thanks, Hans.
> >
> > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > > Hi All,
> > >
> > > On 1/11/23 10:51, Hans de Goede wrote:
> > > > Hi,
> > > >
> > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > > >> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > > >>> Hi,
> > > >>>
> > > >>> On 1/10/23 16:19, Youssef Aly wrote:
> > > >>>> Hi Hans,
> > > >>>>
> > > >>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > >>>> the kernel commandline for the patched kernel, it doesn't work without it.
> > > >>>>
> > > >>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > >>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > >>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> > > >>>>
> > > >>>> Hybrid:
> > > >>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > >>>> amdgpu_bl1.
> > > >>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > >>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > > >>>>
> > > >>>> Discrete:
> > > >>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > >>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > >>>> same as 80, etc... ,
> > > >>>> /sys/class/backlight contains nvidia_0.
> > > >>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > >>>> contains nvidia_wmi_ec_backlight.
> > > >>>
> > > >>> Thank you for testing!
> > > >>>
> > > >>> Ok so it seems there are 2 issues at play here:
> > > >>>
> > > >>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > >>>    or nvidia_wmi_ec (hybrid mode)
> > > >>>
> > > >>> 2. There is a bug in the nvidia binary drivers backlight control in native
> > > >>>    mode on this system causing the range to be wrong
> > > >>>
> > > >>> Daniel, we really need help from NVidia with fixing 1. can you see if
> > > >>> there is a way to check the BIOS setting/mode from inside the kernel ?
> > > >>
> > > >> Yes, the ACPI MXDM method should be able to do this. However, querying
> > > >> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > >> determine whether the backlight is supposed to be EC-driven, since there
> > > >> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > >> be orthogonal to whether or not the EC driver should be used. It sounds
> > > >> like the BIOS is possibly reporting a wrong value for that query.
> > > >>
> > > >> I guess we could wire up a quirk that checks MXDM and overrides the
> > > >> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > >> mux operation mode. Then that quirk could be applied to this system.
> > > >> I can put together a patch for that.
> > > >
> > > > If you can write a patch for this that would be great, thank you,
> > > > but I think we first need to root-cause this better:
> > > >
> > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > to always use the native backlight. So I've gone back to the original email
> > > > thread which lead to me adding that quirk.
> > > >
> > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > did ask to test with different BIOS settings their to and the reporter's
> > > > reply was:
> > > >
> > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > > >
> > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > device and in Youssef's case the amdgpu_bl# device never works.
> > > >
> > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > > >
> > > > While the dGPU can be one of:
> > > > NVIDIA GeForce RTX 3060
> > > > NVIDIA GeForce GTX 3050 Ti
> > > > NVIDIA GeForce GTX 3050
> > > >
> > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > maybe not load at all on the model with the 3050 versions.
> > >
> > > A quick status update on this.
> > >
> > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > gotten back to me with lspci output on their G15 and it indeed has
> > > a GTX 3050.
> > >
> > > So atm we have the following models which are affected one way
> > > or the other:
> > >
> > >   -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 :(
> > >
> > > With the models which need acpi_backlight=native being broken
> > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > for backlight control while they actually should not be using that.
> > >
> > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> >
> > I've attached a simple kernel module which adds a debugfs file that
> > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > systems which need the quirk may be in one of the non-dynamic modes, and
> > the systems which are broken by the quirk may be in dynamic mux mode. It
> > should be pretty straightforward to compile this as an out-of-tree
> > module using the Kbuild extmod infrastructure, as follows:
> >
> > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> >    wish to create an empty directory to put it in) and create a file in
> >    that directory containing the following line:
>
> The name of this file should be 'Kbuild'. Sorry for the noise.
>
> >    obj-m += mxdm-debugfs.o
> >
> > 2) Build the kernel module:
> >
> >    make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> >
> >    (The "source" and "build" paths under /lib/modules/`uname -r` should
> >    be the correct paths in almost all cases; if your system uses
> >    different paths, substitute those. You will need the development
> >    headers for external kernel modules, and the relevant toolchain bits,
> >    but if you're already using the NVIDIA proprietary driver you almost
> >    certainly already have all of that.)
> >
> > 3) Load the kernel module:
> >
> >    insmod ./mxdm-debugfs.ko
> >
> > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > Reading this file should report the current mux operation mode.
> >
> > While switching mux modes on a dynamic mux system to test this kernel
> > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > when the mux mode was set to discrete only on that particular system.
> > This contradicted the behavior I had previously observed on other
> > systems; i.e., that MXDM is always available regardless of the currently
> > set mux mode, so I tried it on another dynamic mux system and observed
> > that the other system does always expose MXDM regardless of the mux
> > mode, and the contents of the debugfs file matched the selected mode.
> >
> > So if the module fails to load with ENODEV and prints the "MXDM not
> > found" message to the kernel log, the system is most likely configured
> > to a non-dynamic mux mode. My usual expectation is that it should load
> > and create the file on most dynamic mux systems. I do not have direct
> > access to any of the above listed systems at the moment, so I do not
> > know whether MXDM will be exposed when the system is not in dynamic mux
> > mode.
> >
> > > Regards,
> > >
> > > Hans
> > >
>
> > // SPDX-License-Identifier: GPL-2.0-only
> > /*
> >  * Copyright (C) 2020 NVIDIA Corporation
> >  *
> >  */
> >
> > #include <linux/acpi.h>
> > #include <acpi/acoutput.h>
> > #include <linux/module.h>
> > #include <linux/pci.h>
> > #include <linux/debugfs.h>
> >
> > extern struct dentry *acpi_debugfs_dir;
> >
> > enum mux_mode {
> >       MUX_MODE_UNKNOWN = 0,
> >       MUX_MODE_INTEGRATED = 1, /* iGPU only */
> >       MUX_MODE_DISCRETE = 2,   /* dGPU only */
> >       MUX_MODE_HYBRID = 3,     /* Dual GPU, mux switched to iGPU */
> >       MUX_MODE_DYNAMIC = 4,    /* Dual GPU, dynamic mux switching */
> >       MUX_MODE_MAX
> > };
> >
> > static char * mode_names[] = {
> >       [MUX_MODE_UNKNOWN] = "unknown\n",
> >       [MUX_MODE_INTEGRATED] = "integrated\n",
> >       [MUX_MODE_DISCRETE] = "discrete\n",
> >       [MUX_MODE_HYBRID] = "hybrid\n",
> >       [MUX_MODE_DYNAMIC] = "dynamic\n",
> > };
> >
> > static struct debugfs_blob_wrapper muxmode_blob;
> >
> > static void store_mux_mode(acpi_handle handle)
> > {
> >       union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> >       struct acpi_object_list in = { .count = 1, .pointer = &arg };
> >
> >       acpi_integer ret;
> >       acpi_status status;
> >
> >       status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> >
> >       if (ACPI_FAILURE(status)) {
> >               acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> >               muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> >       } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> >               acpi_handle_err(handle, "Mux mode value out of range");
> >               muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> >       } else {
> >               muxmode_blob.data = mode_names[ret];
> >       }
> >
> >       muxmode_blob.size = strlen(muxmode_blob.data);
> > }
> >
> > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > {
> >       acpi_handle search;
> >
> >       if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> >               /* Found the parent object of the MXDM method; pass it back
> >                * to the caller and stop searching. */
> >               *ret = obj;
> >
> >               return AE_CTRL_TERMINATE;
> >       }
> >
> >       /* No MXDM; keep looking */
> >       return AE_OK;
> > }
> >
> > static struct dentry *muxmode_file_dentry;
> >
> > static int __init mxdm_debugfs_init(void)
> > {
> >       acpi_handle mxdm_handle = NULL;
> >       acpi_status ret;
> >
> >       ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> >                                         find_mxdm, NULL, NULL, &mxdm_handle);
> >
> >       if (ACPI_FAILURE(ret) || !mxdm_handle) {
> >               pr_err("MXDM not found.\n");
> >               return -ENODEV;
> >       }
> >
> >     /* Populate the blob wrapper: the mux mode cannot change without rebooting
> >      * so this only needs to be done once. */
> >       store_mux_mode(mxdm_handle);
> >
> >       muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> >                                                 acpi_debugfs_dir,
> >                                                 &muxmode_blob);
> >
> >       return muxmode_file_dentry ? 0 : -EIO;
> > }
> > module_init(mxdm_debugfs_init);
> >
> > static void __exit mxdm_debugfs_exit(void)
> > {
> >       if (muxmode_file_dentry) {
> >               debugfs_remove(muxmode_file_dentry);
> >               muxmode_file_dentry = NULL;
> >       }
> > }
> > module_exit(mxdm_debugfs_exit);
> >
> > MODULE_LICENSE("GPL v2");
> > MODULE_DESCRIPTION("MXDM mux mode test module");
> > MODULE_AUTHOR("Daniel Dadap <ddadap@nvidia.com>");
> >
> > /*
> >  * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> >  * the WMI wrapper for the related WMAA method for backlight control.
> >  */
> > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
>

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
>  Hello Daniel,
> 
> I tried building the module using the instructions you provided, but
> ran into some problems as I didn't have the /lib/modules/$(uname
> -r)/source directory on my end.
> I created a Makefile in a directory containing mxdm-debugfs.c file and
> added the following to it:
> 
> obj-m += mxdm-debugfs.o
> 
> all:
>     make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> 
> clean:
>     make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> 
> I then ran "make" and loaded the module.

Ah, yes, I should have mentioned specifically that the instructions
assumed either a split Kbuild configuration with separate source and
output directories, or a single combined source and output directory but
with "source" and "build" both being symlinks to the same directory. I
forget which distros do what exactly, but some ship a combined
source/output directory but only have one of either "source" or "build";
yours appears to be the latter configuration. I'm glad you were able to
get it building anyway.
 
> 1) Hybrid mode set to "Enabled" from the bios settings,
> /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> 2) Hybrid mode set to "Disabled" from the bios settings,
> /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.

Okay. This is consistent with my expectations. If we also find that the
systems which require the quirk report either "discrete", "hybrid", or
"integrated" (IIUC those systems do not have the mode configurable in the
UEFI settings), then I think we can fix the quirk by checking the mux
mode and only forcing to native if the system is not in hybrid mode.

Or perhaps we should just get rid of the quirk, and unconditionally test
the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
are not in "dynamic" mode, regardless of whether they expose the WMI EC
backlight interface and regardless of whether that interface reports
that the EC backlight driver should be used. (On the systems that need
the quirk, that interface is reporting that the backlight should be
EC-controlled even when it shouldn't be.) I *think* that in theory, it
should be possible for a system design to require EC backlight control
even when the mux is in a non-dynamic mode, but in practice I don't know
why anybody would do that, and am not aware of any systems which do so
(although until the report of the broken backlight on the 3050 version
of the Dell G15 5515, I wasn't aware of any systems that reported EC
backlight control when it was supposed to be native.)

Hans, I think the most reasonable options are:

1) Remove the quirk, and check for MXDM when deciding whether a system
should use the EC backlight driver. This has the disadvantage of adding
a check where one isn't actually needed on some (most?) systems, and the
advantage of most likely avoiding the need to add quirks for other
systems where the system reports EC backlight control when native should
be used. It also has the possibility of being wrong on a theoretically
possible configuration, although if we ever encounter such a
configuration we could handle it with a quirk or find some other way to
distinguish between systems that do or do not require the EC backlight
driver.

2) Keep the existing quirk, and only force to native if MXDM is missing
or if MXDM reports that the system is in a non-dynamic mode.

I'm inclined to go with (2), because it seems "safer", but am happy to
implement (1) if you think that's the better option. For the MXDM check
I think the first thing to do is to check whether the MXDM method is
present at all: as observed on at least one system, there is no MXDM
method when the system is in non-dynamic mode. Then if MXDM is present,
check whether it reports that the mux is in dynamic mode. For (1), only
query the WMI-wrapped API to determine the backlight control source if
the mux is in dynamic mode. For (2), only force the backlight to native
if the mux is not in dynamic mode.

This, again, assumes that none of the systems which require the quirk
report that the mux is in dynamic mode. If any of them do, we will need
to find a different way to determine which systems are lying about how
the backlight is supposed to be controlled.

> Regards,
> 
> Youssef
> 
> 
> On Tue, 17 Jan 2023 at 23:24, Daniel Dadap <ddadap@nvidia.com> wrote:
> >
> > Hans pointed out a crucial omission in the build instructions in a
> > different thread where I also shared this test module:
> >
> > On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > > Thanks, Hans.
> > >
> > > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > > > Hi All,
> > > >
> > > > On 1/11/23 10:51, Hans de Goede wrote:
> > > > > Hi,
> > > > >
> > > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > > > >> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > > > >>> Hi,
> > > > >>>
> > > > >>> On 1/10/23 16:19, Youssef Aly wrote:
> > > > >>>> Hi Hans,
> > > > >>>>
> > > > >>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > > >>>> the kernel commandline for the patched kernel, it doesn't work without it.
> > > > >>>>
> > > > >>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > > >>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > > >>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> > > > >>>>
> > > > >>>> Hybrid:
> > > > >>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > > >>>> amdgpu_bl1.
> > > > >>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > > >>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > > > >>>>
> > > > >>>> Discrete:
> > > > >>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > > >>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > > >>>> same as 80, etc... ,
> > > > >>>> /sys/class/backlight contains nvidia_0.
> > > > >>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > > >>>> contains nvidia_wmi_ec_backlight.
> > > > >>>
> > > > >>> Thank you for testing!
> > > > >>>
> > > > >>> Ok so it seems there are 2 issues at play here:
> > > > >>>
> > > > >>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > > >>>    or nvidia_wmi_ec (hybrid mode)
> > > > >>>
> > > > >>> 2. There is a bug in the nvidia binary drivers backlight control in native
> > > > >>>    mode on this system causing the range to be wrong
> > > > >>>
> > > > >>> Daniel, we really need help from NVidia with fixing 1. can you see if
> > > > >>> there is a way to check the BIOS setting/mode from inside the kernel ?
> > > > >>
> > > > >> Yes, the ACPI MXDM method should be able to do this. However, querying
> > > > >> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > > >> determine whether the backlight is supposed to be EC-driven, since there
> > > > >> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > > >> be orthogonal to whether or not the EC driver should be used. It sounds
> > > > >> like the BIOS is possibly reporting a wrong value for that query.
> > > > >>
> > > > >> I guess we could wire up a quirk that checks MXDM and overrides the
> > > > >> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > > >> mux operation mode. Then that quirk could be applied to this system.
> > > > >> I can put together a patch for that.
> > > > >
> > > > > If you can write a patch for this that would be great, thank you,
> > > > > but I think we first need to root-cause this better:
> > > > >
> > > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > > to always use the native backlight. So I've gone back to the original email
> > > > > thread which lead to me adding that quirk.
> > > > >
> > > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > > did ask to test with different BIOS settings their to and the reporter's
> > > > > reply was:
> > > > >
> > > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > > > >
> > > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > > device and in Youssef's case the amdgpu_bl# device never works.
> > > > >
> > > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > > > >
> > > > > While the dGPU can be one of:
> > > > > NVIDIA GeForce RTX 3060
> > > > > NVIDIA GeForce GTX 3050 Ti
> > > > > NVIDIA GeForce GTX 3050
> > > > >
> > > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > > maybe not load at all on the model with the 3050 versions.
> > > >
> > > > A quick status update on this.
> > > >
> > > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > > gotten back to me with lspci output on their G15 and it indeed has
> > > > a GTX 3050.
> > > >
> > > > So atm we have the following models which are affected one way
> > > > or the other:
> > > >
> > > >   -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 :(
> > > >
> > > > With the models which need acpi_backlight=native being broken
> > > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > > for backlight control while they actually should not be using that.
> > > >
> > > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > >
> > > I've attached a simple kernel module which adds a debugfs file that
> > > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > > systems which need the quirk may be in one of the non-dynamic modes, and
> > > the systems which are broken by the quirk may be in dynamic mux mode. It
> > > should be pretty straightforward to compile this as an out-of-tree
> > > module using the Kbuild extmod infrastructure, as follows:
> > >
> > > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> > >    wish to create an empty directory to put it in) and create a file in
> > >    that directory containing the following line:
> >
> > The name of this file should be 'Kbuild'. Sorry for the noise.
> >
> > >    obj-m += mxdm-debugfs.o
> > >
> > > 2) Build the kernel module:
> > >
> > >    make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> > >
> > >    (The "source" and "build" paths under /lib/modules/`uname -r` should
> > >    be the correct paths in almost all cases; if your system uses
> > >    different paths, substitute those. You will need the development
> > >    headers for external kernel modules, and the relevant toolchain bits,
> > >    but if you're already using the NVIDIA proprietary driver you almost
> > >    certainly already have all of that.)
> > >
> > > 3) Load the kernel module:
> > >
> > >    insmod ./mxdm-debugfs.ko
> > >
> > > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > > Reading this file should report the current mux operation mode.
> > >
> > > While switching mux modes on a dynamic mux system to test this kernel
> > > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > > when the mux mode was set to discrete only on that particular system.
> > > This contradicted the behavior I had previously observed on other
> > > systems; i.e., that MXDM is always available regardless of the currently
> > > set mux mode, so I tried it on another dynamic mux system and observed
> > > that the other system does always expose MXDM regardless of the mux
> > > mode, and the contents of the debugfs file matched the selected mode.
> > >
> > > So if the module fails to load with ENODEV and prints the "MXDM not
> > > found" message to the kernel log, the system is most likely configured
> > > to a non-dynamic mux mode. My usual expectation is that it should load
> > > and create the file on most dynamic mux systems. I do not have direct
> > > access to any of the above listed systems at the moment, so I do not
> > > know whether MXDM will be exposed when the system is not in dynamic mux
> > > mode.
> > >
> > > > Regards,
> > > >
> > > > Hans
> > > >
> >
> > > // SPDX-License-Identifier: GPL-2.0-only
> > > /*
> > >  * Copyright (C) 2020 NVIDIA Corporation
> > >  *
> > >  */
> > >
> > > #include <linux/acpi.h>
> > > #include <acpi/acoutput.h>
> > > #include <linux/module.h>
> > > #include <linux/pci.h>
> > > #include <linux/debugfs.h>
> > >
> > > extern struct dentry *acpi_debugfs_dir;
> > >
> > > enum mux_mode {
> > >       MUX_MODE_UNKNOWN = 0,
> > >       MUX_MODE_INTEGRATED = 1, /* iGPU only */
> > >       MUX_MODE_DISCRETE = 2,   /* dGPU only */
> > >       MUX_MODE_HYBRID = 3,     /* Dual GPU, mux switched to iGPU */
> > >       MUX_MODE_DYNAMIC = 4,    /* Dual GPU, dynamic mux switching */
> > >       MUX_MODE_MAX
> > > };
> > >
> > > static char * mode_names[] = {
> > >       [MUX_MODE_UNKNOWN] = "unknown\n",
> > >       [MUX_MODE_INTEGRATED] = "integrated\n",
> > >       [MUX_MODE_DISCRETE] = "discrete\n",
> > >       [MUX_MODE_HYBRID] = "hybrid\n",
> > >       [MUX_MODE_DYNAMIC] = "dynamic\n",
> > > };
> > >
> > > static struct debugfs_blob_wrapper muxmode_blob;
> > >
> > > static void store_mux_mode(acpi_handle handle)
> > > {
> > >       union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> > >       struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > >
> > >       acpi_integer ret;
> > >       acpi_status status;
> > >
> > >       status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > >
> > >       if (ACPI_FAILURE(status)) {
> > >               acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> > >               muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > >       } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > >               acpi_handle_err(handle, "Mux mode value out of range");
> > >               muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > >       } else {
> > >               muxmode_blob.data = mode_names[ret];
> > >       }
> > >
> > >       muxmode_blob.size = strlen(muxmode_blob.data);
> > > }
> > >
> > > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > > {
> > >       acpi_handle search;
> > >
> > >       if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > >               /* Found the parent object of the MXDM method; pass it back
> > >                * to the caller and stop searching. */
> > >               *ret = obj;
> > >
> > >               return AE_CTRL_TERMINATE;
> > >       }
> > >
> > >       /* No MXDM; keep looking */
> > >       return AE_OK;
> > > }
> > >
> > > static struct dentry *muxmode_file_dentry;
> > >
> > > static int __init mxdm_debugfs_init(void)
> > > {
> > >       acpi_handle mxdm_handle = NULL;
> > >       acpi_status ret;
> > >
> > >       ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > >                                         find_mxdm, NULL, NULL, &mxdm_handle);
> > >
> > >       if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > >               pr_err("MXDM not found.\n");
> > >               return -ENODEV;
> > >       }
> > >
> > >     /* Populate the blob wrapper: the mux mode cannot change without rebooting
> > >      * so this only needs to be done once. */
> > >       store_mux_mode(mxdm_handle);
> > >
> > >       muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > >                                                 acpi_debugfs_dir,
> > >                                                 &muxmode_blob);
> > >
> > >       return muxmode_file_dentry ? 0 : -EIO;
> > > }
> > > module_init(mxdm_debugfs_init);
> > >
> > > static void __exit mxdm_debugfs_exit(void)
> > > {
> > >       if (muxmode_file_dentry) {
> > >               debugfs_remove(muxmode_file_dentry);
> > >               muxmode_file_dentry = NULL;
> > >       }
> > > }
> > > module_exit(mxdm_debugfs_exit);
> > >
> > > MODULE_LICENSE("GPL v2");
> > > MODULE_DESCRIPTION("MXDM mux mode test module");
> > > MODULE_AUTHOR("Daniel Dadap <ddadap@nvidia.com>");
> > >
> > > /*
> > >  * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> > >  * the WMI wrapper for the related WMAA method for backlight control.
> > >  */
> > > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
> >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Iris]

[-- Attachment #1.1: Type: text/plain, Size: 18323 bytes --]

I have followed Youssef's instructions to build the module, and after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"

As mentioned before, this RTX 3050 system does not have configurable GPU mode.

------- Original Message -------
On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap <ddadap@nvidia.com> wrote:


> On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> 

> > Hello Daniel,
> > 

> > I tried building the module using the instructions you provided, but
> > ran into some problems as I didn't have the /lib/modules/$(uname
> > -r)/source directory on my end.
> > I created a Makefile in a directory containing mxdm-debugfs.c file and
> > added the following to it:
> > 

> > obj-m += mxdm-debugfs.o
> > 

> > all:
> > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> > 

> > clean:
> > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > 

> > I then ran "make" and loaded the module.
> 

> 

> Ah, yes, I should have mentioned specifically that the instructions
> assumed either a split Kbuild configuration with separate source and
> output directories, or a single combined source and output directory but
> with "source" and "build" both being symlinks to the same directory. I
> forget which distros do what exactly, but some ship a combined
> source/output directory but only have one of either "source" or "build";
> yours appears to be the latter configuration. I'm glad you were able to
> get it building anyway.
> 

> > 1) Hybrid mode set to "Enabled" from the bios settings,
> > /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> > 2) Hybrid mode set to "Disabled" from the bios settings,
> > /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> 

> 

> Okay. This is consistent with my expectations. If we also find that the
> systems which require the quirk report either "discrete", "hybrid", or
> "integrated" (IIUC those systems do not have the mode configurable in the
> UEFI settings), then I think we can fix the quirk by checking the mux
> mode and only forcing to native if the system is not in hybrid mode.
> 

> Or perhaps we should just get rid of the quirk, and unconditionally test
> the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
> are not in "dynamic" mode, regardless of whether they expose the WMI EC
> backlight interface and regardless of whether that interface reports
> that the EC backlight driver should be used. (On the systems that need
> the quirk, that interface is reporting that the backlight should be
> EC-controlled even when it shouldn't be.) I think that in theory, it
> should be possible for a system design to require EC backlight control
> even when the mux is in a non-dynamic mode, but in practice I don't know
> why anybody would do that, and am not aware of any systems which do so
> (although until the report of the broken backlight on the 3050 version
> of the Dell G15 5515, I wasn't aware of any systems that reported EC
> backlight control when it was supposed to be native.)
> 

> Hans, I think the most reasonable options are:
> 

> 1) Remove the quirk, and check for MXDM when deciding whether a system
> should use the EC backlight driver. This has the disadvantage of adding
> a check where one isn't actually needed on some (most?) systems, and the
> advantage of most likely avoiding the need to add quirks for other
> systems where the system reports EC backlight control when native should
> be used. It also has the possibility of being wrong on a theoretically
> possible configuration, although if we ever encounter such a
> configuration we could handle it with a quirk or find some other way to
> distinguish between systems that do or do not require the EC backlight
> driver.
> 

> 2) Keep the existing quirk, and only force to native if MXDM is missing
> or if MXDM reports that the system is in a non-dynamic mode.
> 

> I'm inclined to go with (2), because it seems "safer", but am happy to
> implement (1) if you think that's the better option. For the MXDM check
> I think the first thing to do is to check whether the MXDM method is
> present at all: as observed on at least one system, there is no MXDM
> method when the system is in non-dynamic mode. Then if MXDM is present,
> check whether it reports that the mux is in dynamic mode. For (1), only
> query the WMI-wrapped API to determine the backlight control source if
> the mux is in dynamic mode. For (2), only force the backlight to native
> if the mux is not in dynamic mode.
> 

> This, again, assumes that none of the systems which require the quirk
> report that the mux is in dynamic mode. If any of them do, we will need
> to find a different way to determine which systems are lying about how
> the backlight is supposed to be controlled.
> 

> > Regards,
> > 

> > Youssef
> > 

> > On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com wrote:
> > 

> > > Hans pointed out a crucial omission in the build instructions in a
> > > different thread where I also shared this test module:
> > > 

> > > On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > > 

> > > > Thanks, Hans.
> > > > 

> > > > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > > > 

> > > > > Hi All,
> > > > > 

> > > > > On 1/11/23 10:51, Hans de Goede wrote:
> > > > > 

> > > > > > Hi,
> > > > > > 

> > > > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > > > > > 

> > > > > > > On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > > > > > > 

> > > > > > > > Hi,
> > > > > > > > 

> > > > > > > > On 1/10/23 16:19, Youssef Aly wrote:
> > > > > > > > 

> > > > > > > > > Hi Hans,
> > > > > > > > > 

> > > > > > > > > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > > > > > > > the kernel commandline for the patched kernel, it doesn't work without it.
> > > > > > > > > 

> > > > > > > > > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > > > > > > > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > > > > > > > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > > > > > > > > 

> > > > > > > > > Hybrid:
> > > > > > > > > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > > > > > > > amdgpu_bl1.
> > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > > > > > > > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > > > > > > > > 

> > > > > > > > > Discrete:
> > > > > > > > > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > > > > > > > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > > > > > > > same as 80, etc... ,
> > > > > > > > > /sys/class/backlight contains nvidia_0.
> > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > > > > > > > contains nvidia_wmi_ec_backlight.
> > > > > > > > 

> > > > > > > > Thank you for testing!
> > > > > > > > 

> > > > > > > > Ok so it seems there are 2 issues at play here:
> > > > > > > > 

> > > > > > > > 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > > > > > > or nvidia_wmi_ec (hybrid mode)
> > > > > > > > 

> > > > > > > > 2. There is a bug in the nvidia binary drivers backlight control in native
> > > > > > > > mode on this system causing the range to be wrong
> > > > > > > > 

> > > > > > > > Daniel, we really need help from NVidia with fixing 1. can you see if
> > > > > > > > there is a way to check the BIOS setting/mode from inside the kernel ?
> > > > > > > 

> > > > > > > Yes, the ACPI MXDM method should be able to do this. However, querying
> > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > > > > > determine whether the backlight is supposed to be EC-driven, since there
> > > > > > > are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > > > > > be orthogonal to whether or not the EC driver should be used. It sounds
> > > > > > > like the BIOS is possibly reporting a wrong value for that query.
> > > > > > > 

> > > > > > > I guess we could wire up a quirk that checks MXDM and overrides the
> > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > > > > > mux operation mode. Then that quirk could be applied to this system.
> > > > > > > I can put together a patch for that.
> > > > > > 

> > > > > > If you can write a patch for this that would be great, thank you,
> > > > > > but I think we first need to root-cause this better:
> > > > > > 

> > > > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > > > to always use the native backlight. So I've gone back to the original email
> > > > > > thread which lead to me adding that quirk.
> > > > > > 

> > > > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > > > did ask to test with different BIOS settings their to and the reporter's
> > > > > > reply was:
> > > > > > 

> > > > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > > > > > 

> > > > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > > > device and in Youssef's case the amdgpu_bl# device never works.
> > > > > > 

> > > > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > > > > > 

> > > > > > While the dGPU can be one of:
> > > > > > NVIDIA GeForce RTX 3060
> > > > > > NVIDIA GeForce GTX 3050 Ti
> > > > > > NVIDIA GeForce GTX 3050
> > > > > > 

> > > > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > > > maybe not load at all on the model with the 3050 versions.
> > > > > 

> > > > > A quick status update on this.
> > > > > 

> > > > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > > > gotten back to me with lspci output on their G15 and it indeed has
> > > > > a GTX 3050.
> > > > > 

> > > > > So atm we have the following models which are affected one way
> > > > > or the other:
> > > > > 

> > > > > -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 :(
> > > > > 

> > > > > With the models which need acpi_backlight=native being broken
> > > > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > > > for backlight control while they actually should not be using that.
> > > > > 

> > > > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > > > 

> > > > I've attached a simple kernel module which adds a debugfs file that
> > > > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > > > systems which need the quirk may be in one of the non-dynamic modes, and
> > > > the systems which are broken by the quirk may be in dynamic mux mode. It
> > > > should be pretty straightforward to compile this as an out-of-tree
> > > > module using the Kbuild extmod infrastructure, as follows:
> > > > 

> > > > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> > > > wish to create an empty directory to put it in) and create a file in
> > > > that directory containing the following line:
> > > 

> > > The name of this file should be 'Kbuild'. Sorry for the noise.
> > > 

> > > > obj-m += mxdm-debugfs.o
> > > > 

> > > > 2) Build the kernel module:
> > > > 

> > > > make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> > > > 

> > > > (The "source" and "build" paths under /lib/modules/`uname -r` should
> > > > be the correct paths in almost all cases; if your system uses
> > > > different paths, substitute those. You will need the development
> > > > headers for external kernel modules, and the relevant toolchain bits,
> > > > but if you're already using the NVIDIA proprietary driver you almost
> > > > certainly already have all of that.)
> > > > 

> > > > 3) Load the kernel module:
> > > > 

> > > > insmod ./mxdm-debugfs.ko
> > > > 

> > > > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > > > Reading this file should report the current mux operation mode.
> > > > 

> > > > While switching mux modes on a dynamic mux system to test this kernel
> > > > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > > > when the mux mode was set to discrete only on that particular system.
> > > > This contradicted the behavior I had previously observed on other
> > > > systems; i.e., that MXDM is always available regardless of the currently
> > > > set mux mode, so I tried it on another dynamic mux system and observed
> > > > that the other system does always expose MXDM regardless of the mux
> > > > mode, and the contents of the debugfs file matched the selected mode.
> > > > 

> > > > So if the module fails to load with ENODEV and prints the "MXDM not
> > > > found" message to the kernel log, the system is most likely configured
> > > > to a non-dynamic mux mode. My usual expectation is that it should load
> > > > and create the file on most dynamic mux systems. I do not have direct
> > > > access to any of the above listed systems at the moment, so I do not
> > > > know whether MXDM will be exposed when the system is not in dynamic mux
> > > > mode.
> > > > 

> > > > > Regards,
> > > > > 

> > > > > Hans
> > > 

> > > > // SPDX-License-Identifier: GPL-2.0-only
> > > > /*
> > > > * Copyright (C) 2020 NVIDIA Corporation
> > > > *
> > > > */
> > > > 

> > > > #include <linux/acpi.h>
> > > > #include <acpi/acoutput.h>
> > > > #include <linux/module.h>
> > > > #include <linux/pci.h>
> > > > #include <linux/debugfs.h>
> > > > 

> > > > extern struct dentry *acpi_debugfs_dir;
> > > > 

> > > > enum mux_mode {
> > > > MUX_MODE_UNKNOWN = 0,
> > > > MUX_MODE_INTEGRATED = 1, /* iGPU only /
> > > > MUX_MODE_DISCRETE = 2, / dGPU only /
> > > > MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> > > > MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> > > > MUX_MODE_MAX
> > > > };
> > > > 

> > > > static char * mode_names[] = {
> > > > [MUX_MODE_UNKNOWN] = "unknown\n",
> > > > [MUX_MODE_INTEGRATED] = "integrated\n",
> > > > [MUX_MODE_DISCRETE] = "discrete\n",
> > > > [MUX_MODE_HYBRID] = "hybrid\n",
> > > > [MUX_MODE_DYNAMIC] = "dynamic\n",
> > > > };
> > > > 

> > > > static struct debugfs_blob_wrapper muxmode_blob;
> > > > 

> > > > static void store_mux_mode(acpi_handle handle)
> > > > {
> > > > union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> > > > struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > > > 

> > > > acpi_integer ret;
> > > > acpi_status status;
> > > > 

> > > > status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > > > 

> > > > if (ACPI_FAILURE(status)) {
> > > > acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > > > acpi_handle_err(handle, "Mux mode value out of range");
> > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > } else {
> > > > muxmode_blob.data = mode_names[ret];
> > > > }
> > > > 

> > > > muxmode_blob.size = strlen(muxmode_blob.data);
> > > > }
> > > > 

> > > > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > > > {
> > > > acpi_handle search;
> > > > 

> > > > if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > > > /* Found the parent object of the MXDM method; pass it back
> > > > * to the caller and stop searching. */
> > > > *ret = obj;
> > > > 

> > > > return AE_CTRL_TERMINATE;
> > > > }
> > > > 

> > > > /* No MXDM; keep looking */
> > > > return AE_OK;
> > > > }
> > > > 

> > > > static struct dentry *muxmode_file_dentry;
> > > > 

> > > > static int __init mxdm_debugfs_init(void)
> > > > {
> > > > acpi_handle mxdm_handle = NULL;
> > > > acpi_status ret;
> > > > 

> > > > ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > > > find_mxdm, NULL, NULL, &mxdm_handle);
> > > > 

> > > > if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > > > pr_err("MXDM not found.\n");
> > > > return -ENODEV;
> > > > }
> > > > 

> > > > /* Populate the blob wrapper: the mux mode cannot change without rebooting
> > > > * so this only needs to be done once. */
> > > > store_mux_mode(mxdm_handle);
> > > > 

> > > > muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > > > acpi_debugfs_dir,
> > > > &muxmode_blob);
> > > > 

> > > > return muxmode_file_dentry ? 0 : -EIO;
> > > > }
> > > > module_init(mxdm_debugfs_init);
> > > > 

> > > > static void __exit mxdm_debugfs_exit(void)
> > > > {
> > > > if (muxmode_file_dentry) {
> > > > debugfs_remove(muxmode_file_dentry);
> > > > muxmode_file_dentry = NULL;
> > > > }
> > > > }
> > > > module_exit(mxdm_debugfs_exit);
> > > > 

> > > > MODULE_LICENSE("GPL v2");
> > > > MODULE_DESCRIPTION("MXDM mux mode test module");
> > > > MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> > > > 

> > > > /*
> > > > * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> > > > * the WMI wrapper for the related WMAA method for backlight control.
> > > > */
> > > > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

[-- Attachment #1: Type: text/plain, Size: 21015 bytes --]

Thanks, Iris:

On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
> I have followed Youssef's instructions to build the module, and after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"

That is unfortunate. I was hoping it would report a non-dynamic mode, which
would make it easier to disambiguate between G15 5515 models which require
EC backlight control and G15 5515 models which require native GPU-driven
backlight control.

I have attached an updated version of the test module which will allow you 
to test if your system does have a dynamic mux. Build and load it the same
way as the previous one (unload the previous one first if you haven't done
so or rebooted already). This adds /sys/kernel/debug/acpi/mxds_mux_state: if
you see this file, read out its contents. I expect that on your system it
should report "integrated", since IIUC the amdgpu_bl backlight device is the
one that works on your system. If you do not see this file, and the message
"MXDS not found" appears in your kernel log, then your ACPI table doesn't
expose the MXDS method, which could be a useful disambiguation test.

Another experiment to try would be to flip the state of the mux. Before
attempting this experiment, make sure to save any work and log in remotely
from another machine, since it is possible that your screen will go blank
and will need a reboot in order to come back up. To change the mux state,
write the target mux state to the mxds_mux_state file. Use whatever the
opposite of the current value is, i.e., if it reads out as "integrated",
then write "discrete", and vice versa. If the mux switch worked, your
screen should go blank and reading the mxds_mux_state file again should
reflect the new state. You can then flip the mux back to its original
position, and you *should* be able to get the display back by forcing
DPMS off and then on again. If you're not running X, writing a '0' then
writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems to
work on my AMD+NVIDIA system. (The DRI device and eDP connector ID might
be enumerated differently on your system.) If neither of those work to
bring your display back up, then reboot the computer.

The most interesting data would be to check whether MXDS is available in
your system's ACPI tables, and if so, whether it is actually functional.

> As mentioned before, this RTX 3050 system does not have configurable GPU mode.
> 
> ------- Original Message -------
> On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap <ddadap@nvidia.com> wrote:
> 
> 
> > On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> > 
> 
> > > Hello Daniel,
> > > 
> 
> > > I tried building the module using the instructions you provided, but
> > > ran into some problems as I didn't have the /lib/modules/$(uname
> > > -r)/source directory on my end.
> > > I created a Makefile in a directory containing mxdm-debugfs.c file and
> > > added the following to it:
> > > 
> 
> > > obj-m += mxdm-debugfs.o
> > > 
> 
> > > all:
> > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> > > 
> 
> > > clean:
> > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > > 
> 
> > > I then ran "make" and loaded the module.
> > 
> 
> > 
> 
> > Ah, yes, I should have mentioned specifically that the instructions
> > assumed either a split Kbuild configuration with separate source and
> > output directories, or a single combined source and output directory but
> > with "source" and "build" both being symlinks to the same directory. I
> > forget which distros do what exactly, but some ship a combined
> > source/output directory but only have one of either "source" or "build";
> > yours appears to be the latter configuration. I'm glad you were able to
> > get it building anyway.
> > 
> 
> > > 1) Hybrid mode set to "Enabled" from the bios settings,
> > > /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> > > 2) Hybrid mode set to "Disabled" from the bios settings,
> > > /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> > 
> 
> > 
> 
> > Okay. This is consistent with my expectations. If we also find that the
> > systems which require the quirk report either "discrete", "hybrid", or
> > "integrated" (IIUC those systems do not have the mode configurable in the
> > UEFI settings), then I think we can fix the quirk by checking the mux
> > mode and only forcing to native if the system is not in hybrid mode.
> > 
> 
> > Or perhaps we should just get rid of the quirk, and unconditionally test
> > the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
> > are not in "dynamic" mode, regardless of whether they expose the WMI EC
> > backlight interface and regardless of whether that interface reports
> > that the EC backlight driver should be used. (On the systems that need
> > the quirk, that interface is reporting that the backlight should be
> > EC-controlled even when it shouldn't be.) I think that in theory, it
> > should be possible for a system design to require EC backlight control
> > even when the mux is in a non-dynamic mode, but in practice I don't know
> > why anybody would do that, and am not aware of any systems which do so
> > (although until the report of the broken backlight on the 3050 version
> > of the Dell G15 5515, I wasn't aware of any systems that reported EC
> > backlight control when it was supposed to be native.)
> > 
> 
> > Hans, I think the most reasonable options are:
> > 
> 
> > 1) Remove the quirk, and check for MXDM when deciding whether a system
> > should use the EC backlight driver. This has the disadvantage of adding
> > a check where one isn't actually needed on some (most?) systems, and the
> > advantage of most likely avoiding the need to add quirks for other
> > systems where the system reports EC backlight control when native should
> > be used. It also has the possibility of being wrong on a theoretically
> > possible configuration, although if we ever encounter such a
> > configuration we could handle it with a quirk or find some other way to
> > distinguish between systems that do or do not require the EC backlight
> > driver.
> > 
> 
> > 2) Keep the existing quirk, and only force to native if MXDM is missing
> > or if MXDM reports that the system is in a non-dynamic mode.
> > 
> 
> > I'm inclined to go with (2), because it seems "safer", but am happy to
> > implement (1) if you think that's the better option. For the MXDM check
> > I think the first thing to do is to check whether the MXDM method is
> > present at all: as observed on at least one system, there is no MXDM
> > method when the system is in non-dynamic mode. Then if MXDM is present,
> > check whether it reports that the mux is in dynamic mode. For (1), only
> > query the WMI-wrapped API to determine the backlight control source if
> > the mux is in dynamic mode. For (2), only force the backlight to native
> > if the mux is not in dynamic mode.
> > 
> 
> > This, again, assumes that none of the systems which require the quirk
> > report that the mux is in dynamic mode. If any of them do, we will need
> > to find a different way to determine which systems are lying about how
> > the backlight is supposed to be controlled.
> > 
> 
> > > Regards,
> > > 
> 
> > > Youssef
> > > 
> 
> > > On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com wrote:
> > > 
> 
> > > > Hans pointed out a crucial omission in the build instructions in a
> > > > different thread where I also shared this test module:
> > > > 
> 
> > > > On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > > > 
> 
> > > > > Thanks, Hans.
> > > > > 
> 
> > > > > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > > > > 
> 
> > > > > > Hi All,
> > > > > > 
> 
> > > > > > On 1/11/23 10:51, Hans de Goede wrote:
> > > > > > 
> 
> > > > > > > Hi,
> > > > > > > 
> 
> > > > > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > > > > > > 
> 
> > > > > > > > On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > > > > > > > 
> 
> > > > > > > > > Hi,
> > > > > > > > > 
> 
> > > > > > > > > On 1/10/23 16:19, Youssef Aly wrote:
> > > > > > > > > 
> 
> > > > > > > > > > Hi Hans,
> > > > > > > > > > 
> 
> > > > > > > > > > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > > > > > > > > the kernel commandline for the patched kernel, it doesn't work without it.
> > > > > > > > > > 
> 
> > > > > > > > > > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > > > > > > > > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > > > > > > > > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > > > > > > > > > 
> 
> > > > > > > > > > Hybrid:
> > > > > > > > > > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > > > > > > > > amdgpu_bl1.
> > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > > > > > > > > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > > > > > > > > > 
> 
> > > > > > > > > > Discrete:
> > > > > > > > > > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > > > > > > > > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > > > > > > > > same as 80, etc... ,
> > > > > > > > > > /sys/class/backlight contains nvidia_0.
> > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > > > > > > > > contains nvidia_wmi_ec_backlight.
> > > > > > > > > 
> 
> > > > > > > > > Thank you for testing!
> > > > > > > > > 
> 
> > > > > > > > > Ok so it seems there are 2 issues at play here:
> > > > > > > > > 
> 
> > > > > > > > > 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > > > > > > > or nvidia_wmi_ec (hybrid mode)
> > > > > > > > > 
> 
> > > > > > > > > 2. There is a bug in the nvidia binary drivers backlight control in native
> > > > > > > > > mode on this system causing the range to be wrong
> > > > > > > > > 
> 
> > > > > > > > > Daniel, we really need help from NVidia with fixing 1. can you see if
> > > > > > > > > there is a way to check the BIOS setting/mode from inside the kernel ?
> > > > > > > > 
> 
> > > > > > > > Yes, the ACPI MXDM method should be able to do this. However, querying
> > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > > > > > > determine whether the backlight is supposed to be EC-driven, since there
> > > > > > > > are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > > > > > > be orthogonal to whether or not the EC driver should be used. It sounds
> > > > > > > > like the BIOS is possibly reporting a wrong value for that query.
> > > > > > > > 
> 
> > > > > > > > I guess we could wire up a quirk that checks MXDM and overrides the
> > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > > > > > > mux operation mode. Then that quirk could be applied to this system.
> > > > > > > > I can put together a patch for that.
> > > > > > > 
> 
> > > > > > > If you can write a patch for this that would be great, thank you,
> > > > > > > but I think we first need to root-cause this better:
> > > > > > > 
> 
> > > > > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > > > > to always use the native backlight. So I've gone back to the original email
> > > > > > > thread which lead to me adding that quirk.
> > > > > > > 
> 
> > > > > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > > > > did ask to test with different BIOS settings their to and the reporter's
> > > > > > > reply was:
> > > > > > > 
> 
> > > > > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > > > > > > 
> 
> > > > > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > > > > device and in Youssef's case the amdgpu_bl# device never works.
> > > > > > > 
> 
> > > > > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > > > > > > 
> 
> > > > > > > While the dGPU can be one of:
> > > > > > > NVIDIA GeForce RTX 3060
> > > > > > > NVIDIA GeForce GTX 3050 Ti
> > > > > > > NVIDIA GeForce GTX 3050
> > > > > > > 
> 
> > > > > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > > > > maybe not load at all on the model with the 3050 versions.
> > > > > > 
> 
> > > > > > A quick status update on this.
> > > > > > 
> 
> > > > > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > > > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > > > > gotten back to me with lspci output on their G15 and it indeed has
> > > > > > a GTX 3050.
> > > > > > 
> 
> > > > > > So atm we have the following models which are affected one way
> > > > > > or the other:
> > > > > > 
> 
> > > > > > -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 :(
> > > > > > 
> 
> > > > > > With the models which need acpi_backlight=native being broken
> > > > > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > > > > for backlight control while they actually should not be using that.
> > > > > > 
> 
> > > > > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > > > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > > > > 
> 
> > > > > I've attached a simple kernel module which adds a debugfs file that
> > > > > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > > > > systems which need the quirk may be in one of the non-dynamic modes, and
> > > > > the systems which are broken by the quirk may be in dynamic mux mode. It
> > > > > should be pretty straightforward to compile this as an out-of-tree
> > > > > module using the Kbuild extmod infrastructure, as follows:
> > > > > 
> 
> > > > > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> > > > > wish to create an empty directory to put it in) and create a file in
> > > > > that directory containing the following line:
> > > > 
> 
> > > > The name of this file should be 'Kbuild'. Sorry for the noise.
> > > > 
> 
> > > > > obj-m += mxdm-debugfs.o
> > > > > 
> 
> > > > > 2) Build the kernel module:
> > > > > 
> 
> > > > > make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> > > > > 
> 
> > > > > (The "source" and "build" paths under /lib/modules/`uname -r` should
> > > > > be the correct paths in almost all cases; if your system uses
> > > > > different paths, substitute those. You will need the development
> > > > > headers for external kernel modules, and the relevant toolchain bits,
> > > > > but if you're already using the NVIDIA proprietary driver you almost
> > > > > certainly already have all of that.)
> > > > > 
> 
> > > > > 3) Load the kernel module:
> > > > > 
> 
> > > > > insmod ./mxdm-debugfs.ko
> > > > > 
> 
> > > > > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > > > > Reading this file should report the current mux operation mode.
> > > > > 
> 
> > > > > While switching mux modes on a dynamic mux system to test this kernel
> > > > > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > > > > when the mux mode was set to discrete only on that particular system.
> > > > > This contradicted the behavior I had previously observed on other
> > > > > systems; i.e., that MXDM is always available regardless of the currently
> > > > > set mux mode, so I tried it on another dynamic mux system and observed
> > > > > that the other system does always expose MXDM regardless of the mux
> > > > > mode, and the contents of the debugfs file matched the selected mode.
> > > > > 
> 
> > > > > So if the module fails to load with ENODEV and prints the "MXDM not
> > > > > found" message to the kernel log, the system is most likely configured
> > > > > to a non-dynamic mux mode. My usual expectation is that it should load
> > > > > and create the file on most dynamic mux systems. I do not have direct
> > > > > access to any of the above listed systems at the moment, so I do not
> > > > > know whether MXDM will be exposed when the system is not in dynamic mux
> > > > > mode.
> > > > > 
> 
> > > > > > Regards,
> > > > > > 
> 
> > > > > > Hans
> > > > 
> 
> > > > > // SPDX-License-Identifier: GPL-2.0-only
> > > > > /*
> > > > > * Copyright (C) 2020 NVIDIA Corporation
> > > > > *
> > > > > */
> > > > > 
> 
> > > > > #include <linux/acpi.h>
> > > > > #include <acpi/acoutput.h>
> > > > > #include <linux/module.h>
> > > > > #include <linux/pci.h>
> > > > > #include <linux/debugfs.h>
> > > > > 
> 
> > > > > extern struct dentry *acpi_debugfs_dir;
> > > > > 
> 
> > > > > enum mux_mode {
> > > > > MUX_MODE_UNKNOWN = 0,
> > > > > MUX_MODE_INTEGRATED = 1, /* iGPU only /
> > > > > MUX_MODE_DISCRETE = 2, / dGPU only /
> > > > > MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> > > > > MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> > > > > MUX_MODE_MAX
> > > > > };
> > > > > 
> 
> > > > > static char * mode_names[] = {
> > > > > [MUX_MODE_UNKNOWN] = "unknown\n",
> > > > > [MUX_MODE_INTEGRATED] = "integrated\n",
> > > > > [MUX_MODE_DISCRETE] = "discrete\n",
> > > > > [MUX_MODE_HYBRID] = "hybrid\n",
> > > > > [MUX_MODE_DYNAMIC] = "dynamic\n",
> > > > > };
> > > > > 
> 
> > > > > static struct debugfs_blob_wrapper muxmode_blob;
> > > > > 
> 
> > > > > static void store_mux_mode(acpi_handle handle)
> > > > > {
> > > > > union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> > > > > struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > > > > 
> 
> > > > > acpi_integer ret;
> > > > > acpi_status status;
> > > > > 
> 
> > > > > status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > > > > 
> 
> > > > > if (ACPI_FAILURE(status)) {
> > > > > acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > > > > acpi_handle_err(handle, "Mux mode value out of range");
> > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > } else {
> > > > > muxmode_blob.data = mode_names[ret];
> > > > > }
> > > > > 
> 
> > > > > muxmode_blob.size = strlen(muxmode_blob.data);
> > > > > }
> > > > > 
> 
> > > > > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > > > > {
> > > > > acpi_handle search;
> > > > > 
> 
> > > > > if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > > > > /* Found the parent object of the MXDM method; pass it back
> > > > > * to the caller and stop searching. */
> > > > > *ret = obj;
> > > > > 
> 
> > > > > return AE_CTRL_TERMINATE;
> > > > > }
> > > > > 
> 
> > > > > /* No MXDM; keep looking */
> > > > > return AE_OK;
> > > > > }
> > > > > 
> 
> > > > > static struct dentry *muxmode_file_dentry;
> > > > > 
> 
> > > > > static int __init mxdm_debugfs_init(void)
> > > > > {
> > > > > acpi_handle mxdm_handle = NULL;
> > > > > acpi_status ret;
> > > > > 
> 
> > > > > ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > > > > find_mxdm, NULL, NULL, &mxdm_handle);
> > > > > 
> 
> > > > > if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > > > > pr_err("MXDM not found.\n");
> > > > > return -ENODEV;
> > > > > }
> > > > > 
> 
> > > > > /* Populate the blob wrapper: the mux mode cannot change without rebooting
> > > > > * so this only needs to be done once. */
> > > > > store_mux_mode(mxdm_handle);
> > > > > 
> 
> > > > > muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > > > > acpi_debugfs_dir,
> > > > > &muxmode_blob);
> > > > > 
> 
> > > > > return muxmode_file_dentry ? 0 : -EIO;
> > > > > }
> > > > > module_init(mxdm_debugfs_init);
> > > > > 
> 
> > > > > static void __exit mxdm_debugfs_exit(void)
> > > > > {
> > > > > if (muxmode_file_dentry) {
> > > > > debugfs_remove(muxmode_file_dentry);
> > > > > muxmode_file_dentry = NULL;
> > > > > }
> > > > > }
> > > > > module_exit(mxdm_debugfs_exit);
> > > > > 
> 
> > > > > MODULE_LICENSE("GPL v2");
> > > > > MODULE_DESCRIPTION("MXDM mux mode test module");
> > > > > MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> > > > > 
> 
> > > > > /*
> > > > > * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> > > > > * the WMI wrapper for the related WMAA method for backlight control.
> > > > > */
> > > > > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");




[-- Attachment #2: mxdm-debugfs.c --]
[-- Type: text/x-csrc, Size: 5804 bytes --]

// SPDX-License-Identifier: GPL-2.0-only
/*
 * Copyright (C) 2023 NVIDIA Corporation
 */

#include <linux/acpi.h>
#include <linux/module.h>
#include <linux/debugfs.h>

extern struct dentry *acpi_debugfs_dir;

enum mux_val {
	MUX_VAL_UNKNOWN = 0,
	MUX_VAL_INTEGRATED = 1, /* iGPU only */
	MUX_VAL_DISCRETE = 2,   /* dGPU only */
	MUX_VAL_MAX_STATE,
	MUX_VAL_HYBRID = 3,     /* Dual GPU, mux switched to iGPU */
	MUX_VAL_DYNAMIC = 4,    /* Dual GPU, dynamic mux switching */
	MUX_VAL_MAX_MODE
};

static char * mux_val_names[] = {
	[MUX_VAL_UNKNOWN] = "unknown\n",
	[MUX_VAL_INTEGRATED] = "integrated\n",
	[MUX_VAL_DISCRETE] = "discrete\n",
	[MUX_VAL_HYBRID] = "hybrid\n",
	[MUX_VAL_DYNAMIC] = "dynamic\n",
};

/*
 * Call MXDM or MXDS with argument value 0 to read the current mode or state.
 * When reading, a return value of 1 means iGPU and 2 means dGPU.
 * Call MXDS with bit 0 set to change the current state.
 * When changing state, clear bit 4 for iGPU and set bit 4 for dGPU.
 */

enum mux_command {
	MUX_COMMAND_GET = 0,
	MUX_COMMAND_SET = 1,
};

#define SET_MUX_STATE(state) (MUX_COMMAND_SET | ((state - 1) << 4))

static struct debugfs_blob_wrapper muxmode_blob;

static acpi_status mux_acpi_eval(acpi_handle handle, char *method,
				 acpi_integer argval, acpi_integer *ret)
{
	union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER,
					       .value = argval } };
	struct acpi_object_list in = { .count = 1, .pointer = &arg };

	return acpi_evaluate_integer(handle, method, &in, ret);
}

static void store_mux_mode(acpi_handle handle)
{
	acpi_integer ret;
	acpi_status status;

	status = mux_acpi_eval(handle, "MXDM", MUX_COMMAND_GET, &ret);

	if (ACPI_FAILURE(status)) {
		acpi_handle_err(handle, "%s\n", acpi_format_exception(status));
		muxmode_blob.data = mux_val_names[MUX_VAL_UNKNOWN];
	} else if (ret < MUX_VAL_UNKNOWN || ret >= MUX_VAL_MAX_MODE) {
		acpi_handle_err(handle, "Mux mode value out of range");
		muxmode_blob.data = mux_val_names[MUX_VAL_UNKNOWN];
	} else {
		muxmode_blob.data = mux_val_names[ret];
	}

	muxmode_blob.size = strlen(muxmode_blob.data);
}

static acpi_status find_method(acpi_handle obj, u32 level, void *ctx, void **ret)
{
	acpi_handle search;
	char *method = ctx;

	if (acpi_get_handle(obj, method, &search) == 0) {
		/* Found the parent object of the method; pass it back
		 * to the caller and stop searching. */
		*ret = obj;

		return AE_CTRL_TERMINATE;
	}

	/* Not found; keep looking */
	return AE_OK;
}

static ssize_t mxds_read (struct file *f, char __user *buf, size_t len, loff_t *off)
{
	acpi_handle *mxds_h = file_inode(f)->i_private;
	size_t name_len, to_copy, copied;
	acpi_integer state;
	acpi_status status;

	if (!mxds_h) {
		return 0;
	}

	status = mux_acpi_eval(mxds_h, "MXDS", MUX_COMMAND_GET, &state);

	if (ACPI_FAILURE(status)) {
		acpi_handle_err(mxds_h, "%s\n", acpi_format_exception(status));
		return 0;
	}

	switch (state) {
	case MUX_VAL_DISCRETE: case MUX_VAL_INTEGRATED:
		break;
	default:
		acpi_handle_warn(mxds_h, "Read invalid mux state: %lld\n", state);
		state = MUX_VAL_UNKNOWN;
		break;
	}

	name_len = strlen(mux_val_names[state]);

	if (*off < 0 || *off > name_len) return 0;

	to_copy = name_len - *off;
	if (len < to_copy)
		to_copy = len;

	copied = to_copy - copy_to_user(buf, mux_val_names[state] + *off, to_copy);
	*off += copied;

	return copied;
}

static ssize_t mxds_write (struct file *f, const char __user *buf, size_t len, loff_t *off)
{
	acpi_handle *mxds_h = file_inode(f)->i_private;
	acpi_integer state, ret;
	acpi_status status;
	char c;

	if (!len || *off) return 0;

	if (copy_from_user(&c, buf, 1)) {
		acpi_handle_warn(mxds_h, "Failed to read new mux state\n");
		return 0;
	}

	switch (c) {
	case 'D': case 'd': case '0' + MUX_VAL_DISCRETE:
		state = MUX_VAL_DISCRETE;
		break;
	case 'I': case 'i': case '0' + MUX_VAL_INTEGRATED:
		state = MUX_VAL_INTEGRATED;
		break;
	default:
		acpi_handle_warn(mxds_h, "Invalid mux target state supplied\n");
		return 0;
	}

	status = mux_acpi_eval(mxds_h, "MXDS", SET_MUX_STATE(state), &ret);

	if (ACPI_FAILURE(status)) {
		acpi_handle_err(mxds_h, "%s\n", acpi_format_exception(status));
		return 0;
	}

	return len;
}

static struct file_operations muxstate_fops = {
	.read = mxds_read,
	.write = mxds_write,
};

static struct dentry *muxmode_file_dentry;
static struct dentry *muxstate_file_dentry;

static int __init mxdm_debugfs_init(void)
{
	acpi_handle mxdm_handle = NULL, mxds_handle = NULL;
	acpi_status ret;

	ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
				  find_method, NULL, "MXDM",
				  &mxdm_handle);

	if (ACPI_FAILURE(ret) || !mxdm_handle) {
		pr_err("MXDM not found.\n");
		return -ENODEV;
	}

	/* Populate the blob wrapper for mux mode: the mux mode cannot change
	 * without rebooting, so we only need to do this once. */
	store_mux_mode(mxdm_handle);

	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
			    find_method, NULL, "MXDS", &mxds_handle);

	muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
						  acpi_debugfs_dir,
						  &muxmode_blob);

	if (mxds_handle) {
		muxstate_file_dentry = debugfs_create_file("mxds_mux_state",
							   0644,
							   acpi_debugfs_dir,
							   mxds_handle,
							   &muxstate_fops);
	} else {
		pr_info("MXDS not found.\n");
	}

	return muxmode_file_dentry ? 0 : -EIO;
}
module_init(mxdm_debugfs_init);

static void __exit mxdm_debugfs_exit(void)
{
	if (muxmode_file_dentry) {
		debugfs_remove(muxmode_file_dentry);
		muxmode_file_dentry = NULL;
	}

	if (muxstate_file_dentry) {
		debugfs_remove(muxstate_file_dentry);
		muxstate_file_dentry = NULL;
	}
}
module_exit(mxdm_debugfs_exit);

MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("MXDM/MXDS mux mode/state test module");
MODULE_AUTHOR("Daniel Dadap <ddadap@nvidia.com>");

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Iris]

[-- Attachment #1.1: Type: text/plain, Size: 21935 bytes --]

After loading the updated module, /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".

Now, i ran the command
sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"

/sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my screen didn't turn off... I changed it back to integrated, then to discrete again, it seems like nothing happened, or did i do something wrong?


------- Original Message -------
On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <ddadap@nvidia.com> wrote:


> Thanks, Iris:
> 

> On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
> 

> > I have followed Youssef's instructions to build the module, and after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
> 

> 

> That is unfortunate. I was hoping it would report a non-dynamic mode, which
> would make it easier to disambiguate between G15 5515 models which require
> EC backlight control and G15 5515 models which require native GPU-driven
> backlight control.
> 

> I have attached an updated version of the test module which will allow you
> to test if your system does have a dynamic mux. Build and load it the same
> way as the previous one (unload the previous one first if you haven't done
> so or rebooted already). This adds /sys/kernel/debug/acpi/mxds_mux_state: if
> you see this file, read out its contents. I expect that on your system it
> should report "integrated", since IIUC the amdgpu_bl backlight device is the
> one that works on your system. If you do not see this file, and the message
> "MXDS not found" appears in your kernel log, then your ACPI table doesn't
> expose the MXDS method, which could be a useful disambiguation test.
> 

> Another experiment to try would be to flip the state of the mux. Before
> attempting this experiment, make sure to save any work and log in remotely
> from another machine, since it is possible that your screen will go blank
> and will need a reboot in order to come back up. To change the mux state,
> write the target mux state to the mxds_mux_state file. Use whatever the
> opposite of the current value is, i.e., if it reads out as "integrated",
> then write "discrete", and vice versa. If the mux switch worked, your
> screen should go blank and reading the mxds_mux_state file again should
> reflect the new state. You can then flip the mux back to its original
> position, and you should be able to get the display back by forcing
> DPMS off and then on again. If you're not running X, writing a '0' then
> writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems to
> work on my AMD+NVIDIA system. (The DRI device and eDP connector ID might
> be enumerated differently on your system.) If neither of those work to
> bring your display back up, then reboot the computer.
> 

> The most interesting data would be to check whether MXDS is available in
> your system's ACPI tables, and if so, whether it is actually functional.
> 

> > As mentioned before, this RTX 3050 system does not have configurable GPU mode.
> > 

> > ------- Original Message -------
> > On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap ddadap@nvidia.com wrote:
> > 

> > > On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> > 

> > > > Hello Daniel,
> > 

> > > > I tried building the module using the instructions you provided, but
> > > > ran into some problems as I didn't have the /lib/modules/$(uname
> > > > -r)/source directory on my end.
> > > > I created a Makefile in a directory containing mxdm-debugfs.c file and
> > > > added the following to it:
> > 

> > > > obj-m += mxdm-debugfs.o
> > 

> > > > all:
> > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> > 

> > > > clean:
> > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > 

> > > > I then ran "make" and loaded the module.
> > 

> > > Ah, yes, I should have mentioned specifically that the instructions
> > > assumed either a split Kbuild configuration with separate source and
> > > output directories, or a single combined source and output directory but
> > > with "source" and "build" both being symlinks to the same directory. I
> > > forget which distros do what exactly, but some ship a combined
> > > source/output directory but only have one of either "source" or "build";
> > > yours appears to be the latter configuration. I'm glad you were able to
> > > get it building anyway.
> > 

> > > > 1) Hybrid mode set to "Enabled" from the bios settings,
> > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> > > > 2) Hybrid mode set to "Disabled" from the bios settings,
> > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> > 

> > > Okay. This is consistent with my expectations. If we also find that the
> > > systems which require the quirk report either "discrete", "hybrid", or
> > > "integrated" (IIUC those systems do not have the mode configurable in the
> > > UEFI settings), then I think we can fix the quirk by checking the mux
> > > mode and only forcing to native if the system is not in hybrid mode.
> > 

> > > Or perhaps we should just get rid of the quirk, and unconditionally test
> > > the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
> > > are not in "dynamic" mode, regardless of whether they expose the WMI EC
> > > backlight interface and regardless of whether that interface reports
> > > that the EC backlight driver should be used. (On the systems that need
> > > the quirk, that interface is reporting that the backlight should be
> > > EC-controlled even when it shouldn't be.) I think that in theory, it
> > > should be possible for a system design to require EC backlight control
> > > even when the mux is in a non-dynamic mode, but in practice I don't know
> > > why anybody would do that, and am not aware of any systems which do so
> > > (although until the report of the broken backlight on the 3050 version
> > > of the Dell G15 5515, I wasn't aware of any systems that reported EC
> > > backlight control when it was supposed to be native.)
> > 

> > > Hans, I think the most reasonable options are:
> > 

> > > 1) Remove the quirk, and check for MXDM when deciding whether a system
> > > should use the EC backlight driver. This has the disadvantage of adding
> > > a check where one isn't actually needed on some (most?) systems, and the
> > > advantage of most likely avoiding the need to add quirks for other
> > > systems where the system reports EC backlight control when native should
> > > be used. It also has the possibility of being wrong on a theoretically
> > > possible configuration, although if we ever encounter such a
> > > configuration we could handle it with a quirk or find some other way to
> > > distinguish between systems that do or do not require the EC backlight
> > > driver.
> > 

> > > 2) Keep the existing quirk, and only force to native if MXDM is missing
> > > or if MXDM reports that the system is in a non-dynamic mode.
> > 

> > > I'm inclined to go with (2), because it seems "safer", but am happy to
> > > implement (1) if you think that's the better option. For the MXDM check
> > > I think the first thing to do is to check whether the MXDM method is
> > > present at all: as observed on at least one system, there is no MXDM
> > > method when the system is in non-dynamic mode. Then if MXDM is present,
> > > check whether it reports that the mux is in dynamic mode. For (1), only
> > > query the WMI-wrapped API to determine the backlight control source if
> > > the mux is in dynamic mode. For (2), only force the backlight to native
> > > if the mux is not in dynamic mode.
> > 

> > > This, again, assumes that none of the systems which require the quirk
> > > report that the mux is in dynamic mode. If any of them do, we will need
> > > to find a different way to determine which systems are lying about how
> > > the backlight is supposed to be controlled.
> > 

> > > > Regards,
> > 

> > > > Youssef
> > 

> > > > On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com wrote:
> > 

> > > > > Hans pointed out a crucial omission in the build instructions in a
> > > > > different thread where I also shared this test module:
> > 

> > > > > On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > 

> > > > > > Thanks, Hans.
> > 

> > > > > > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > 

> > > > > > > Hi All,
> > 

> > > > > > > On 1/11/23 10:51, Hans de Goede wrote:
> > 

> > > > > > > > Hi,
> > 

> > > > > > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > 

> > > > > > > > > On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > 

> > > > > > > > > > Hi,
> > 

> > > > > > > > > > On 1/10/23 16:19, Youssef Aly wrote:
> > 

> > > > > > > > > > > Hi Hans,
> > 

> > > > > > > > > > > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > > > > > > > > > the kernel commandline for the patched kernel, it doesn't work without it.
> > 

> > > > > > > > > > > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > > > > > > > > > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > > > > > > > > > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > 

> > > > > > > > > > > Hybrid:
> > > > > > > > > > > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > > > > > > > > > amdgpu_bl1.
> > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > > > > > > > > > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > 

> > > > > > > > > > > Discrete:
> > > > > > > > > > > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > > > > > > > > > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > > > > > > > > > same as 80, etc... ,
> > > > > > > > > > > /sys/class/backlight contains nvidia_0.
> > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > > > > > > > > > contains nvidia_wmi_ec_backlight.
> > 

> > > > > > > > > > Thank you for testing!
> > 

> > > > > > > > > > Ok so it seems there are 2 issues at play here:
> > 

> > > > > > > > > > 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > > > > > > > > or nvidia_wmi_ec (hybrid mode)
> > 

> > > > > > > > > > 2. There is a bug in the nvidia binary drivers backlight control in native
> > > > > > > > > > mode on this system causing the range to be wrong
> > 

> > > > > > > > > > Daniel, we really need help from NVidia with fixing 1. can you see if
> > > > > > > > > > there is a way to check the BIOS setting/mode from inside the kernel ?
> > 

> > > > > > > > > Yes, the ACPI MXDM method should be able to do this. However, querying
> > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > > > > > > > determine whether the backlight is supposed to be EC-driven, since there
> > > > > > > > > are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > > > > > > > be orthogonal to whether or not the EC driver should be used. It sounds
> > > > > > > > > like the BIOS is possibly reporting a wrong value for that query.
> > 

> > > > > > > > > I guess we could wire up a quirk that checks MXDM and overrides the
> > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > > > > > > > mux operation mode. Then that quirk could be applied to this system.
> > > > > > > > > I can put together a patch for that.
> > 

> > > > > > > > If you can write a patch for this that would be great, thank you,
> > > > > > > > but I think we first need to root-cause this better:
> > 

> > > > > > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > > > > > to always use the native backlight. So I've gone back to the original email
> > > > > > > > thread which lead to me adding that quirk.
> > 

> > > > > > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > > > > > did ask to test with different BIOS settings their to and the reporter's
> > > > > > > > reply was:
> > 

> > > > > > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > > > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > 

> > > > > > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > > > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > > > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > > > > > device and in Youssef's case the amdgpu_bl# device never works.
> > 

> > > > > > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > 

> > > > > > > > While the dGPU can be one of:
> > > > > > > > NVIDIA GeForce RTX 3060
> > > > > > > > NVIDIA GeForce GTX 3050 Ti
> > > > > > > > NVIDIA GeForce GTX 3050
> > 

> > > > > > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > > > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > > > > > maybe not load at all on the model with the 3050 versions.
> > 

> > > > > > > A quick status update on this.
> > 

> > > > > > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > > > > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > > > > > gotten back to me with lspci output on their G15 and it indeed has
> > > > > > > a GTX 3050.
> > 

> > > > > > > So atm we have the following models which are affected one way
> > > > > > > or the other:
> > 

> > > > > > > -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 :(
> > 

> > > > > > > With the models which need acpi_backlight=native being broken
> > > > > > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > > > > > for backlight control while they actually should not be using that.
> > 

> > > > > > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > > > > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > 

> > > > > > I've attached a simple kernel module which adds a debugfs file that
> > > > > > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > > > > > systems which need the quirk may be in one of the non-dynamic modes, and
> > > > > > the systems which are broken by the quirk may be in dynamic mux mode. It
> > > > > > should be pretty straightforward to compile this as an out-of-tree
> > > > > > module using the Kbuild extmod infrastructure, as follows:
> > 

> > > > > > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> > > > > > wish to create an empty directory to put it in) and create a file in
> > > > > > that directory containing the following line:
> > 

> > > > > The name of this file should be 'Kbuild'. Sorry for the noise.
> > 

> > > > > > obj-m += mxdm-debugfs.o
> > 

> > > > > > 2) Build the kernel module:
> > 

> > > > > > make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> > 

> > > > > > (The "source" and "build" paths under /lib/modules/`uname -r` should
> > > > > > be the correct paths in almost all cases; if your system uses
> > > > > > different paths, substitute those. You will need the development
> > > > > > headers for external kernel modules, and the relevant toolchain bits,
> > > > > > but if you're already using the NVIDIA proprietary driver you almost
> > > > > > certainly already have all of that.)
> > 

> > > > > > 3) Load the kernel module:
> > 

> > > > > > insmod ./mxdm-debugfs.ko
> > 

> > > > > > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > > > > > Reading this file should report the current mux operation mode.
> > 

> > > > > > While switching mux modes on a dynamic mux system to test this kernel
> > > > > > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > > > > > when the mux mode was set to discrete only on that particular system.
> > > > > > This contradicted the behavior I had previously observed on other
> > > > > > systems; i.e., that MXDM is always available regardless of the currently
> > > > > > set mux mode, so I tried it on another dynamic mux system and observed
> > > > > > that the other system does always expose MXDM regardless of the mux
> > > > > > mode, and the contents of the debugfs file matched the selected mode.
> > 

> > > > > > So if the module fails to load with ENODEV and prints the "MXDM not
> > > > > > found" message to the kernel log, the system is most likely configured
> > > > > > to a non-dynamic mux mode. My usual expectation is that it should load
> > > > > > and create the file on most dynamic mux systems. I do not have direct
> > > > > > access to any of the above listed systems at the moment, so I do not
> > > > > > know whether MXDM will be exposed when the system is not in dynamic mux
> > > > > > mode.
> > 

> > > > > > > Regards,
> > 

> > > > > > > Hans
> > 

> > > > > > // SPDX-License-Identifier: GPL-2.0-only
> > > > > > /*
> > > > > > * Copyright (C) 2020 NVIDIA Corporation
> > > > > > *
> > > > > > */
> > 

> > > > > > #include <linux/acpi.h>
> > > > > > #include <acpi/acoutput.h>
> > > > > > #include <linux/module.h>
> > > > > > #include <linux/pci.h>
> > > > > > #include <linux/debugfs.h>
> > 

> > > > > > extern struct dentry *acpi_debugfs_dir;
> > 

> > > > > > enum mux_mode {
> > > > > > MUX_MODE_UNKNOWN = 0,
> > > > > > MUX_MODE_INTEGRATED = 1, /* iGPU only /
> > > > > > MUX_MODE_DISCRETE = 2, / dGPU only /
> > > > > > MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> > > > > > MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> > > > > > MUX_MODE_MAX
> > > > > > };
> > 

> > > > > > static char * mode_names[] = {
> > > > > > [MUX_MODE_UNKNOWN] = "unknown\n",
> > > > > > [MUX_MODE_INTEGRATED] = "integrated\n",
> > > > > > [MUX_MODE_DISCRETE] = "discrete\n",
> > > > > > [MUX_MODE_HYBRID] = "hybrid\n",
> > > > > > [MUX_MODE_DYNAMIC] = "dynamic\n",
> > > > > > };
> > 

> > > > > > static struct debugfs_blob_wrapper muxmode_blob;
> > 

> > > > > > static void store_mux_mode(acpi_handle handle)
> > > > > > {
> > > > > > union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> > > > > > struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > 

> > > > > > acpi_integer ret;
> > > > > > acpi_status status;
> > 

> > > > > > status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > 

> > > > > > if (ACPI_FAILURE(status)) {
> > > > > > acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > > > > > acpi_handle_err(handle, "Mux mode value out of range");
> > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > } else {
> > > > > > muxmode_blob.data = mode_names[ret];
> > > > > > }
> > 

> > > > > > muxmode_blob.size = strlen(muxmode_blob.data);
> > > > > > }
> > 

> > > > > > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > > > > > {
> > > > > > acpi_handle search;
> > 

> > > > > > if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > > > > > /* Found the parent object of the MXDM method; pass it back
> > > > > > * to the caller and stop searching. */
> > > > > > *ret = obj;
> > 

> > > > > > return AE_CTRL_TERMINATE;
> > > > > > }
> > 

> > > > > > /* No MXDM; keep looking */
> > > > > > return AE_OK;
> > > > > > }
> > 

> > > > > > static struct dentry *muxmode_file_dentry;
> > 

> > > > > > static int __init mxdm_debugfs_init(void)
> > > > > > {
> > > > > > acpi_handle mxdm_handle = NULL;
> > > > > > acpi_status ret;
> > 

> > > > > > ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > > > > > find_mxdm, NULL, NULL, &mxdm_handle);
> > 

> > > > > > if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > > > > > pr_err("MXDM not found.\n");
> > > > > > return -ENODEV;
> > > > > > }
> > 

> > > > > > /* Populate the blob wrapper: the mux mode cannot change without rebooting
> > > > > > * so this only needs to be done once. */
> > > > > > store_mux_mode(mxdm_handle);
> > 

> > > > > > muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > > > > > acpi_debugfs_dir,
> > > > > > &muxmode_blob);
> > 

> > > > > > return muxmode_file_dentry ? 0 : -EIO;
> > > > > > }
> > > > > > module_init(mxdm_debugfs_init);
> > 

> > > > > > static void __exit mxdm_debugfs_exit(void)
> > > > > > {
> > > > > > if (muxmode_file_dentry) {
> > > > > > debugfs_remove(muxmode_file_dentry);
> > > > > > muxmode_file_dentry = NULL;
> > > > > > }
> > > > > > }
> > > > > > module_exit(mxdm_debugfs_exit);
> > 

> > > > > > MODULE_LICENSE("GPL v2");
> > > > > > MODULE_DESCRIPTION("MXDM mux mode test module");
> > > > > > MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> > 

> > > > > > /*
> > > > > > * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> > > > > > * the WMI wrapper for the related WMAA method for backlight control.
> > > > > > */
> > > > > > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
> 

> 

> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Aly]

I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
x_state contained "integrated".

I ran
echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
now it contained ''discrete' and the screen turned off.
then I return it to its initial state.

Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
but it didn't work, had to reboot, I am running gnome on wayland.


On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
>
> After loading the updated module, /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
>
> Now, i ran the command
> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
>
> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my screen didn't turn off... I changed it back to integrated, then to discrete again, it seems like nothing happened, or did i do something wrong?
>
>
> ------- Original Message -------
> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <ddadap@nvidia.com> wrote:
>
>
> > Thanks, Iris:
> >
>
> > On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
> >
>
> > > I have followed Youssef's instructions to build the module, and after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
> >
>
> >
>
> > That is unfortunate. I was hoping it would report a non-dynamic mode, which
> > would make it easier to disambiguate between G15 5515 models which require
> > EC backlight control and G15 5515 models which require native GPU-driven
> > backlight control.
> >
>
> > I have attached an updated version of the test module which will allow you
> > to test if your system does have a dynamic mux. Build and load it the same
> > way as the previous one (unload the previous one first if you haven't done
> > so or rebooted already). This adds /sys/kernel/debug/acpi/mxds_mux_state: if
> > you see this file, read out its contents. I expect that on your system it
> > should report "integrated", since IIUC the amdgpu_bl backlight device is the
> > one that works on your system. If you do not see this file, and the message
> > "MXDS not found" appears in your kernel log, then your ACPI table doesn't
> > expose the MXDS method, which could be a useful disambiguation test.
> >
>
> > Another experiment to try would be to flip the state of the mux. Before
> > attempting this experiment, make sure to save any work and log in remotely
> > from another machine, since it is possible that your screen will go blank
> > and will need a reboot in order to come back up. To change the mux state,
> > write the target mux state to the mxds_mux_state file. Use whatever the
> > opposite of the current value is, i.e., if it reads out as "integrated",
> > then write "discrete", and vice versa. If the mux switch worked, your
> > screen should go blank and reading the mxds_mux_state file again should
> > reflect the new state. You can then flip the mux back to its original
> > position, and you should be able to get the display back by forcing
> > DPMS off and then on again. If you're not running X, writing a '0' then
> > writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems to
> > work on my AMD+NVIDIA system. (The DRI device and eDP connector ID might
> > be enumerated differently on your system.) If neither of those work to
> > bring your display back up, then reboot the computer.
> >
>
> > The most interesting data would be to check whether MXDS is available in
> > your system's ACPI tables, and if so, whether it is actually functional.
> >
>
> > > As mentioned before, this RTX 3050 system does not have configurable GPU mode.
> > >
>
> > > ------- Original Message -------
> > > On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap ddadap@nvidia.com wrote:
> > >
>
> > > > On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> > >
>
> > > > > Hello Daniel,
> > >
>
> > > > > I tried building the module using the instructions you provided, but
> > > > > ran into some problems as I didn't have the /lib/modules/$(uname
> > > > > -r)/source directory on my end.
> > > > > I created a Makefile in a directory containing mxdm-debugfs.c file and
> > > > > added the following to it:
> > >
>
> > > > > obj-m += mxdm-debugfs.o
> > >
>
> > > > > all:
> > > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> > >
>
> > > > > clean:
> > > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > >
>
> > > > > I then ran "make" and loaded the module.
> > >
>
> > > > Ah, yes, I should have mentioned specifically that the instructions
> > > > assumed either a split Kbuild configuration with separate source and
> > > > output directories, or a single combined source and output directory but
> > > > with "source" and "build" both being symlinks to the same directory. I
> > > > forget which distros do what exactly, but some ship a combined
> > > > source/output directory but only have one of either "source" or "build";
> > > > yours appears to be the latter configuration. I'm glad you were able to
> > > > get it building anyway.
> > >
>
> > > > > 1) Hybrid mode set to "Enabled" from the bios settings,
> > > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> > > > > 2) Hybrid mode set to "Disabled" from the bios settings,
> > > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> > >
>
> > > > Okay. This is consistent with my expectations. If we also find that the
> > > > systems which require the quirk report either "discrete", "hybrid", or
> > > > "integrated" (IIUC those systems do not have the mode configurable in the
> > > > UEFI settings), then I think we can fix the quirk by checking the mux
> > > > mode and only forcing to native if the system is not in hybrid mode.
> > >
>
> > > > Or perhaps we should just get rid of the quirk, and unconditionally test
> > > > the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
> > > > are not in "dynamic" mode, regardless of whether they expose the WMI EC
> > > > backlight interface and regardless of whether that interface reports
> > > > that the EC backlight driver should be used. (On the systems that need
> > > > the quirk, that interface is reporting that the backlight should be
> > > > EC-controlled even when it shouldn't be.) I think that in theory, it
> > > > should be possible for a system design to require EC backlight control
> > > > even when the mux is in a non-dynamic mode, but in practice I don't know
> > > > why anybody would do that, and am not aware of any systems which do so
> > > > (although until the report of the broken backlight on the 3050 version
> > > > of the Dell G15 5515, I wasn't aware of any systems that reported EC
> > > > backlight control when it was supposed to be native.)
> > >
>
> > > > Hans, I think the most reasonable options are:
> > >
>
> > > > 1) Remove the quirk, and check for MXDM when deciding whether a system
> > > > should use the EC backlight driver. This has the disadvantage of adding
> > > > a check where one isn't actually needed on some (most?) systems, and the
> > > > advantage of most likely avoiding the need to add quirks for other
> > > > systems where the system reports EC backlight control when native should
> > > > be used. It also has the possibility of being wrong on a theoretically
> > > > possible configuration, although if we ever encounter such a
> > > > configuration we could handle it with a quirk or find some other way to
> > > > distinguish between systems that do or do not require the EC backlight
> > > > driver.
> > >
>
> > > > 2) Keep the existing quirk, and only force to native if MXDM is missing
> > > > or if MXDM reports that the system is in a non-dynamic mode.
> > >
>
> > > > I'm inclined to go with (2), because it seems "safer", but am happy to
> > > > implement (1) if you think that's the better option. For the MXDM check
> > > > I think the first thing to do is to check whether the MXDM method is
> > > > present at all: as observed on at least one system, there is no MXDM
> > > > method when the system is in non-dynamic mode. Then if MXDM is present,
> > > > check whether it reports that the mux is in dynamic mode. For (1), only
> > > > query the WMI-wrapped API to determine the backlight control source if
> > > > the mux is in dynamic mode. For (2), only force the backlight to native
> > > > if the mux is not in dynamic mode.
> > >
>
> > > > This, again, assumes that none of the systems which require the quirk
> > > > report that the mux is in dynamic mode. If any of them do, we will need
> > > > to find a different way to determine which systems are lying about how
> > > > the backlight is supposed to be controlled.
> > >
>
> > > > > Regards,
> > >
>
> > > > > Youssef
> > >
>
> > > > > On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com wrote:
> > >
>
> > > > > > Hans pointed out a crucial omission in the build instructions in a
> > > > > > different thread where I also shared this test module:
> > >
>
> > > > > > On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > >
>
> > > > > > > Thanks, Hans.
> > >
>
> > > > > > > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > >
>
> > > > > > > > Hi All,
> > >
>
> > > > > > > > On 1/11/23 10:51, Hans de Goede wrote:
> > >
>
> > > > > > > > > Hi,
> > >
>
> > > > > > > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > >
>
> > > > > > > > > > On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > >
>
> > > > > > > > > > > Hi,
> > >
>
> > > > > > > > > > > On 1/10/23 16:19, Youssef Aly wrote:
> > >
>
> > > > > > > > > > > > Hi Hans,
> > >
>
> > > > > > > > > > > > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > > > > > > > > > > the kernel commandline for the patched kernel, it doesn't work without it.
> > >
>
> > > > > > > > > > > > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > > > > > > > > > > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > > > > > > > > > > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > >
>
> > > > > > > > > > > > Hybrid:
> > > > > > > > > > > > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > > > > > > > > > > amdgpu_bl1.
> > > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > > > > > > > > > > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > >
>
> > > > > > > > > > > > Discrete:
> > > > > > > > > > > > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > > > > > > > > > > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > > > > > > > > > > same as 80, etc... ,
> > > > > > > > > > > > /sys/class/backlight contains nvidia_0.
> > > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > > > > > > > > > > contains nvidia_wmi_ec_backlight.
> > >
>
> > > > > > > > > > > Thank you for testing!
> > >
>
> > > > > > > > > > > Ok so it seems there are 2 issues at play here:
> > >
>
> > > > > > > > > > > 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > > > > > > > > > or nvidia_wmi_ec (hybrid mode)
> > >
>
> > > > > > > > > > > 2. There is a bug in the nvidia binary drivers backlight control in native
> > > > > > > > > > > mode on this system causing the range to be wrong
> > >
>
> > > > > > > > > > > Daniel, we really need help from NVidia with fixing 1. can you see if
> > > > > > > > > > > there is a way to check the BIOS setting/mode from inside the kernel ?
> > >
>
> > > > > > > > > > Yes, the ACPI MXDM method should be able to do this. However, querying
> > > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > > > > > > > > determine whether the backlight is supposed to be EC-driven, since there
> > > > > > > > > > are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > > > > > > > > be orthogonal to whether or not the EC driver should be used. It sounds
> > > > > > > > > > like the BIOS is possibly reporting a wrong value for that query.
> > >
>
> > > > > > > > > > I guess we could wire up a quirk that checks MXDM and overrides the
> > > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > > > > > > > > mux operation mode. Then that quirk could be applied to this system.
> > > > > > > > > > I can put together a patch for that.
> > >
>
> > > > > > > > > If you can write a patch for this that would be great, thank you,
> > > > > > > > > but I think we first need to root-cause this better:
> > >
>
> > > > > > > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > > > > > > to always use the native backlight. So I've gone back to the original email
> > > > > > > > > thread which lead to me adding that quirk.
> > >
>
> > > > > > > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > > > > > > did ask to test with different BIOS settings their to and the reporter's
> > > > > > > > > reply was:
> > >
>
> > > > > > > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > > > > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > >
>
> > > > > > > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > > > > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > > > > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > > > > > > device and in Youssef's case the amdgpu_bl# device never works.
> > >
>
> > > > > > > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > >
>
> > > > > > > > > While the dGPU can be one of:
> > > > > > > > > NVIDIA GeForce RTX 3060
> > > > > > > > > NVIDIA GeForce GTX 3050 Ti
> > > > > > > > > NVIDIA GeForce GTX 3050
> > >
>
> > > > > > > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > > > > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > > > > > > maybe not load at all on the model with the 3050 versions.
> > >
>
> > > > > > > > A quick status update on this.
> > >
>
> > > > > > > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > > > > > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > > > > > > gotten back to me with lspci output on their G15 and it indeed has
> > > > > > > > a GTX 3050.
> > >
>
> > > > > > > > So atm we have the following models which are affected one way
> > > > > > > > or the other:
> > >
>
> > > > > > > > -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 :(
> > >
>
> > > > > > > > With the models which need acpi_backlight=native being broken
> > > > > > > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > > > > > > for backlight control while they actually should not be using that.
> > >
>
> > > > > > > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > > > > > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > >
>
> > > > > > > I've attached a simple kernel module which adds a debugfs file that
> > > > > > > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > > > > > > systems which need the quirk may be in one of the non-dynamic modes, and
> > > > > > > the systems which are broken by the quirk may be in dynamic mux mode. It
> > > > > > > should be pretty straightforward to compile this as an out-of-tree
> > > > > > > module using the Kbuild extmod infrastructure, as follows:
> > >
>
> > > > > > > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> > > > > > > wish to create an empty directory to put it in) and create a file in
> > > > > > > that directory containing the following line:
> > >
>
> > > > > > The name of this file should be 'Kbuild'. Sorry for the noise.
> > >
>
> > > > > > > obj-m += mxdm-debugfs.o
> > >
>
> > > > > > > 2) Build the kernel module:
> > >
>
> > > > > > > make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> > >
>
> > > > > > > (The "source" and "build" paths under /lib/modules/`uname -r` should
> > > > > > > be the correct paths in almost all cases; if your system uses
> > > > > > > different paths, substitute those. You will need the development
> > > > > > > headers for external kernel modules, and the relevant toolchain bits,
> > > > > > > but if you're already using the NVIDIA proprietary driver you almost
> > > > > > > certainly already have all of that.)
> > >
>
> > > > > > > 3) Load the kernel module:
> > >
>
> > > > > > > insmod ./mxdm-debugfs.ko
> > >
>
> > > > > > > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > > > > > > Reading this file should report the current mux operation mode.
> > >
>
> > > > > > > While switching mux modes on a dynamic mux system to test this kernel
> > > > > > > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > > > > > > when the mux mode was set to discrete only on that particular system.
> > > > > > > This contradicted the behavior I had previously observed on other
> > > > > > > systems; i.e., that MXDM is always available regardless of the currently
> > > > > > > set mux mode, so I tried it on another dynamic mux system and observed
> > > > > > > that the other system does always expose MXDM regardless of the mux
> > > > > > > mode, and the contents of the debugfs file matched the selected mode.
> > >
>
> > > > > > > So if the module fails to load with ENODEV and prints the "MXDM not
> > > > > > > found" message to the kernel log, the system is most likely configured
> > > > > > > to a non-dynamic mux mode. My usual expectation is that it should load
> > > > > > > and create the file on most dynamic mux systems. I do not have direct
> > > > > > > access to any of the above listed systems at the moment, so I do not
> > > > > > > know whether MXDM will be exposed when the system is not in dynamic mux
> > > > > > > mode.
> > >
>
> > > > > > > > Regards,
> > >
>
> > > > > > > > Hans
> > >
>
> > > > > > > // SPDX-License-Identifier: GPL-2.0-only
> > > > > > > /*
> > > > > > > * Copyright (C) 2020 NVIDIA Corporation
> > > > > > > *
> > > > > > > */
> > >
>
> > > > > > > #include <linux/acpi.h>
> > > > > > > #include <acpi/acoutput.h>
> > > > > > > #include <linux/module.h>
> > > > > > > #include <linux/pci.h>
> > > > > > > #include <linux/debugfs.h>
> > >
>
> > > > > > > extern struct dentry *acpi_debugfs_dir;
> > >
>
> > > > > > > enum mux_mode {
> > > > > > > MUX_MODE_UNKNOWN = 0,
> > > > > > > MUX_MODE_INTEGRATED = 1, /* iGPU only /
> > > > > > > MUX_MODE_DISCRETE = 2, / dGPU only /
> > > > > > > MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> > > > > > > MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> > > > > > > MUX_MODE_MAX
> > > > > > > };
> > >
>
> > > > > > > static char * mode_names[] = {
> > > > > > > [MUX_MODE_UNKNOWN] = "unknown\n",
> > > > > > > [MUX_MODE_INTEGRATED] = "integrated\n",
> > > > > > > [MUX_MODE_DISCRETE] = "discrete\n",
> > > > > > > [MUX_MODE_HYBRID] = "hybrid\n",
> > > > > > > [MUX_MODE_DYNAMIC] = "dynamic\n",
> > > > > > > };
> > >
>
> > > > > > > static struct debugfs_blob_wrapper muxmode_blob;
> > >
>
> > > > > > > static void store_mux_mode(acpi_handle handle)
> > > > > > > {
> > > > > > > union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> > > > > > > struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > >
>
> > > > > > > acpi_integer ret;
> > > > > > > acpi_status status;
> > >
>
> > > > > > > status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > >
>
> > > > > > > if (ACPI_FAILURE(status)) {
> > > > > > > acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> > > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > > } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > > > > > > acpi_handle_err(handle, "Mux mode value out of range");
> > > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > > } else {
> > > > > > > muxmode_blob.data = mode_names[ret];
> > > > > > > }
> > >
>
> > > > > > > muxmode_blob.size = strlen(muxmode_blob.data);
> > > > > > > }
> > >
>
> > > > > > > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > > > > > > {
> > > > > > > acpi_handle search;
> > >
>
> > > > > > > if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > > > > > > /* Found the parent object of the MXDM method; pass it back
> > > > > > > * to the caller and stop searching. */
> > > > > > > *ret = obj;
> > >
>
> > > > > > > return AE_CTRL_TERMINATE;
> > > > > > > }
> > >
>
> > > > > > > /* No MXDM; keep looking */
> > > > > > > return AE_OK;
> > > > > > > }
> > >
>
> > > > > > > static struct dentry *muxmode_file_dentry;
> > >
>
> > > > > > > static int __init mxdm_debugfs_init(void)
> > > > > > > {
> > > > > > > acpi_handle mxdm_handle = NULL;
> > > > > > > acpi_status ret;
> > >
>
> > > > > > > ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > > > > > > find_mxdm, NULL, NULL, &mxdm_handle);
> > >
>
> > > > > > > if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > > > > > > pr_err("MXDM not found.\n");
> > > > > > > return -ENODEV;
> > > > > > > }
> > >
>
> > > > > > > /* Populate the blob wrapper: the mux mode cannot change without rebooting
> > > > > > > * so this only needs to be done once. */
> > > > > > > store_mux_mode(mxdm_handle);
> > >
>
> > > > > > > muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > > > > > > acpi_debugfs_dir,
> > > > > > > &muxmode_blob);
> > >
>
> > > > > > > return muxmode_file_dentry ? 0 : -EIO;
> > > > > > > }
> > > > > > > module_init(mxdm_debugfs_init);
> > >
>
> > > > > > > static void __exit mxdm_debugfs_exit(void)
> > > > > > > {
> > > > > > > if (muxmode_file_dentry) {
> > > > > > > debugfs_remove(muxmode_file_dentry);
> > > > > > > muxmode_file_dentry = NULL;
> > > > > > > }
> > > > > > > }
> > > > > > > module_exit(mxdm_debugfs_exit);
> > >
>
> > > > > > > MODULE_LICENSE("GPL v2");
> > > > > > > MODULE_DESCRIPTION("MXDM mux mode test module");
> > > > > > > MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> > >
>
> > > > > > > /*
> > > > > > > * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> > > > > > > * the WMI wrapper for the related WMAA method for backlight control.
> > > > > > > */
> > > > > > > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
> >
>
> >
>
> >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

On Wed, Jan 18, 2023 at 09:20:15PM +0000, Iris wrote:
> After loading the updated module, /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
> 
> Now, i ran the command
> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
> 
> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my screen didn't turn off... I changed it back to integrated, then to discrete again, it seems like nothing happened, or did i do something wrong?

I don't think you did anything wrong: it sounds like your system exposes
all of the dynamic mux switch ACPI interfaces (including reporting that
the backlight should be under EC control), but none of them actually do
anything. My best guess is that Dell is using the same firmware for both
dynamic mux and non-dyanmic mux (I suspect that there's actually no mux
at all on your system), but leaves the dynamic mux controls enabled in
ACPI even when they're irrelevant. Unfortunately this will make it
difficult to distinguish the systems that actually do have a dynamic mux
(and therefore must use EC backlight control) from ones that do not (and
therefore must *not* use EC backlight control). Hopefully we will be
able to find a way to do so. I am conferring with some of my colleagues
who work on the NVIDIA driver for Windows to see if they have run into
similar issues.

Would you be willing to share a dump of your ACPI tables? If you run
`acpidump -b`, it will write out several *.dat files (you'll probably
want to do this in an empty directory). Then tar up the files and send
them to me, probably directly to avoid sending a large attachment to the
whole list. I'm hoping there will be something in there that can be used
to discern whether the mux interfaces actually work. Usually the mux
stuff is in the DSDT table, but I've seen it in other tables (e.g. SSDT)
on some systems, so it's probably best to include all the dumped tables.

An nvidia-bug-report.log could be helpful to: if you have the NVIDIA
proprietary driver installed, it should have included a script called
nvidia-bug-report.sh somewhere in your PATH. The script collects various
bits of system information and writes it to a file named
nvidia-bug-report.log.gz in the current directory. If you do not have
the NVIDIA proprietary driver installed, you can extract the contents of
a .run installer package by executing it with the "-x" option on the
command line. This will create a directory populated with the various
files that the installer installs, including nvidia-bug-report.sh at the
top level of the newly create directory.
 
> 
> ------- Original Message -------
> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <ddadap@nvidia.com> wrote:
> 
> 
> > Thanks, Iris:
> > 
> 
> > On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
> > 
> 
> > > I have followed Youssef's instructions to build the module, and after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
> > 
> 
> > 
> 
> > That is unfortunate. I was hoping it would report a non-dynamic mode, which
> > would make it easier to disambiguate between G15 5515 models which require
> > EC backlight control and G15 5515 models which require native GPU-driven
> > backlight control.
> > 
> 
> > I have attached an updated version of the test module which will allow you
> > to test if your system does have a dynamic mux. Build and load it the same
> > way as the previous one (unload the previous one first if you haven't done
> > so or rebooted already). This adds /sys/kernel/debug/acpi/mxds_mux_state: if
> > you see this file, read out its contents. I expect that on your system it
> > should report "integrated", since IIUC the amdgpu_bl backlight device is the
> > one that works on your system. If you do not see this file, and the message
> > "MXDS not found" appears in your kernel log, then your ACPI table doesn't
> > expose the MXDS method, which could be a useful disambiguation test.
> > 
> 
> > Another experiment to try would be to flip the state of the mux. Before
> > attempting this experiment, make sure to save any work and log in remotely
> > from another machine, since it is possible that your screen will go blank
> > and will need a reboot in order to come back up. To change the mux state,
> > write the target mux state to the mxds_mux_state file. Use whatever the
> > opposite of the current value is, i.e., if it reads out as "integrated",
> > then write "discrete", and vice versa. If the mux switch worked, your
> > screen should go blank and reading the mxds_mux_state file again should
> > reflect the new state. You can then flip the mux back to its original
> > position, and you should be able to get the display back by forcing
> > DPMS off and then on again. If you're not running X, writing a '0' then
> > writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems to
> > work on my AMD+NVIDIA system. (The DRI device and eDP connector ID might
> > be enumerated differently on your system.) If neither of those work to
> > bring your display back up, then reboot the computer.
> > 
> 
> > The most interesting data would be to check whether MXDS is available in
> > your system's ACPI tables, and if so, whether it is actually functional.
> > 
> 
> > > As mentioned before, this RTX 3050 system does not have configurable GPU mode.
> > > 
> 
> > > ------- Original Message -------
> > > On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap ddadap@nvidia.com wrote:
> > > 
> 
> > > > On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> > > 
> 
> > > > > Hello Daniel,
> > > 
> 
> > > > > I tried building the module using the instructions you provided, but
> > > > > ran into some problems as I didn't have the /lib/modules/$(uname
> > > > > -r)/source directory on my end.
> > > > > I created a Makefile in a directory containing mxdm-debugfs.c file and
> > > > > added the following to it:
> > > 
> 
> > > > > obj-m += mxdm-debugfs.o
> > > 
> 
> > > > > all:
> > > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> > > 
> 
> > > > > clean:
> > > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > > 
> 
> > > > > I then ran "make" and loaded the module.
> > > 
> 
> > > > Ah, yes, I should have mentioned specifically that the instructions
> > > > assumed either a split Kbuild configuration with separate source and
> > > > output directories, or a single combined source and output directory but
> > > > with "source" and "build" both being symlinks to the same directory. I
> > > > forget which distros do what exactly, but some ship a combined
> > > > source/output directory but only have one of either "source" or "build";
> > > > yours appears to be the latter configuration. I'm glad you were able to
> > > > get it building anyway.
> > > 
> 
> > > > > 1) Hybrid mode set to "Enabled" from the bios settings,
> > > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> > > > > 2) Hybrid mode set to "Disabled" from the bios settings,
> > > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> > > 
> 
> > > > Okay. This is consistent with my expectations. If we also find that the
> > > > systems which require the quirk report either "discrete", "hybrid", or
> > > > "integrated" (IIUC those systems do not have the mode configurable in the
> > > > UEFI settings), then I think we can fix the quirk by checking the mux
> > > > mode and only forcing to native if the system is not in hybrid mode.
> > > 
> 
> > > > Or perhaps we should just get rid of the quirk, and unconditionally test
> > > > the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
> > > > are not in "dynamic" mode, regardless of whether they expose the WMI EC
> > > > backlight interface and regardless of whether that interface reports
> > > > that the EC backlight driver should be used. (On the systems that need
> > > > the quirk, that interface is reporting that the backlight should be
> > > > EC-controlled even when it shouldn't be.) I think that in theory, it
> > > > should be possible for a system design to require EC backlight control
> > > > even when the mux is in a non-dynamic mode, but in practice I don't know
> > > > why anybody would do that, and am not aware of any systems which do so
> > > > (although until the report of the broken backlight on the 3050 version
> > > > of the Dell G15 5515, I wasn't aware of any systems that reported EC
> > > > backlight control when it was supposed to be native.)
> > > 
> 
> > > > Hans, I think the most reasonable options are:
> > > 
> 
> > > > 1) Remove the quirk, and check for MXDM when deciding whether a system
> > > > should use the EC backlight driver. This has the disadvantage of adding
> > > > a check where one isn't actually needed on some (most?) systems, and the
> > > > advantage of most likely avoiding the need to add quirks for other
> > > > systems where the system reports EC backlight control when native should
> > > > be used. It also has the possibility of being wrong on a theoretically
> > > > possible configuration, although if we ever encounter such a
> > > > configuration we could handle it with a quirk or find some other way to
> > > > distinguish between systems that do or do not require the EC backlight
> > > > driver.
> > > 
> 
> > > > 2) Keep the existing quirk, and only force to native if MXDM is missing
> > > > or if MXDM reports that the system is in a non-dynamic mode.
> > > 
> 
> > > > I'm inclined to go with (2), because it seems "safer", but am happy to
> > > > implement (1) if you think that's the better option. For the MXDM check
> > > > I think the first thing to do is to check whether the MXDM method is
> > > > present at all: as observed on at least one system, there is no MXDM
> > > > method when the system is in non-dynamic mode. Then if MXDM is present,
> > > > check whether it reports that the mux is in dynamic mode. For (1), only
> > > > query the WMI-wrapped API to determine the backlight control source if
> > > > the mux is in dynamic mode. For (2), only force the backlight to native
> > > > if the mux is not in dynamic mode.
> > > 
> 
> > > > This, again, assumes that none of the systems which require the quirk
> > > > report that the mux is in dynamic mode. If any of them do, we will need
> > > > to find a different way to determine which systems are lying about how
> > > > the backlight is supposed to be controlled.
> > > 
> 
> > > > > Regards,
> > > 
> 
> > > > > Youssef
> > > 
> 
> > > > > On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com wrote:
> > > 
> 
> > > > > > Hans pointed out a crucial omission in the build instructions in a
> > > > > > different thread where I also shared this test module:
> > > 
> 
> > > > > > On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > > 
> 
> > > > > > > Thanks, Hans.
> > > 
> 
> > > > > > > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > > 
> 
> > > > > > > > Hi All,
> > > 
> 
> > > > > > > > On 1/11/23 10:51, Hans de Goede wrote:
> > > 
> 
> > > > > > > > > Hi,
> > > 
> 
> > > > > > > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > > 
> 
> > > > > > > > > > On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > > 
> 
> > > > > > > > > > > Hi,
> > > 
> 
> > > > > > > > > > > On 1/10/23 16:19, Youssef Aly wrote:
> > > 
> 
> > > > > > > > > > > > Hi Hans,
> > > 
> 
> > > > > > > > > > > > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > > > > > > > > > > the kernel commandline for the patched kernel, it doesn't work without it.
> > > 
> 
> > > > > > > > > > > > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > > > > > > > > > > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > > > > > > > > > > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > > 
> 
> > > > > > > > > > > > Hybrid:
> > > > > > > > > > > > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > > > > > > > > > > amdgpu_bl1.
> > > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > > > > > > > > > > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > > 
> 
> > > > > > > > > > > > Discrete:
> > > > > > > > > > > > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > > > > > > > > > > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > > > > > > > > > > same as 80, etc... ,
> > > > > > > > > > > > /sys/class/backlight contains nvidia_0.
> > > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > > > > > > > > > > contains nvidia_wmi_ec_backlight.
> > > 
> 
> > > > > > > > > > > Thank you for testing!
> > > 
> 
> > > > > > > > > > > Ok so it seems there are 2 issues at play here:
> > > 
> 
> > > > > > > > > > > 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > > > > > > > > > or nvidia_wmi_ec (hybrid mode)
> > > 
> 
> > > > > > > > > > > 2. There is a bug in the nvidia binary drivers backlight control in native
> > > > > > > > > > > mode on this system causing the range to be wrong
> > > 
> 
> > > > > > > > > > > Daniel, we really need help from NVidia with fixing 1. can you see if
> > > > > > > > > > > there is a way to check the BIOS setting/mode from inside the kernel ?
> > > 
> 
> > > > > > > > > > Yes, the ACPI MXDM method should be able to do this. However, querying
> > > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > > > > > > > > determine whether the backlight is supposed to be EC-driven, since there
> > > > > > > > > > are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > > > > > > > > be orthogonal to whether or not the EC driver should be used. It sounds
> > > > > > > > > > like the BIOS is possibly reporting a wrong value for that query.
> > > 
> 
> > > > > > > > > > I guess we could wire up a quirk that checks MXDM and overrides the
> > > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > > > > > > > > mux operation mode. Then that quirk could be applied to this system.
> > > > > > > > > > I can put together a patch for that.
> > > 
> 
> > > > > > > > > If you can write a patch for this that would be great, thank you,
> > > > > > > > > but I think we first need to root-cause this better:
> > > 
> 
> > > > > > > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > > > > > > to always use the native backlight. So I've gone back to the original email
> > > > > > > > > thread which lead to me adding that quirk.
> > > 
> 
> > > > > > > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > > > > > > did ask to test with different BIOS settings their to and the reporter's
> > > > > > > > > reply was:
> > > 
> 
> > > > > > > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > > > > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > > 
> 
> > > > > > > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > > > > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > > > > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > > > > > > device and in Youssef's case the amdgpu_bl# device never works.
> > > 
> 
> > > > > > > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > > 
> 
> > > > > > > > > While the dGPU can be one of:
> > > > > > > > > NVIDIA GeForce RTX 3060
> > > > > > > > > NVIDIA GeForce GTX 3050 Ti
> > > > > > > > > NVIDIA GeForce GTX 3050
> > > 
> 
> > > > > > > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > > > > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > > > > > > maybe not load at all on the model with the 3050 versions.
> > > 
> 
> > > > > > > > A quick status update on this.
> > > 
> 
> > > > > > > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > > > > > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > > > > > > gotten back to me with lspci output on their G15 and it indeed has
> > > > > > > > a GTX 3050.
> > > 
> 
> > > > > > > > So atm we have the following models which are affected one way
> > > > > > > > or the other:
> > > 
> 
> > > > > > > > -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 :(
> > > 
> 
> > > > > > > > With the models which need acpi_backlight=native being broken
> > > > > > > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > > > > > > for backlight control while they actually should not be using that.
> > > 
> 
> > > > > > > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > > > > > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > > 
> 
> > > > > > > I've attached a simple kernel module which adds a debugfs file that
> > > > > > > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > > > > > > systems which need the quirk may be in one of the non-dynamic modes, and
> > > > > > > the systems which are broken by the quirk may be in dynamic mux mode. It
> > > > > > > should be pretty straightforward to compile this as an out-of-tree
> > > > > > > module using the Kbuild extmod infrastructure, as follows:
> > > 
> 
> > > > > > > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> > > > > > > wish to create an empty directory to put it in) and create a file in
> > > > > > > that directory containing the following line:
> > > 
> 
> > > > > > The name of this file should be 'Kbuild'. Sorry for the noise.
> > > 
> 
> > > > > > > obj-m += mxdm-debugfs.o
> > > 
> 
> > > > > > > 2) Build the kernel module:
> > > 
> 
> > > > > > > make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> > > 
> 
> > > > > > > (The "source" and "build" paths under /lib/modules/`uname -r` should
> > > > > > > be the correct paths in almost all cases; if your system uses
> > > > > > > different paths, substitute those. You will need the development
> > > > > > > headers for external kernel modules, and the relevant toolchain bits,
> > > > > > > but if you're already using the NVIDIA proprietary driver you almost
> > > > > > > certainly already have all of that.)
> > > 
> 
> > > > > > > 3) Load the kernel module:
> > > 
> 
> > > > > > > insmod ./mxdm-debugfs.ko
> > > 
> 
> > > > > > > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > > > > > > Reading this file should report the current mux operation mode.
> > > 
> 
> > > > > > > While switching mux modes on a dynamic mux system to test this kernel
> > > > > > > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > > > > > > when the mux mode was set to discrete only on that particular system.
> > > > > > > This contradicted the behavior I had previously observed on other
> > > > > > > systems; i.e., that MXDM is always available regardless of the currently
> > > > > > > set mux mode, so I tried it on another dynamic mux system and observed
> > > > > > > that the other system does always expose MXDM regardless of the mux
> > > > > > > mode, and the contents of the debugfs file matched the selected mode.
> > > 
> 
> > > > > > > So if the module fails to load with ENODEV and prints the "MXDM not
> > > > > > > found" message to the kernel log, the system is most likely configured
> > > > > > > to a non-dynamic mux mode. My usual expectation is that it should load
> > > > > > > and create the file on most dynamic mux systems. I do not have direct
> > > > > > > access to any of the above listed systems at the moment, so I do not
> > > > > > > know whether MXDM will be exposed when the system is not in dynamic mux
> > > > > > > mode.
> > > 
> 
> > > > > > > > Regards,
> > > 
> 
> > > > > > > > Hans
> > > 
> 
> > > > > > > // SPDX-License-Identifier: GPL-2.0-only
> > > > > > > /*
> > > > > > > * Copyright (C) 2020 NVIDIA Corporation
> > > > > > > *
> > > > > > > */
> > > 
> 
> > > > > > > #include <linux/acpi.h>
> > > > > > > #include <acpi/acoutput.h>
> > > > > > > #include <linux/module.h>
> > > > > > > #include <linux/pci.h>
> > > > > > > #include <linux/debugfs.h>
> > > 
> 
> > > > > > > extern struct dentry *acpi_debugfs_dir;
> > > 
> 
> > > > > > > enum mux_mode {
> > > > > > > MUX_MODE_UNKNOWN = 0,
> > > > > > > MUX_MODE_INTEGRATED = 1, /* iGPU only /
> > > > > > > MUX_MODE_DISCRETE = 2, / dGPU only /
> > > > > > > MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> > > > > > > MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> > > > > > > MUX_MODE_MAX
> > > > > > > };
> > > 
> 
> > > > > > > static char * mode_names[] = {
> > > > > > > [MUX_MODE_UNKNOWN] = "unknown\n",
> > > > > > > [MUX_MODE_INTEGRATED] = "integrated\n",
> > > > > > > [MUX_MODE_DISCRETE] = "discrete\n",
> > > > > > > [MUX_MODE_HYBRID] = "hybrid\n",
> > > > > > > [MUX_MODE_DYNAMIC] = "dynamic\n",
> > > > > > > };
> > > 
> 
> > > > > > > static struct debugfs_blob_wrapper muxmode_blob;
> > > 
> 
> > > > > > > static void store_mux_mode(acpi_handle handle)
> > > > > > > {
> > > > > > > union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> > > > > > > struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > > 
> 
> > > > > > > acpi_integer ret;
> > > > > > > acpi_status status;
> > > 
> 
> > > > > > > status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > > 
> 
> > > > > > > if (ACPI_FAILURE(status)) {
> > > > > > > acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> > > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > > } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > > > > > > acpi_handle_err(handle, "Mux mode value out of range");
> > > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > > } else {
> > > > > > > muxmode_blob.data = mode_names[ret];
> > > > > > > }
> > > 
> 
> > > > > > > muxmode_blob.size = strlen(muxmode_blob.data);
> > > > > > > }
> > > 
> 
> > > > > > > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > > > > > > {
> > > > > > > acpi_handle search;
> > > 
> 
> > > > > > > if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > > > > > > /* Found the parent object of the MXDM method; pass it back
> > > > > > > * to the caller and stop searching. */
> > > > > > > *ret = obj;
> > > 
> 
> > > > > > > return AE_CTRL_TERMINATE;
> > > > > > > }
> > > 
> 
> > > > > > > /* No MXDM; keep looking */
> > > > > > > return AE_OK;
> > > > > > > }
> > > 
> 
> > > > > > > static struct dentry *muxmode_file_dentry;
> > > 
> 
> > > > > > > static int __init mxdm_debugfs_init(void)
> > > > > > > {
> > > > > > > acpi_handle mxdm_handle = NULL;
> > > > > > > acpi_status ret;
> > > 
> 
> > > > > > > ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > > > > > > find_mxdm, NULL, NULL, &mxdm_handle);
> > > 
> 
> > > > > > > if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > > > > > > pr_err("MXDM not found.\n");
> > > > > > > return -ENODEV;
> > > > > > > }
> > > 
> 
> > > > > > > /* Populate the blob wrapper: the mux mode cannot change without rebooting
> > > > > > > * so this only needs to be done once. */
> > > > > > > store_mux_mode(mxdm_handle);
> > > 
> 
> > > > > > > muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > > > > > > acpi_debugfs_dir,
> > > > > > > &muxmode_blob);
> > > 
> 
> > > > > > > return muxmode_file_dentry ? 0 : -EIO;
> > > > > > > }
> > > > > > > module_init(mxdm_debugfs_init);
> > > 
> 
> > > > > > > static void __exit mxdm_debugfs_exit(void)
> > > > > > > {
> > > > > > > if (muxmode_file_dentry) {
> > > > > > > debugfs_remove(muxmode_file_dentry);
> > > > > > > muxmode_file_dentry = NULL;
> > > > > > > }
> > > > > > > }
> > > > > > > module_exit(mxdm_debugfs_exit);
> > > 
> 
> > > > > > > MODULE_LICENSE("GPL v2");
> > > > > > > MODULE_DESCRIPTION("MXDM mux mode test module");
> > > > > > > MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> > > 
> 
> > > > > > > /*
> > > > > > > * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> > > > > > > * the WMI wrapper for the related WMAA method for backlight control.
> > > > > > > */
> > > > > > > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
> > 
> 
> > 
> 
> > 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

On Thu, Jan 19, 2023 at 12:02:50AM +0200, Youssef Aly wrote:
> I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
> x_state contained "integrated".
> 
> I ran
> echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
> now it contained ''discrete' and the screen turned off.
> then I return it to its initial state.
> 
> Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
> but it didn't work, had to reboot, I am running gnome on wayland.

Your system does allow you to switch the mux mode in the UEFI setup
screen, correct? If you could share your ACPI tables as well (see the
instructions in a fork of this thread) that would be helpful.

It sounds like your system has a functional dynamic mux, which would be
consistent with being able to choose different mux modes in UEFI setup.
The screen not coming back up isn't a big concern: triggering the
hotplug is something that's *supposed* to work (and it worked on the
AMD+NVIDIA system I tried it on), but I am not surprised if it doesn't
work everywhere.
 
> 
> On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
> >
> > After loading the updated module, /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
> >
> > Now, i ran the command
> > sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
> >
> > /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my screen didn't turn off... I changed it back to integrated, then to discrete again, it seems like nothing happened, or did i do something wrong?
> >
> >
> > ------- Original Message -------
> > On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <ddadap@nvidia.com> wrote:
> >
> >
> > > Thanks, Iris:
> > >
> >
> > > On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
> > >
> >
> > > > I have followed Youssef's instructions to build the module, and after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
> > >
> >
> > >
> >
> > > That is unfortunate. I was hoping it would report a non-dynamic mode, which
> > > would make it easier to disambiguate between G15 5515 models which require
> > > EC backlight control and G15 5515 models which require native GPU-driven
> > > backlight control.
> > >
> >
> > > I have attached an updated version of the test module which will allow you
> > > to test if your system does have a dynamic mux. Build and load it the same
> > > way as the previous one (unload the previous one first if you haven't done
> > > so or rebooted already). This adds /sys/kernel/debug/acpi/mxds_mux_state: if
> > > you see this file, read out its contents. I expect that on your system it
> > > should report "integrated", since IIUC the amdgpu_bl backlight device is the
> > > one that works on your system. If you do not see this file, and the message
> > > "MXDS not found" appears in your kernel log, then your ACPI table doesn't
> > > expose the MXDS method, which could be a useful disambiguation test.
> > >
> >
> > > Another experiment to try would be to flip the state of the mux. Before
> > > attempting this experiment, make sure to save any work and log in remotely
> > > from another machine, since it is possible that your screen will go blank
> > > and will need a reboot in order to come back up. To change the mux state,
> > > write the target mux state to the mxds_mux_state file. Use whatever the
> > > opposite of the current value is, i.e., if it reads out as "integrated",
> > > then write "discrete", and vice versa. If the mux switch worked, your
> > > screen should go blank and reading the mxds_mux_state file again should
> > > reflect the new state. You can then flip the mux back to its original
> > > position, and you should be able to get the display back by forcing
> > > DPMS off and then on again. If you're not running X, writing a '0' then
> > > writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems to
> > > work on my AMD+NVIDIA system. (The DRI device and eDP connector ID might
> > > be enumerated differently on your system.) If neither of those work to
> > > bring your display back up, then reboot the computer.
> > >
> >
> > > The most interesting data would be to check whether MXDS is available in
> > > your system's ACPI tables, and if so, whether it is actually functional.
> > >
> >
> > > > As mentioned before, this RTX 3050 system does not have configurable GPU mode.
> > > >
> >
> > > > ------- Original Message -------
> > > > On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap ddadap@nvidia.com wrote:
> > > >
> >
> > > > > On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> > > >
> >
> > > > > > Hello Daniel,
> > > >
> >
> > > > > > I tried building the module using the instructions you provided, but
> > > > > > ran into some problems as I didn't have the /lib/modules/$(uname
> > > > > > -r)/source directory on my end.
> > > > > > I created a Makefile in a directory containing mxdm-debugfs.c file and
> > > > > > added the following to it:
> > > >
> >
> > > > > > obj-m += mxdm-debugfs.o
> > > >
> >
> > > > > > all:
> > > > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> > > >
> >
> > > > > > clean:
> > > > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > > >
> >
> > > > > > I then ran "make" and loaded the module.
> > > >
> >
> > > > > Ah, yes, I should have mentioned specifically that the instructions
> > > > > assumed either a split Kbuild configuration with separate source and
> > > > > output directories, or a single combined source and output directory but
> > > > > with "source" and "build" both being symlinks to the same directory. I
> > > > > forget which distros do what exactly, but some ship a combined
> > > > > source/output directory but only have one of either "source" or "build";
> > > > > yours appears to be the latter configuration. I'm glad you were able to
> > > > > get it building anyway.
> > > >
> >
> > > > > > 1) Hybrid mode set to "Enabled" from the bios settings,
> > > > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> > > > > > 2) Hybrid mode set to "Disabled" from the bios settings,
> > > > > > /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> > > >
> >
> > > > > Okay. This is consistent with my expectations. If we also find that the
> > > > > systems which require the quirk report either "discrete", "hybrid", or
> > > > > "integrated" (IIUC those systems do not have the mode configurable in the
> > > > > UEFI settings), then I think we can fix the quirk by checking the mux
> > > > > mode and only forcing to native if the system is not in hybrid mode.
> > > >
> >
> > > > > Or perhaps we should just get rid of the quirk, and unconditionally test
> > > > > the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
> > > > > are not in "dynamic" mode, regardless of whether they expose the WMI EC
> > > > > backlight interface and regardless of whether that interface reports
> > > > > that the EC backlight driver should be used. (On the systems that need
> > > > > the quirk, that interface is reporting that the backlight should be
> > > > > EC-controlled even when it shouldn't be.) I think that in theory, it
> > > > > should be possible for a system design to require EC backlight control
> > > > > even when the mux is in a non-dynamic mode, but in practice I don't know
> > > > > why anybody would do that, and am not aware of any systems which do so
> > > > > (although until the report of the broken backlight on the 3050 version
> > > > > of the Dell G15 5515, I wasn't aware of any systems that reported EC
> > > > > backlight control when it was supposed to be native.)
> > > >
> >
> > > > > Hans, I think the most reasonable options are:
> > > >
> >
> > > > > 1) Remove the quirk, and check for MXDM when deciding whether a system
> > > > > should use the EC backlight driver. This has the disadvantage of adding
> > > > > a check where one isn't actually needed on some (most?) systems, and the
> > > > > advantage of most likely avoiding the need to add quirks for other
> > > > > systems where the system reports EC backlight control when native should
> > > > > be used. It also has the possibility of being wrong on a theoretically
> > > > > possible configuration, although if we ever encounter such a
> > > > > configuration we could handle it with a quirk or find some other way to
> > > > > distinguish between systems that do or do not require the EC backlight
> > > > > driver.
> > > >
> >
> > > > > 2) Keep the existing quirk, and only force to native if MXDM is missing
> > > > > or if MXDM reports that the system is in a non-dynamic mode.
> > > >
> >
> > > > > I'm inclined to go with (2), because it seems "safer", but am happy to
> > > > > implement (1) if you think that's the better option. For the MXDM check
> > > > > I think the first thing to do is to check whether the MXDM method is
> > > > > present at all: as observed on at least one system, there is no MXDM
> > > > > method when the system is in non-dynamic mode. Then if MXDM is present,
> > > > > check whether it reports that the mux is in dynamic mode. For (1), only
> > > > > query the WMI-wrapped API to determine the backlight control source if
> > > > > the mux is in dynamic mode. For (2), only force the backlight to native
> > > > > if the mux is not in dynamic mode.
> > > >
> >
> > > > > This, again, assumes that none of the systems which require the quirk
> > > > > report that the mux is in dynamic mode. If any of them do, we will need
> > > > > to find a different way to determine which systems are lying about how
> > > > > the backlight is supposed to be controlled.
> > > >
> >
> > > > > > Regards,
> > > >
> >
> > > > > > Youssef
> > > >
> >
> > > > > > On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com wrote:
> > > >
> >
> > > > > > > Hans pointed out a crucial omission in the build instructions in a
> > > > > > > different thread where I also shared this test module:
> > > >
> >
> > > > > > > On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > > >
> >
> > > > > > > > Thanks, Hans.
> > > >
> >
> > > > > > > > On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > > >
> >
> > > > > > > > > Hi All,
> > > >
> >
> > > > > > > > > On 1/11/23 10:51, Hans de Goede wrote:
> > > >
> >
> > > > > > > > > > Hi,
> > > >
> >
> > > > > > > > > > On 1/11/23 01:40, Daniel Dadap wrote:
> > > >
> >
> > > > > > > > > > > On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > > >
> >
> > > > > > > > > > > > Hi,
> > > >
> >
> > > > > > > > > > > > On 1/10/23 16:19, Youssef Aly wrote:
> > > >
> >
> > > > > > > > > > > > > Hi Hans,
> > > >
> >
> > > > > > > > > > > > > Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > > > > > > > > > > > > the kernel commandline for the patched kernel, it doesn't work without it.
> > > >
> >
> > > > > > > > > > > > > I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
> > > > > > > > > > > > > the modes with "acpi_backlight=nvidia_wmi_ec" and
> > > > > > > > > > > > > "acpi_backlight=native" using the patched kernel (v6.1.4):
> > > >
> >
> > > > > > > > > > > > > Hybrid:
> > > > > > > > > > > > > "acpi_backlight=native": Does not work, /sys/class/backlight contains
> > > > > > > > > > > > > amdgpu_bl1.
> > > > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > > > > > > > > > > > > /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > > >
> >
> > > > > > > > > > > > > Discrete:
> > > > > > > > > > > > > "acpi_backlight=native": Works but when brightness from 0-10 is the
> > > > > > > > > > > > > same as 0-100, for example 10 is full brightness like 100, 8 is the
> > > > > > > > > > > > > same as 80, etc... ,
> > > > > > > > > > > > > /sys/class/backlight contains nvidia_0.
> > > > > > > > > > > > > "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
> > > > > > > > > > > > > contains nvidia_wmi_ec_backlight.
> > > >
> >
> > > > > > > > > > > > Thank you for testing!
> > > >
> >
> > > > > > > > > > > > Ok so it seems there are 2 issues at play here:
> > > >
> >
> > > > > > > > > > > > 1. Depending on the BIOS setting we need to use either native (discrete mode)
> > > > > > > > > > > > or nvidia_wmi_ec (hybrid mode)
> > > >
> >
> > > > > > > > > > > > 2. There is a bug in the nvidia binary drivers backlight control in native
> > > > > > > > > > > > mode on this system causing the range to be wrong
> > > >
> >
> > > > > > > > > > > > Daniel, we really need help from NVidia with fixing 1. can you see if
> > > > > > > > > > > > there is a way to check the BIOS setting/mode from inside the kernel ?
> > > >
> >
> > > > > > > > > > > Yes, the ACPI MXDM method should be able to do this. However, querying
> > > > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
> > > > > > > > > > > determine whether the backlight is supposed to be EC-driven, since there
> > > > > > > > > > > are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
> > > > > > > > > > > be orthogonal to whether or not the EC driver should be used. It sounds
> > > > > > > > > > > like the BIOS is possibly reporting a wrong value for that query.
> > > >
> >
> > > > > > > > > > > I guess we could wire up a quirk that checks MXDM and overrides the
> > > > > > > > > > > WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
> > > > > > > > > > > mux operation mode. Then that quirk could be applied to this system.
> > > > > > > > > > > I can put together a patch for that.
> > > >
> >
> > > > > > > > > > If you can write a patch for this that would be great, thank you,
> > > > > > > > > > but I think we first need to root-cause this better:
> > > >
> >
> > > > > > > > > > Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
> > > > > > > > > > to always use the native backlight. So I've gone back to the original email
> > > > > > > > > > thread which lead to me adding that quirk.
> > > >
> >
> > > > > > > > > > We (I forwarded a mail from you to the reporter this was not on the list)
> > > > > > > > > > did ask to test with different BIOS settings their to and the reporter's
> > > > > > > > > > reply was:
> > > >
> >
> > > > > > > > > > "Daniel wanted me to check different GPU modes, but my BIOS has no options
> > > > > > > > > > for GPU. It's always in hybrid mode with PRIME render offload."
> > > >
> >
> > > > > > > > > > And perhaps even more interesting in their case with acpi_backlight=native
> > > > > > > > > > to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
> > > > > > > > > > in Youssef's case when running in discrete mode there is an nvidia backlight
> > > > > > > > > > device and in Youssef's case the amdgpu_bl# device never works.
> > > >
> >
> > > > > > > > > > The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
> > > >
> >
> > > > > > > > > > While the dGPU can be one of:
> > > > > > > > > > NVIDIA GeForce RTX 3060
> > > > > > > > > > NVIDIA GeForce GTX 3050 Ti
> > > > > > > > > > NVIDIA GeForce GTX 3050
> > > >
> >
> > > > > > > > > > I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
> > > > > > > > > > be relevant to the model with the 3060 and that nvidia-wmi-ec should
> > > > > > > > > > maybe not load at all on the model with the 3050 versions.
> > > >
> >
> > > > > > > > > A quick status update on this.
> > > >
> >
> > > > > > > > > Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
> > > > > > > > > to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
> > > > > > > > > gotten back to me with lspci output on their G15 and it indeed has
> > > > > > > > > a GTX 3050.
> > > >
> >
> > > > > > > > > So atm we have the following models which are affected one way
> > > > > > > > > or the other:
> > > >
> >
> > > > > > > > > -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 :(
> > > >
> >
> > > > > > > > > With the models which need acpi_backlight=native being broken
> > > > > > > > > by (false positive) detection of the laptop needing nvidia-wmi-ec
> > > > > > > > > for backlight control while they actually should not be using that.
> > > >
> >
> > > > > > > > > and with the Dell G15 5515 with RTX 3060 atm being broken because
> > > > > > > > > of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > > >
> >
> > > > > > > > I've attached a simple kernel module which adds a debugfs file that
> > > > > > > > reports the current mux mode. As mentioned elsewhere, I suspect that the
> > > > > > > > systems which need the quirk may be in one of the non-dynamic modes, and
> > > > > > > > the systems which are broken by the quirk may be in dynamic mux mode. It
> > > > > > > > should be pretty straightforward to compile this as an out-of-tree
> > > > > > > > module using the Kbuild extmod infrastructure, as follows:
> > > >
> >
> > > > > > > > 1) Change to the directory containing the mxdm-debugfs.c file (you may
> > > > > > > > wish to create an empty directory to put it in) and create a file in
> > > > > > > > that directory containing the following line:
> > > >
> >
> > > > > > > The name of this file should be 'Kbuild'. Sorry for the noise.
> > > >
> >
> > > > > > > > obj-m += mxdm-debugfs.o
> > > >
> >
> > > > > > > > 2) Build the kernel module:
> > > >
> >
> > > > > > > > make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
> > > >
> >
> > > > > > > > (The "source" and "build" paths under /lib/modules/`uname -r` should
> > > > > > > > be the correct paths in almost all cases; if your system uses
> > > > > > > > different paths, substitute those. You will need the development
> > > > > > > > headers for external kernel modules, and the relevant toolchain bits,
> > > > > > > > but if you're already using the NVIDIA proprietary driver you almost
> > > > > > > > certainly already have all of that.)
> > > >
> >
> > > > > > > > 3) Load the kernel module:
> > > >
> >
> > > > > > > > insmod ./mxdm-debugfs.ko
> > > >
> >
> > > > > > > > This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
> > > > > > > > Reading this file should report the current mux operation mode.
> > > >
> >
> > > > > > > > While switching mux modes on a dynamic mux system to test this kernel
> > > > > > > > module, I noticed that the ACPI tables no longer exposed the MXDM method
> > > > > > > > when the mux mode was set to discrete only on that particular system.
> > > > > > > > This contradicted the behavior I had previously observed on other
> > > > > > > > systems; i.e., that MXDM is always available regardless of the currently
> > > > > > > > set mux mode, so I tried it on another dynamic mux system and observed
> > > > > > > > that the other system does always expose MXDM regardless of the mux
> > > > > > > > mode, and the contents of the debugfs file matched the selected mode.
> > > >
> >
> > > > > > > > So if the module fails to load with ENODEV and prints the "MXDM not
> > > > > > > > found" message to the kernel log, the system is most likely configured
> > > > > > > > to a non-dynamic mux mode. My usual expectation is that it should load
> > > > > > > > and create the file on most dynamic mux systems. I do not have direct
> > > > > > > > access to any of the above listed systems at the moment, so I do not
> > > > > > > > know whether MXDM will be exposed when the system is not in dynamic mux
> > > > > > > > mode.
> > > >
> >
> > > > > > > > > Regards,
> > > >
> >
> > > > > > > > > Hans
> > > >
> >
> > > > > > > > // SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > /*
> > > > > > > > * Copyright (C) 2020 NVIDIA Corporation
> > > > > > > > *
> > > > > > > > */
> > > >
> >
> > > > > > > > #include <linux/acpi.h>
> > > > > > > > #include <acpi/acoutput.h>
> > > > > > > > #include <linux/module.h>
> > > > > > > > #include <linux/pci.h>
> > > > > > > > #include <linux/debugfs.h>
> > > >
> >
> > > > > > > > extern struct dentry *acpi_debugfs_dir;
> > > >
> >
> > > > > > > > enum mux_mode {
> > > > > > > > MUX_MODE_UNKNOWN = 0,
> > > > > > > > MUX_MODE_INTEGRATED = 1, /* iGPU only /
> > > > > > > > MUX_MODE_DISCRETE = 2, / dGPU only /
> > > > > > > > MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> > > > > > > > MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> > > > > > > > MUX_MODE_MAX
> > > > > > > > };
> > > >
> >
> > > > > > > > static char * mode_names[] = {
> > > > > > > > [MUX_MODE_UNKNOWN] = "unknown\n",
> > > > > > > > [MUX_MODE_INTEGRATED] = "integrated\n",
> > > > > > > > [MUX_MODE_DISCRETE] = "discrete\n",
> > > > > > > > [MUX_MODE_HYBRID] = "hybrid\n",
> > > > > > > > [MUX_MODE_DYNAMIC] = "dynamic\n",
> > > > > > > > };
> > > >
> >
> > > > > > > > static struct debugfs_blob_wrapper muxmode_blob;
> > > >
> >
> > > > > > > > static void store_mux_mode(acpi_handle handle)
> > > > > > > > {
> > > > > > > > union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
> > > > > > > > struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > > >
> >
> > > > > > > > acpi_integer ret;
> > > > > > > > acpi_status status;
> > > >
> >
> > > > > > > > status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > > >
> >
> > > > > > > > if (ACPI_FAILURE(status)) {
> > > > > > > > acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
> > > > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > > > } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > > > > > > > acpi_handle_err(handle, "Mux mode value out of range");
> > > > > > > > muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > > > > > > > } else {
> > > > > > > > muxmode_blob.data = mode_names[ret];
> > > > > > > > }
> > > >
> >
> > > > > > > > muxmode_blob.size = strlen(muxmode_blob.data);
> > > > > > > > }
> > > >
> >
> > > > > > > > static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
> > > > > > > > {
> > > > > > > > acpi_handle search;
> > > >
> >
> > > > > > > > if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > > > > > > > /* Found the parent object of the MXDM method; pass it back
> > > > > > > > * to the caller and stop searching. */
> > > > > > > > *ret = obj;
> > > >
> >
> > > > > > > > return AE_CTRL_TERMINATE;
> > > > > > > > }
> > > >
> >
> > > > > > > > /* No MXDM; keep looking */
> > > > > > > > return AE_OK;
> > > > > > > > }
> > > >
> >
> > > > > > > > static struct dentry *muxmode_file_dentry;
> > > >
> >
> > > > > > > > static int __init mxdm_debugfs_init(void)
> > > > > > > > {
> > > > > > > > acpi_handle mxdm_handle = NULL;
> > > > > > > > acpi_status ret;
> > > >
> >
> > > > > > > > ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > > > > > > > find_mxdm, NULL, NULL, &mxdm_handle);
> > > >
> >
> > > > > > > > if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > > > > > > > pr_err("MXDM not found.\n");
> > > > > > > > return -ENODEV;
> > > > > > > > }
> > > >
> >
> > > > > > > > /* Populate the blob wrapper: the mux mode cannot change without rebooting
> > > > > > > > * so this only needs to be done once. */
> > > > > > > > store_mux_mode(mxdm_handle);
> > > >
> >
> > > > > > > > muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > > > > > > > acpi_debugfs_dir,
> > > > > > > > &muxmode_blob);
> > > >
> >
> > > > > > > > return muxmode_file_dentry ? 0 : -EIO;
> > > > > > > > }
> > > > > > > > module_init(mxdm_debugfs_init);
> > > >
> >
> > > > > > > > static void __exit mxdm_debugfs_exit(void)
> > > > > > > > {
> > > > > > > > if (muxmode_file_dentry) {
> > > > > > > > debugfs_remove(muxmode_file_dentry);
> > > > > > > > muxmode_file_dentry = NULL;
> > > > > > > > }
> > > > > > > > }
> > > > > > > > module_exit(mxdm_debugfs_exit);
> > > >
> >
> > > > > > > > MODULE_LICENSE("GPL v2");
> > > > > > > > MODULE_DESCRIPTION("MXDM mux mode test module");
> > > > > > > > MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> > > >
> >
> > > > > > > > /*
> > > > > > > > * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
> > > > > > > > * the WMI wrapper for the related WMAA method for backlight control.
> > > > > > > > */
> > > > > > > > MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
> > >
> >
> > >
> >
> > >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Linux regression tracking (Thorsten Leemhuis)]

On 18.01.23 23:11, Daniel Dadap wrote:
> On Thu, Jan 19, 2023 at 12:02:50AM +0200, Youssef Aly wrote:
>> I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
>> x_state contained "integrated".
>>
>> I ran
>> echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
>> now it contained ''discrete' and the screen turned off.
>> then I return it to its initial state.
>>
>> Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
>> but it didn't work, had to reboot, I am running gnome on wayland.
> 
> Your system does allow you to switch the mux mode in the UEFI setup
> screen, correct? If you could share your ACPI tables as well (see the
> instructions in a fork of this thread) that would be helpful.

I might be missing something, but it looks like this discussion stalled
here.

Youssef Aly, did you ever share the data Daniel asked for? Or did you
stop caring? Maybe because it works / you found a workaround?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

> It sounds like your system has a functional dynamic mux, which would be
> consistent with being able to choose different mux modes in UEFI setup.
> The screen not coming back up isn't a big concern: triggering the
> hotplug is something that's *supposed* to work (and it worked on the
> AMD+NVIDIA system I tried it on), but I am not surprised if it doesn't
> work everywhere.
>  
>>
>> On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
>>>
>>> After loading the updated module, /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
>>>
>>> Now, i ran the command
>>> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
>>>
>>> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my screen didn't turn off... I changed it back to integrated, then to discrete again, it seems like nothing happened, or did i do something wrong?
>>>
>>>
>>> ------- Original Message -------
>>> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <ddadap@nvidia.com> wrote:
>>>
>>>
>>>> Thanks, Iris:
>>>>
>>>
>>>> On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
>>>>
>>>
>>>>> I have followed Youssef's instructions to build the module, and after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
>>>>
>>>
>>>>
>>>
>>>> That is unfortunate. I was hoping it would report a non-dynamic mode, which
>>>> would make it easier to disambiguate between G15 5515 models which require
>>>> EC backlight control and G15 5515 models which require native GPU-driven
>>>> backlight control.
>>>>
>>>
>>>> I have attached an updated version of the test module which will allow you
>>>> to test if your system does have a dynamic mux. Build and load it the same
>>>> way as the previous one (unload the previous one first if you haven't done
>>>> so or rebooted already). This adds /sys/kernel/debug/acpi/mxds_mux_state: if
>>>> you see this file, read out its contents. I expect that on your system it
>>>> should report "integrated", since IIUC the amdgpu_bl backlight device is the
>>>> one that works on your system. If you do not see this file, and the message
>>>> "MXDS not found" appears in your kernel log, then your ACPI table doesn't
>>>> expose the MXDS method, which could be a useful disambiguation test.
>>>>
>>>
>>>> Another experiment to try would be to flip the state of the mux. Before
>>>> attempting this experiment, make sure to save any work and log in remotely
>>>> from another machine, since it is possible that your screen will go blank
>>>> and will need a reboot in order to come back up. To change the mux state,
>>>> write the target mux state to the mxds_mux_state file. Use whatever the
>>>> opposite of the current value is, i.e., if it reads out as "integrated",
>>>> then write "discrete", and vice versa. If the mux switch worked, your
>>>> screen should go blank and reading the mxds_mux_state file again should
>>>> reflect the new state. You can then flip the mux back to its original
>>>> position, and you should be able to get the display back by forcing
>>>> DPMS off and then on again. If you're not running X, writing a '0' then
>>>> writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems to
>>>> work on my AMD+NVIDIA system. (The DRI device and eDP connector ID might
>>>> be enumerated differently on your system.) If neither of those work to
>>>> bring your display back up, then reboot the computer.
>>>>
>>>
>>>> The most interesting data would be to check whether MXDS is available in
>>>> your system's ACPI tables, and if so, whether it is actually functional.
>>>>
>>>
>>>>> As mentioned before, this RTX 3050 system does not have configurable GPU mode.
>>>>>
>>>
>>>>> ------- Original Message -------
>>>>> On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap ddadap@nvidia.com wrote:
>>>>>
>>>
>>>>>> On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
>>>>>
>>>
>>>>>>> Hello Daniel,
>>>>>
>>>
>>>>>>> I tried building the module using the instructions you provided, but
>>>>>>> ran into some problems as I didn't have the /lib/modules/$(uname
>>>>>>> -r)/source directory on my end.
>>>>>>> I created a Makefile in a directory containing mxdm-debugfs.c file and
>>>>>>> added the following to it:
>>>>>
>>>
>>>>>>> obj-m += mxdm-debugfs.o
>>>>>
>>>
>>>>>>> all:
>>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
>>>>>
>>>
>>>>>>> clean:
>>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
>>>>>
>>>
>>>>>>> I then ran "make" and loaded the module.
>>>>>
>>>
>>>>>> Ah, yes, I should have mentioned specifically that the instructions
>>>>>> assumed either a split Kbuild configuration with separate source and
>>>>>> output directories, or a single combined source and output directory but
>>>>>> with "source" and "build" both being symlinks to the same directory. I
>>>>>> forget which distros do what exactly, but some ship a combined
>>>>>> source/output directory but only have one of either "source" or "build";
>>>>>> yours appears to be the latter configuration. I'm glad you were able to
>>>>>> get it building anyway.
>>>>>
>>>
>>>>>>> 1) Hybrid mode set to "Enabled" from the bios settings,
>>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
>>>>>>> 2) Hybrid mode set to "Disabled" from the bios settings,
>>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
>>>>>
>>>
>>>>>> Okay. This is consistent with my expectations. If we also find that the
>>>>>> systems which require the quirk report either "discrete", "hybrid", or
>>>>>> "integrated" (IIUC those systems do not have the mode configurable in the
>>>>>> UEFI settings), then I think we can fix the quirk by checking the mux
>>>>>> mode and only forcing to native if the system is not in hybrid mode.
>>>>>
>>>
>>>>>> Or perhaps we should just get rid of the quirk, and unconditionally test
>>>>>> the mux mode, and avoid using nvidia-wmi-ec-backlight on systems which
>>>>>> are not in "dynamic" mode, regardless of whether they expose the WMI EC
>>>>>> backlight interface and regardless of whether that interface reports
>>>>>> that the EC backlight driver should be used. (On the systems that need
>>>>>> the quirk, that interface is reporting that the backlight should be
>>>>>> EC-controlled even when it shouldn't be.) I think that in theory, it
>>>>>> should be possible for a system design to require EC backlight control
>>>>>> even when the mux is in a non-dynamic mode, but in practice I don't know
>>>>>> why anybody would do that, and am not aware of any systems which do so
>>>>>> (although until the report of the broken backlight on the 3050 version
>>>>>> of the Dell G15 5515, I wasn't aware of any systems that reported EC
>>>>>> backlight control when it was supposed to be native.)
>>>>>
>>>
>>>>>> Hans, I think the most reasonable options are:
>>>>>
>>>
>>>>>> 1) Remove the quirk, and check for MXDM when deciding whether a system
>>>>>> should use the EC backlight driver. This has the disadvantage of adding
>>>>>> a check where one isn't actually needed on some (most?) systems, and the
>>>>>> advantage of most likely avoiding the need to add quirks for other
>>>>>> systems where the system reports EC backlight control when native should
>>>>>> be used. It also has the possibility of being wrong on a theoretically
>>>>>> possible configuration, although if we ever encounter such a
>>>>>> configuration we could handle it with a quirk or find some other way to
>>>>>> distinguish between systems that do or do not require the EC backlight
>>>>>> driver.
>>>>>
>>>
>>>>>> 2) Keep the existing quirk, and only force to native if MXDM is missing
>>>>>> or if MXDM reports that the system is in a non-dynamic mode.
>>>>>
>>>
>>>>>> I'm inclined to go with (2), because it seems "safer", but am happy to
>>>>>> implement (1) if you think that's the better option. For the MXDM check
>>>>>> I think the first thing to do is to check whether the MXDM method is
>>>>>> present at all: as observed on at least one system, there is no MXDM
>>>>>> method when the system is in non-dynamic mode. Then if MXDM is present,
>>>>>> check whether it reports that the mux is in dynamic mode. For (1), only
>>>>>> query the WMI-wrapped API to determine the backlight control source if
>>>>>> the mux is in dynamic mode. For (2), only force the backlight to native
>>>>>> if the mux is not in dynamic mode.
>>>>>
>>>
>>>>>> This, again, assumes that none of the systems which require the quirk
>>>>>> report that the mux is in dynamic mode. If any of them do, we will need
>>>>>> to find a different way to determine which systems are lying about how
>>>>>> the backlight is supposed to be controlled.
>>>>>
>>>
>>>>>>> Regards,
>>>>>
>>>
>>>>>>> Youssef
>>>>>
>>>
>>>>>>> On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com wrote:
>>>>>
>>>
>>>>>>>> Hans pointed out a crucial omission in the build instructions in a
>>>>>>>> different thread where I also shared this test module:
>>>>>
>>>
>>>>>>>> On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
>>>>>
>>>
>>>>>>>>> Thanks, Hans.
>>>>>
>>>
>>>>>>>>> On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
>>>>>
>>>
>>>>>>>>>> Hi All,
>>>>>
>>>
>>>>>>>>>> On 1/11/23 10:51, Hans de Goede wrote:
>>>>>
>>>
>>>>>>>>>>> Hi,
>>>>>
>>>
>>>>>>>>>>> On 1/11/23 01:40, Daniel Dadap wrote:
>>>>>
>>>
>>>>>>>>>>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>>>>>
>>>
>>>>>>>>>>>>> Hi,
>>>>>
>>>
>>>>>>>>>>>>> On 1/10/23 16:19, Youssef Aly wrote:
>>>>>
>>>
>>>>>>>>>>>>>> Hi Hans,
>>>>>
>>>
>>>>>>>>>>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>>>>>>>>>>>>>> the kernel commandline for the patched kernel, it doesn't work without it.
>>>>>
>>>
>>>>>>>>>>>>>> I have 2 modes in the bios Hybrid on/off (hybrid / discrete). I tried
>>>>>>>>>>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>>>>>>>>>>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>>>>>
>>>
>>>>>>>>>>>>>> Hybrid:
>>>>>>>>>>>>>> "acpi_backlight=native": Does not work, /sys/class/backlight contains
>>>>>>>>>>>>>> amdgpu_bl1.
>>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>>>>>>>>>>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>>>>>
>>>
>>>>>>>>>>>>>> Discrete:
>>>>>>>>>>>>>> "acpi_backlight=native": Works but when brightness from 0-10 is the
>>>>>>>>>>>>>> same as 0-100, for example 10 is full brightness like 100, 8 is the
>>>>>>>>>>>>>> same as 80, etc... ,
>>>>>>>>>>>>>> /sys/class/backlight contains nvidia_0.
>>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work, /sys/class/backlight
>>>>>>>>>>>>>> contains nvidia_wmi_ec_backlight.
>>>>>
>>>
>>>>>>>>>>>>> Thank you for testing!
>>>>>
>>>
>>>>>>>>>>>>> Ok so it seems there are 2 issues at play here:
>>>>>
>>>
>>>>>>>>>>>>> 1. Depending on the BIOS setting we need to use either native (discrete mode)
>>>>>>>>>>>>> or nvidia_wmi_ec (hybrid mode)
>>>>>
>>>
>>>>>>>>>>>>> 2. There is a bug in the nvidia binary drivers backlight control in native
>>>>>>>>>>>>> mode on this system causing the range to be wrong
>>>>>
>>>
>>>>>>>>>>>>> Daniel, we really need help from NVidia with fixing 1. can you see if
>>>>>>>>>>>>> there is a way to check the BIOS setting/mode from inside the kernel ?
>>>>>
>>>
>>>>>>>>>>>> Yes, the ACPI MXDM method should be able to do this. However, querying
>>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical way to
>>>>>>>>>>>> determine whether the backlight is supposed to be EC-driven, since there
>>>>>>>>>>>> are EC-driven and non-EC-driven designs, so the BIOS mode is supposed to
>>>>>>>>>>>> be orthogonal to whether or not the EC driver should be used. It sounds
>>>>>>>>>>>> like the BIOS is possibly reporting a wrong value for that query.
>>>>>
>>>
>>>>>>>>>>>> I guess we could wire up a quirk that checks MXDM and overrides the
>>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from the current
>>>>>>>>>>>> mux operation mode. Then that quirk could be applied to this system.
>>>>>>>>>>>> I can put together a patch for that.
>>>>>
>>>
>>>>>>>>>>> If you can write a patch for this that would be great, thank you,
>>>>>>>>>>> but I think we first need to root-cause this better:
>>>>>
>>>
>>>>>>>>>>> Currently the Dell G15 5515 is DMI quirked inside: drivers/apci/video_detect.c
>>>>>>>>>>> to always use the native backlight. So I've gone back to the original email
>>>>>>>>>>> thread which lead to me adding that quirk.
>>>>>
>>>
>>>>>>>>>>> We (I forwarded a mail from you to the reporter this was not on the list)
>>>>>>>>>>> did ask to test with different BIOS settings their to and the reporter's
>>>>>>>>>>> reply was:
>>>>>
>>>
>>>>>>>>>>> "Daniel wanted me to check different GPU modes, but my BIOS has no options
>>>>>>>>>>> for GPU. It's always in hybrid mode with PRIME render offload."
>>>>>
>>>
>>>>>>>>>>> And perhaps even more interesting in their case with acpi_backlight=native
>>>>>>>>>>> to disable nvidia-wmi-ec they have a working amdgpu_bl# device. Where as
>>>>>>>>>>> in Youssef's case when running in discrete mode there is an nvidia backlight
>>>>>>>>>>> device and in Youssef's case the amdgpu_bl# device never works.
>>>>>
>>>
>>>>>>>>>>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H CPU (with iGPU)
>>>>>
>>>
>>>>>>>>>>> While the dGPU can be one of:
>>>>>>>>>>> NVIDIA GeForce RTX 3060
>>>>>>>>>>> NVIDIA GeForce GTX 3050 Ti
>>>>>>>>>>> NVIDIA GeForce GTX 3050
>>>>>
>>>
>>>>>>>>>>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code may only
>>>>>>>>>>> be relevant to the model with the 3060 and that nvidia-wmi-ec should
>>>>>>>>>>> maybe not load at all on the model with the 3050 versions.
>>>>>
>>>
>>>>>>>>>> A quick status update on this.
>>>>>
>>>
>>>>>>>>>> Iris (added to the Cc), the reporter with the Dell G15 5515 which lead me
>>>>>>>>>> to add the acpi_backlight=native DMI quirk for the Dell G15 5515 has
>>>>>>>>>> gotten back to me with lspci output on their G15 and it indeed has
>>>>>>>>>> a GTX 3050.
>>>>>
>>>
>>>>>>>>>> So atm we have the following models which are affected one way
>>>>>>>>>> or the other:
>>>>>
>>>
>>>>>>>>>> -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 :(
>>>>>
>>>
>>>>>>>>>> With the models which need acpi_backlight=native being broken
>>>>>>>>>> by (false positive) detection of the laptop needing nvidia-wmi-ec
>>>>>>>>>> for backlight control while they actually should not be using that.
>>>>>
>>>
>>>>>>>>>> and with the Dell G15 5515 with RTX 3060 atm being broken because
>>>>>>>>>> of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
>>>>>
>>>
>>>>>>>>> I've attached a simple kernel module which adds a debugfs file that
>>>>>>>>> reports the current mux mode. As mentioned elsewhere, I suspect that the
>>>>>>>>> systems which need the quirk may be in one of the non-dynamic modes, and
>>>>>>>>> the systems which are broken by the quirk may be in dynamic mux mode. It
>>>>>>>>> should be pretty straightforward to compile this as an out-of-tree
>>>>>>>>> module using the Kbuild extmod infrastructure, as follows:
>>>>>
>>>
>>>>>>>>> 1) Change to the directory containing the mxdm-debugfs.c file (you may
>>>>>>>>> wish to create an empty directory to put it in) and create a file in
>>>>>>>>> that directory containing the following line:
>>>>>
>>>
>>>>>>>> The name of this file should be 'Kbuild'. Sorry for the noise.
>>>>>
>>>
>>>>>>>>> obj-m += mxdm-debugfs.o
>>>>>
>>>
>>>>>>>>> 2) Build the kernel module:
>>>>>
>>>
>>>>>>>>> make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname -r)/build M=$(pwd)
>>>>>
>>>
>>>>>>>>> (The "source" and "build" paths under /lib/modules/`uname -r` should
>>>>>>>>> be the correct paths in almost all cases; if your system uses
>>>>>>>>> different paths, substitute those. You will need the development
>>>>>>>>> headers for external kernel modules, and the relevant toolchain bits,
>>>>>>>>> but if you're already using the NVIDIA proprietary driver you almost
>>>>>>>>> certainly already have all of that.)
>>>>>
>>>
>>>>>>>>> 3) Load the kernel module:
>>>>>
>>>
>>>>>>>>> insmod ./mxdm-debugfs.ko
>>>>>
>>>
>>>>>>>>> This should create a file at /sys/kernel/debug/acpi/mxdm_mux_mode.
>>>>>>>>> Reading this file should report the current mux operation mode.
>>>>>
>>>
>>>>>>>>> While switching mux modes on a dynamic mux system to test this kernel
>>>>>>>>> module, I noticed that the ACPI tables no longer exposed the MXDM method
>>>>>>>>> when the mux mode was set to discrete only on that particular system.
>>>>>>>>> This contradicted the behavior I had previously observed on other
>>>>>>>>> systems; i.e., that MXDM is always available regardless of the currently
>>>>>>>>> set mux mode, so I tried it on another dynamic mux system and observed
>>>>>>>>> that the other system does always expose MXDM regardless of the mux
>>>>>>>>> mode, and the contents of the debugfs file matched the selected mode.
>>>>>
>>>
>>>>>>>>> So if the module fails to load with ENODEV and prints the "MXDM not
>>>>>>>>> found" message to the kernel log, the system is most likely configured
>>>>>>>>> to a non-dynamic mux mode. My usual expectation is that it should load
>>>>>>>>> and create the file on most dynamic mux systems. I do not have direct
>>>>>>>>> access to any of the above listed systems at the moment, so I do not
>>>>>>>>> know whether MXDM will be exposed when the system is not in dynamic mux
>>>>>>>>> mode.
>>>>>
>>>
>>>>>>>>>> Regards,
>>>>>
>>>
>>>>>>>>>> Hans
>>>>>
>>>
>>>>>>>>> // SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>> /*
>>>>>>>>> * Copyright (C) 2020 NVIDIA Corporation
>>>>>>>>> *
>>>>>>>>> */
>>>>>
>>>
>>>>>>>>> #include <linux/acpi.h>
>>>>>>>>> #include <acpi/acoutput.h>
>>>>>>>>> #include <linux/module.h>
>>>>>>>>> #include <linux/pci.h>
>>>>>>>>> #include <linux/debugfs.h>
>>>>>
>>>
>>>>>>>>> extern struct dentry *acpi_debugfs_dir;
>>>>>
>>>
>>>>>>>>> enum mux_mode {
>>>>>>>>> MUX_MODE_UNKNOWN = 0,
>>>>>>>>> MUX_MODE_INTEGRATED = 1, /* iGPU only /
>>>>>>>>> MUX_MODE_DISCRETE = 2, / dGPU only /
>>>>>>>>> MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
>>>>>>>>> MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
>>>>>>>>> MUX_MODE_MAX
>>>>>>>>> };
>>>>>
>>>
>>>>>>>>> static char * mode_names[] = {
>>>>>>>>> [MUX_MODE_UNKNOWN] = "unknown\n",
>>>>>>>>> [MUX_MODE_INTEGRATED] = "integrated\n",
>>>>>>>>> [MUX_MODE_DISCRETE] = "discrete\n",
>>>>>>>>> [MUX_MODE_HYBRID] = "hybrid\n",
>>>>>>>>> [MUX_MODE_DYNAMIC] = "dynamic\n",
>>>>>>>>> };
>>>>>
>>>
>>>>>>>>> static struct debugfs_blob_wrapper muxmode_blob;
>>>>>
>>>
>>>>>>>>> static void store_mux_mode(acpi_handle handle)
>>>>>>>>> {
>>>>>>>>> union acpi_object arg = { .integer = { .type = ACPI_TYPE_INTEGER, .value = 0 } };
>>>>>>>>> struct acpi_object_list in = { .count = 1, .pointer = &arg };
>>>>>
>>>
>>>>>>>>> acpi_integer ret;
>>>>>>>>> acpi_status status;
>>>>>
>>>
>>>>>>>>> status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
>>>>>
>>>
>>>>>>>>> if (ACPI_FAILURE(status)) {
>>>>>>>>> acpi_handle_err(handle, "ACPI MXDM failed: %s\n", acpi_format_exception(status));
>>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>>>>>>>>> } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
>>>>>>>>> acpi_handle_err(handle, "Mux mode value out of range");
>>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>>>>>>>>> } else {
>>>>>>>>> muxmode_blob.data = mode_names[ret];
>>>>>>>>> }
>>>>>
>>>
>>>>>>>>> muxmode_blob.size = strlen(muxmode_blob.data);
>>>>>>>>> }
>>>>>
>>>
>>>>>>>>> static acpi_status find_mxdm(acpi_handle obj, u32 level, void *ctx, void **ret)
>>>>>>>>> {
>>>>>>>>> acpi_handle search;
>>>>>
>>>
>>>>>>>>> if (acpi_get_handle(obj, "MXDM", &search) == 0) {
>>>>>>>>> /* Found the parent object of the MXDM method; pass it back
>>>>>>>>> * to the caller and stop searching. */
>>>>>>>>> *ret = obj;
>>>>>
>>>
>>>>>>>>> return AE_CTRL_TERMINATE;
>>>>>>>>> }
>>>>>
>>>
>>>>>>>>> /* No MXDM; keep looking */
>>>>>>>>> return AE_OK;
>>>>>>>>> }
>>>>>
>>>
>>>>>>>>> static struct dentry *muxmode_file_dentry;
>>>>>
>>>
>>>>>>>>> static int __init mxdm_debugfs_init(void)
>>>>>>>>> {
>>>>>>>>> acpi_handle mxdm_handle = NULL;
>>>>>>>>> acpi_status ret;
>>>>>
>>>
>>>>>>>>> ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
>>>>>>>>> find_mxdm, NULL, NULL, &mxdm_handle);
>>>>>
>>>
>>>>>>>>> if (ACPI_FAILURE(ret) || !mxdm_handle) {
>>>>>>>>> pr_err("MXDM not found.\n");
>>>>>>>>> return -ENODEV;
>>>>>>>>> }
>>>>>
>>>
>>>>>>>>> /* Populate the blob wrapper: the mux mode cannot change without rebooting
>>>>>>>>> * so this only needs to be done once. */
>>>>>>>>> store_mux_mode(mxdm_handle);
>>>>>
>>>
>>>>>>>>> muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
>>>>>>>>> acpi_debugfs_dir,
>>>>>>>>> &muxmode_blob);
>>>>>
>>>
>>>>>>>>> return muxmode_file_dentry ? 0 : -EIO;
>>>>>>>>> }
>>>>>>>>> module_init(mxdm_debugfs_init);
>>>>>
>>>
>>>>>>>>> static void __exit mxdm_debugfs_exit(void)
>>>>>>>>> {
>>>>>>>>> if (muxmode_file_dentry) {
>>>>>>>>> debugfs_remove(muxmode_file_dentry);
>>>>>>>>> muxmode_file_dentry = NULL;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> module_exit(mxdm_debugfs_exit);
>>>>>
>>>
>>>>>>>>> MODULE_LICENSE("GPL v2");
>>>>>>>>> MODULE_DESCRIPTION("MXDM mux mode test module");
>>>>>>>>> MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
>>>>>
>>>
>>>>>>>>> /*
>>>>>>>>> * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so key off of
>>>>>>>>> * the WMI wrapper for the related WMAA method for backlight control.
>>>>>>>>> */
>>>>>>>>> MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
>>>>
>>>
>>>>
>>>
>>>>
> 
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Daniel Dadap]

On Fri, Feb 17, 2023 at 05:04:52PM +0200, Youssef Aly wrote:
> Yes, I sent the data to daniel. I am currently just using an older kernel
> (6.0) before the regression.

Thanks, Youssef. I am also only seeing the test kernel module results as
the most recent message I have from you. If you sent the ACPI table dumps
as an attachment, there is a chance they got filtered out - this happened
with another ACPI dump that somebody tried to send me. Perhaps posting the
files to a file sharing site might work better - it would be interesting
to compare your ACPI table dump to another from a different 5515 model.

> On Fri, Feb 17, 2023, 2:36 PM Linux regression tracking (Thorsten Leemhuis)
> <regressions@leemhuis.info> wrote:
> 
> > On 18.01.23 23:11, Daniel Dadap wrote:
> > > On Thu, Jan 19, 2023 at 12:02:50AM +0200, Youssef Aly wrote:
> > >> I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
> > >> x_state contained "integrated".
> > >>
> > >> I ran
> > >> echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
> > >> now it contained ''discrete' and the screen turned off.
> > >> then I return it to its initial state.
> > >>
> > >> Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
> > >> but it didn't work, had to reboot, I am running gnome on wayland.
> > >
> > > Your system does allow you to switch the mux mode in the UEFI setup
> > > screen, correct? If you could share your ACPI tables as well (see the
> > > instructions in a fork of this thread) that would be helpful.
> >
> > I might be missing something, but it looks like this discussion stalled
> > here.
> >
> > Youssef Aly, did you ever share the data Daniel asked for? Or did you
> > stop caring? Maybe because it works / you found a workaround?
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
> >
> > #regzbot poke
> >
> > > It sounds like your system has a functional dynamic mux, which would be
> > > consistent with being able to choose different mux modes in UEFI setup.
> > > The screen not coming back up isn't a big concern: triggering the
> > > hotplug is something that's *supposed* to work (and it worked on the
> > > AMD+NVIDIA system I tried it on), but I am not surprised if it doesn't
> > > work everywhere.
> > >
> > >>
> > >> On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
> > >>>
> > >>> After loading the updated module,
> > /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
> > >>>
> > >>> Now, i ran the command
> > >>> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
> > >>>
> > >>> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my
> > screen didn't turn off... I changed it back to integrated, then to discrete
> > again, it seems like nothing happened, or did i do something wrong?
> > >>>
> > >>>
> > >>> ------- Original Message -------
> > >>> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <
> > ddadap@nvidia.com> wrote:
> > >>>
> > >>>
> > >>>> Thanks, Iris:
> > >>>>
> > >>>
> > >>>> On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
> > >>>>
> > >>>
> > >>>>> I have followed Youssef's instructions to build the module, and
> > after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
> > >>>>
> > >>>
> > >>>>
> > >>>
> > >>>> That is unfortunate. I was hoping it would report a non-dynamic mode,
> > which
> > >>>> would make it easier to disambiguate between G15 5515 models which
> > require
> > >>>> EC backlight control and G15 5515 models which require native
> > GPU-driven
> > >>>> backlight control.
> > >>>>
> > >>>
> > >>>> I have attached an updated version of the test module which will
> > allow you
> > >>>> to test if your system does have a dynamic mux. Build and load it the
> > same
> > >>>> way as the previous one (unload the previous one first if you haven't
> > done
> > >>>> so or rebooted already). This adds
> > /sys/kernel/debug/acpi/mxds_mux_state: if
> > >>>> you see this file, read out its contents. I expect that on your
> > system it
> > >>>> should report "integrated", since IIUC the amdgpu_bl backlight device
> > is the
> > >>>> one that works on your system. If you do not see this file, and the
> > message
> > >>>> "MXDS not found" appears in your kernel log, then your ACPI table
> > doesn't
> > >>>> expose the MXDS method, which could be a useful disambiguation test.
> > >>>>
> > >>>
> > >>>> Another experiment to try would be to flip the state of the mux.
> > Before
> > >>>> attempting this experiment, make sure to save any work and log in
> > remotely
> > >>>> from another machine, since it is possible that your screen will go
> > blank
> > >>>> and will need a reboot in order to come back up. To change the mux
> > state,
> > >>>> write the target mux state to the mxds_mux_state file. Use whatever
> > the
> > >>>> opposite of the current value is, i.e., if it reads out as
> > "integrated",
> > >>>> then write "discrete", and vice versa. If the mux switch worked, your
> > >>>> screen should go blank and reading the mxds_mux_state file again
> > should
> > >>>> reflect the new state. You can then flip the mux back to its original
> > >>>> position, and you should be able to get the display back by forcing
> > >>>> DPMS off and then on again. If you're not running X, writing a '0'
> > then
> > >>>> writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems
> > to
> > >>>> work on my AMD+NVIDIA system. (The DRI device and eDP connector ID
> > might
> > >>>> be enumerated differently on your system.) If neither of those work to
> > >>>> bring your display back up, then reboot the computer.
> > >>>>
> > >>>
> > >>>> The most interesting data would be to check whether MXDS is available
> > in
> > >>>> your system's ACPI tables, and if so, whether it is actually
> > functional.
> > >>>>
> > >>>
> > >>>>> As mentioned before, this RTX 3050 system does not have configurable
> > GPU mode.
> > >>>>>
> > >>>
> > >>>>> ------- Original Message -------
> > >>>>> On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap
> > ddadap@nvidia.com wrote:
> > >>>>>
> > >>>
> > >>>>>> On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> > >>>>>
> > >>>
> > >>>>>>> Hello Daniel,
> > >>>>>
> > >>>
> > >>>>>>> I tried building the module using the instructions you provided,
> > but
> > >>>>>>> ran into some problems as I didn't have the /lib/modules/$(uname
> > >>>>>>> -r)/source directory on my end.
> > >>>>>>> I created a Makefile in a directory containing mxdm-debugfs.c file
> > and
> > >>>>>>> added the following to it:
> > >>>>>
> > >>>
> > >>>>>>> obj-m += mxdm-debugfs.o
> > >>>>>
> > >>>
> > >>>>>>> all:
> > >>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> > >>>>>
> > >>>
> > >>>>>>> clean:
> > >>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > >>>>>
> > >>>
> > >>>>>>> I then ran "make" and loaded the module.
> > >>>>>
> > >>>
> > >>>>>> Ah, yes, I should have mentioned specifically that the instructions
> > >>>>>> assumed either a split Kbuild configuration with separate source and
> > >>>>>> output directories, or a single combined source and output
> > directory but
> > >>>>>> with "source" and "build" both being symlinks to the same
> > directory. I
> > >>>>>> forget which distros do what exactly, but some ship a combined
> > >>>>>> source/output directory but only have one of either "source" or
> > "build";
> > >>>>>> yours appears to be the latter configuration. I'm glad you were
> > able to
> > >>>>>> get it building anyway.
> > >>>>>
> > >>>
> > >>>>>>> 1) Hybrid mode set to "Enabled" from the bios settings,
> > >>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> > >>>>>>> 2) Hybrid mode set to "Disabled" from the bios settings,
> > >>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> > >>>>>
> > >>>
> > >>>>>> Okay. This is consistent with my expectations. If we also find that
> > the
> > >>>>>> systems which require the quirk report either "discrete", "hybrid",
> > or
> > >>>>>> "integrated" (IIUC those systems do not have the mode configurable
> > in the
> > >>>>>> UEFI settings), then I think we can fix the quirk by checking the
> > mux
> > >>>>>> mode and only forcing to native if the system is not in hybrid mode.
> > >>>>>
> > >>>
> > >>>>>> Or perhaps we should just get rid of the quirk, and unconditionally
> > test
> > >>>>>> the mux mode, and avoid using nvidia-wmi-ec-backlight on systems
> > which
> > >>>>>> are not in "dynamic" mode, regardless of whether they expose the
> > WMI EC
> > >>>>>> backlight interface and regardless of whether that interface reports
> > >>>>>> that the EC backlight driver should be used. (On the systems that
> > need
> > >>>>>> the quirk, that interface is reporting that the backlight should be
> > >>>>>> EC-controlled even when it shouldn't be.) I think that in theory, it
> > >>>>>> should be possible for a system design to require EC backlight
> > control
> > >>>>>> even when the mux is in a non-dynamic mode, but in practice I don't
> > know
> > >>>>>> why anybody would do that, and am not aware of any systems which do
> > so
> > >>>>>> (although until the report of the broken backlight on the 3050
> > version
> > >>>>>> of the Dell G15 5515, I wasn't aware of any systems that reported EC
> > >>>>>> backlight control when it was supposed to be native.)
> > >>>>>
> > >>>
> > >>>>>> Hans, I think the most reasonable options are:
> > >>>>>
> > >>>
> > >>>>>> 1) Remove the quirk, and check for MXDM when deciding whether a
> > system
> > >>>>>> should use the EC backlight driver. This has the disadvantage of
> > adding
> > >>>>>> a check where one isn't actually needed on some (most?) systems,
> > and the
> > >>>>>> advantage of most likely avoiding the need to add quirks for other
> > >>>>>> systems where the system reports EC backlight control when native
> > should
> > >>>>>> be used. It also has the possibility of being wrong on a
> > theoretically
> > >>>>>> possible configuration, although if we ever encounter such a
> > >>>>>> configuration we could handle it with a quirk or find some other
> > way to
> > >>>>>> distinguish between systems that do or do not require the EC
> > backlight
> > >>>>>> driver.
> > >>>>>
> > >>>
> > >>>>>> 2) Keep the existing quirk, and only force to native if MXDM is
> > missing
> > >>>>>> or if MXDM reports that the system is in a non-dynamic mode.
> > >>>>>
> > >>>
> > >>>>>> I'm inclined to go with (2), because it seems "safer", but am happy
> > to
> > >>>>>> implement (1) if you think that's the better option. For the MXDM
> > check
> > >>>>>> I think the first thing to do is to check whether the MXDM method is
> > >>>>>> present at all: as observed on at least one system, there is no MXDM
> > >>>>>> method when the system is in non-dynamic mode. Then if MXDM is
> > present,
> > >>>>>> check whether it reports that the mux is in dynamic mode. For (1),
> > only
> > >>>>>> query the WMI-wrapped API to determine the backlight control source
> > if
> > >>>>>> the mux is in dynamic mode. For (2), only force the backlight to
> > native
> > >>>>>> if the mux is not in dynamic mode.
> > >>>>>
> > >>>
> > >>>>>> This, again, assumes that none of the systems which require the
> > quirk
> > >>>>>> report that the mux is in dynamic mode. If any of them do, we will
> > need
> > >>>>>> to find a different way to determine which systems are lying about
> > how
> > >>>>>> the backlight is supposed to be controlled.
> > >>>>>
> > >>>
> > >>>>>>> Regards,
> > >>>>>
> > >>>
> > >>>>>>> Youssef
> > >>>>>
> > >>>
> > >>>>>>> On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com
> > wrote:
> > >>>>>
> > >>>
> > >>>>>>>> Hans pointed out a crucial omission in the build instructions in a
> > >>>>>>>> different thread where I also shared this test module:
> > >>>>>
> > >>>
> > >>>>>>>> On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> > >>>>>
> > >>>
> > >>>>>>>>> Thanks, Hans.
> > >>>>>
> > >>>
> > >>>>>>>>> On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> > >>>>>
> > >>>
> > >>>>>>>>>> Hi All,
> > >>>>>
> > >>>
> > >>>>>>>>>> On 1/11/23 10:51, Hans de Goede wrote:
> > >>>>>
> > >>>
> > >>>>>>>>>>> Hi,
> > >>>>>
> > >>>
> > >>>>>>>>>>> On 1/11/23 01:40, Daniel Dadap wrote:
> > >>>>>
> > >>>
> > >>>>>>>>>>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> > >>>>>
> > >>>
> > >>>>>>>>>>>>> Hi,
> > >>>>>
> > >>>
> > >>>>>>>>>>>>> On 1/10/23 16:19, Youssef Aly wrote:
> > >>>>>
> > >>>
> > >>>>>>>>>>>>>> Hi Hans,
> > >>>>>
> > >>>
> > >>>>>>>>>>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> > >>>>>>>>>>>>>> the kernel commandline for the patched kernel, it doesn't
> > work without it.
> > >>>>>
> > >>>
> > >>>>>>>>>>>>>> I have 2 modes in the bios Hybrid on/off (hybrid /
> > discrete). I tried
> > >>>>>>>>>>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> > >>>>>>>>>>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> > >>>>>
> > >>>
> > >>>>>>>>>>>>>> Hybrid:
> > >>>>>>>>>>>>>> "acpi_backlight=native": Does not work,
> > /sys/class/backlight contains
> > >>>>>>>>>>>>>> amdgpu_bl1.
> > >>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> > >>>>>>>>>>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> > >>>>>
> > >>>
> > >>>>>>>>>>>>>> Discrete:
> > >>>>>>>>>>>>>> "acpi_backlight=native": Works but when brightness from
> > 0-10 is the
> > >>>>>>>>>>>>>> same as 0-100, for example 10 is full brightness like 100,
> > 8 is the
> > >>>>>>>>>>>>>> same as 80, etc... ,
> > >>>>>>>>>>>>>> /sys/class/backlight contains nvidia_0.
> > >>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work,
> > /sys/class/backlight
> > >>>>>>>>>>>>>> contains nvidia_wmi_ec_backlight.
> > >>>>>
> > >>>
> > >>>>>>>>>>>>> Thank you for testing!
> > >>>>>
> > >>>
> > >>>>>>>>>>>>> Ok so it seems there are 2 issues at play here:
> > >>>>>
> > >>>
> > >>>>>>>>>>>>> 1. Depending on the BIOS setting we need to use either
> > native (discrete mode)
> > >>>>>>>>>>>>> or nvidia_wmi_ec (hybrid mode)
> > >>>>>
> > >>>
> > >>>>>>>>>>>>> 2. There is a bug in the nvidia binary drivers backlight
> > control in native
> > >>>>>>>>>>>>> mode on this system causing the range to be wrong
> > >>>>>
> > >>>
> > >>>>>>>>>>>>> Daniel, we really need help from NVidia with fixing 1. can
> > you see if
> > >>>>>>>>>>>>> there is a way to check the BIOS setting/mode from inside
> > the kernel ?
> > >>>>>
> > >>>
> > >>>>>>>>>>>> Yes, the ACPI MXDM method should be able to do this. However,
> > querying
> > >>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical
> > way to
> > >>>>>>>>>>>> determine whether the backlight is supposed to be EC-driven,
> > since there
> > >>>>>>>>>>>> are EC-driven and non-EC-driven designs, so the BIOS mode is
> > supposed to
> > >>>>>>>>>>>> be orthogonal to whether or not the EC driver should be used.
> > It sounds
> > >>>>>>>>>>>> like the BIOS is possibly reporting a wrong value for that
> > query.
> > >>>>>
> > >>>
> > >>>>>>>>>>>> I guess we could wire up a quirk that checks MXDM and
> > overrides the
> > >>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from
> > the current
> > >>>>>>>>>>>> mux operation mode. Then that quirk could be applied to this
> > system.
> > >>>>>>>>>>>> I can put together a patch for that.
> > >>>>>
> > >>>
> > >>>>>>>>>>> If you can write a patch for this that would be great, thank
> > you,
> > >>>>>>>>>>> but I think we first need to root-cause this better:
> > >>>>>
> > >>>
> > >>>>>>>>>>> Currently the Dell G15 5515 is DMI quirked inside:
> > drivers/apci/video_detect.c
> > >>>>>>>>>>> to always use the native backlight. So I've gone back to the
> > original email
> > >>>>>>>>>>> thread which lead to me adding that quirk.
> > >>>>>
> > >>>
> > >>>>>>>>>>> We (I forwarded a mail from you to the reporter this was not
> > on the list)
> > >>>>>>>>>>> did ask to test with different BIOS settings their to and the
> > reporter's
> > >>>>>>>>>>> reply was:
> > >>>>>
> > >>>
> > >>>>>>>>>>> "Daniel wanted me to check different GPU modes, but my BIOS
> > has no options
> > >>>>>>>>>>> for GPU. It's always in hybrid mode with PRIME render offload."
> > >>>>>
> > >>>
> > >>>>>>>>>>> And perhaps even more interesting in their case with
> > acpi_backlight=native
> > >>>>>>>>>>> to disable nvidia-wmi-ec they have a working amdgpu_bl#
> > device. Where as
> > >>>>>>>>>>> in Youssef's case when running in discrete mode there is an
> > nvidia backlight
> > >>>>>>>>>>> device and in Youssef's case the amdgpu_bl# device never works.
> > >>>>>
> > >>>
> > >>>>>>>>>>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H
> > CPU (with iGPU)
> > >>>>>
> > >>>
> > >>>>>>>>>>> While the dGPU can be one of:
> > >>>>>>>>>>> NVIDIA GeForce RTX 3060
> > >>>>>>>>>>> NVIDIA GeForce GTX 3050 Ti
> > >>>>>>>>>>> NVIDIA GeForce GTX 3050
> > >>>>>
> > >>>
> > >>>>>>>>>>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code
> > may only
> > >>>>>>>>>>> be relevant to the model with the 3060 and that nvidia-wmi-ec
> > should
> > >>>>>>>>>>> maybe not load at all on the model with the 3050 versions.
> > >>>>>
> > >>>
> > >>>>>>>>>> A quick status update on this.
> > >>>>>
> > >>>
> > >>>>>>>>>> Iris (added to the Cc), the reporter with the Dell G15 5515
> > which lead me
> > >>>>>>>>>> to add the acpi_backlight=native DMI quirk for the Dell G15
> > 5515 has
> > >>>>>>>>>> gotten back to me with lspci output on their G15 and it indeed
> > has
> > >>>>>>>>>> a GTX 3050.
> > >>>>>
> > >>>
> > >>>>>>>>>> So atm we have the following models which are affected one way
> > >>>>>>>>>> or the other:
> > >>>>>
> > >>>
> > >>>>>>>>>> -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
> > :(
> > >>>>>
> > >>>
> > >>>>>>>>>> With the models which need acpi_backlight=native being broken
> > >>>>>>>>>> by (false positive) detection of the laptop needing
> > nvidia-wmi-ec
> > >>>>>>>>>> for backlight control while they actually should not be using
> > that.
> > >>>>>
> > >>>
> > >>>>>>>>>> and with the Dell G15 5515 with RTX 3060 atm being broken
> > because
> > >>>>>>>>>> of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> > >>>>>
> > >>>
> > >>>>>>>>> I've attached a simple kernel module which adds a debugfs file
> > that
> > >>>>>>>>> reports the current mux mode. As mentioned elsewhere, I suspect
> > that the
> > >>>>>>>>> systems which need the quirk may be in one of the non-dynamic
> > modes, and
> > >>>>>>>>> the systems which are broken by the quirk may be in dynamic mux
> > mode. It
> > >>>>>>>>> should be pretty straightforward to compile this as an
> > out-of-tree
> > >>>>>>>>> module using the Kbuild extmod infrastructure, as follows:
> > >>>>>
> > >>>
> > >>>>>>>>> 1) Change to the directory containing the mxdm-debugfs.c file
> > (you may
> > >>>>>>>>> wish to create an empty directory to put it in) and create a
> > file in
> > >>>>>>>>> that directory containing the following line:
> > >>>>>
> > >>>
> > >>>>>>>> The name of this file should be 'Kbuild'. Sorry for the noise.
> > >>>>>
> > >>>
> > >>>>>>>>> obj-m += mxdm-debugfs.o
> > >>>>>
> > >>>
> > >>>>>>>>> 2) Build the kernel module:
> > >>>>>
> > >>>
> > >>>>>>>>> make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname
> > -r)/build M=$(pwd)
> > >>>>>
> > >>>
> > >>>>>>>>> (The "source" and "build" paths under /lib/modules/`uname -r`
> > should
> > >>>>>>>>> be the correct paths in almost all cases; if your system uses
> > >>>>>>>>> different paths, substitute those. You will need the development
> > >>>>>>>>> headers for external kernel modules, and the relevant toolchain
> > bits,
> > >>>>>>>>> but if you're already using the NVIDIA proprietary driver you
> > almost
> > >>>>>>>>> certainly already have all of that.)
> > >>>>>
> > >>>
> > >>>>>>>>> 3) Load the kernel module:
> > >>>>>
> > >>>
> > >>>>>>>>> insmod ./mxdm-debugfs.ko
> > >>>>>
> > >>>
> > >>>>>>>>> This should create a file at
> > /sys/kernel/debug/acpi/mxdm_mux_mode.
> > >>>>>>>>> Reading this file should report the current mux operation mode.
> > >>>>>
> > >>>
> > >>>>>>>>> While switching mux modes on a dynamic mux system to test this
> > kernel
> > >>>>>>>>> module, I noticed that the ACPI tables no longer exposed the
> > MXDM method
> > >>>>>>>>> when the mux mode was set to discrete only on that particular
> > system.
> > >>>>>>>>> This contradicted the behavior I had previously observed on other
> > >>>>>>>>> systems; i.e., that MXDM is always available regardless of the
> > currently
> > >>>>>>>>> set mux mode, so I tried it on another dynamic mux system and
> > observed
> > >>>>>>>>> that the other system does always expose MXDM regardless of the
> > mux
> > >>>>>>>>> mode, and the contents of the debugfs file matched the selected
> > mode.
> > >>>>>
> > >>>
> > >>>>>>>>> So if the module fails to load with ENODEV and prints the "MXDM
> > not
> > >>>>>>>>> found" message to the kernel log, the system is most likely
> > configured
> > >>>>>>>>> to a non-dynamic mux mode. My usual expectation is that it
> > should load
> > >>>>>>>>> and create the file on most dynamic mux systems. I do not have
> > direct
> > >>>>>>>>> access to any of the above listed systems at the moment, so I do
> > not
> > >>>>>>>>> know whether MXDM will be exposed when the system is not in
> > dynamic mux
> > >>>>>>>>> mode.
> > >>>>>
> > >>>
> > >>>>>>>>>> Regards,
> > >>>>>
> > >>>
> > >>>>>>>>>> Hans
> > >>>>>
> > >>>
> > >>>>>>>>> // SPDX-License-Identifier: GPL-2.0-only
> > >>>>>>>>> /*
> > >>>>>>>>> * Copyright (C) 2020 NVIDIA Corporation
> > >>>>>>>>> *
> > >>>>>>>>> */
> > >>>>>
> > >>>
> > >>>>>>>>> #include <linux/acpi.h>
> > >>>>>>>>> #include <acpi/acoutput.h>
> > >>>>>>>>> #include <linux/module.h>
> > >>>>>>>>> #include <linux/pci.h>
> > >>>>>>>>> #include <linux/debugfs.h>
> > >>>>>
> > >>>
> > >>>>>>>>> extern struct dentry *acpi_debugfs_dir;
> > >>>>>
> > >>>
> > >>>>>>>>> enum mux_mode {
> > >>>>>>>>> MUX_MODE_UNKNOWN = 0,
> > >>>>>>>>> MUX_MODE_INTEGRATED = 1, /* iGPU only /
> > >>>>>>>>> MUX_MODE_DISCRETE = 2, / dGPU only /
> > >>>>>>>>> MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> > >>>>>>>>> MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> > >>>>>>>>> MUX_MODE_MAX
> > >>>>>>>>> };
> > >>>>>
> > >>>
> > >>>>>>>>> static char * mode_names[] = {
> > >>>>>>>>> [MUX_MODE_UNKNOWN] = "unknown\n",
> > >>>>>>>>> [MUX_MODE_INTEGRATED] = "integrated\n",
> > >>>>>>>>> [MUX_MODE_DISCRETE] = "discrete\n",
> > >>>>>>>>> [MUX_MODE_HYBRID] = "hybrid\n",
> > >>>>>>>>> [MUX_MODE_DYNAMIC] = "dynamic\n",
> > >>>>>>>>> };
> > >>>>>
> > >>>
> > >>>>>>>>> static struct debugfs_blob_wrapper muxmode_blob;
> > >>>>>
> > >>>
> > >>>>>>>>> static void store_mux_mode(acpi_handle handle)
> > >>>>>>>>> {
> > >>>>>>>>> union acpi_object arg = { .integer = { .type =
> > ACPI_TYPE_INTEGER, .value = 0 } };
> > >>>>>>>>> struct acpi_object_list in = { .count = 1, .pointer = &arg };
> > >>>>>
> > >>>
> > >>>>>>>>> acpi_integer ret;
> > >>>>>>>>> acpi_status status;
> > >>>>>
> > >>>
> > >>>>>>>>> status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> > >>>>>
> > >>>
> > >>>>>>>>> if (ACPI_FAILURE(status)) {
> > >>>>>>>>> acpi_handle_err(handle, "ACPI MXDM failed: %s\n",
> > acpi_format_exception(status));
> > >>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > >>>>>>>>> } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> > >>>>>>>>> acpi_handle_err(handle, "Mux mode value out of range");
> > >>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> > >>>>>>>>> } else {
> > >>>>>>>>> muxmode_blob.data = mode_names[ret];
> > >>>>>>>>> }
> > >>>>>
> > >>>
> > >>>>>>>>> muxmode_blob.size = strlen(muxmode_blob.data);
> > >>>>>>>>> }
> > >>>>>
> > >>>
> > >>>>>>>>> static acpi_status find_mxdm(acpi_handle obj, u32 level, void
> > *ctx, void **ret)
> > >>>>>>>>> {
> > >>>>>>>>> acpi_handle search;
> > >>>>>
> > >>>
> > >>>>>>>>> if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> > >>>>>>>>> /* Found the parent object of the MXDM method; pass it back
> > >>>>>>>>> * to the caller and stop searching. */
> > >>>>>>>>> *ret = obj;
> > >>>>>
> > >>>
> > >>>>>>>>> return AE_CTRL_TERMINATE;
> > >>>>>>>>> }
> > >>>>>
> > >>>
> > >>>>>>>>> /* No MXDM; keep looking */
> > >>>>>>>>> return AE_OK;
> > >>>>>>>>> }
> > >>>>>
> > >>>
> > >>>>>>>>> static struct dentry *muxmode_file_dentry;
> > >>>>>
> > >>>
> > >>>>>>>>> static int __init mxdm_debugfs_init(void)
> > >>>>>>>>> {
> > >>>>>>>>> acpi_handle mxdm_handle = NULL;
> > >>>>>>>>> acpi_status ret;
> > >>>>>
> > >>>
> > >>>>>>>>> ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> > >>>>>>>>> find_mxdm, NULL, NULL, &mxdm_handle);
> > >>>>>
> > >>>
> > >>>>>>>>> if (ACPI_FAILURE(ret) || !mxdm_handle) {
> > >>>>>>>>> pr_err("MXDM not found.\n");
> > >>>>>>>>> return -ENODEV;
> > >>>>>>>>> }
> > >>>>>
> > >>>
> > >>>>>>>>> /* Populate the blob wrapper: the mux mode cannot change without
> > rebooting
> > >>>>>>>>> * so this only needs to be done once. */
> > >>>>>>>>> store_mux_mode(mxdm_handle);
> > >>>>>
> > >>>
> > >>>>>>>>> muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> > >>>>>>>>> acpi_debugfs_dir,
> > >>>>>>>>> &muxmode_blob);
> > >>>>>
> > >>>
> > >>>>>>>>> return muxmode_file_dentry ? 0 : -EIO;
> > >>>>>>>>> }
> > >>>>>>>>> module_init(mxdm_debugfs_init);
> > >>>>>
> > >>>
> > >>>>>>>>> static void __exit mxdm_debugfs_exit(void)
> > >>>>>>>>> {
> > >>>>>>>>> if (muxmode_file_dentry) {
> > >>>>>>>>> debugfs_remove(muxmode_file_dentry);
> > >>>>>>>>> muxmode_file_dentry = NULL;
> > >>>>>>>>> }
> > >>>>>>>>> }
> > >>>>>>>>> module_exit(mxdm_debugfs_exit);
> > >>>>>
> > >>>
> > >>>>>>>>> MODULE_LICENSE("GPL v2");
> > >>>>>>>>> MODULE_DESCRIPTION("MXDM mux mode test module");
> > >>>>>>>>> MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> > >>>>>
> > >>>
> > >>>>>>>>> /*
> > >>>>>>>>> * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so
> > key off of
> > >>>>>>>>> * the WMI wrapper for the related WMAA method for backlight
> > control.
> > >>>>>>>>> */
> > >>>>>>>>> MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
> > >>>>
> > >>>
> > >>>>
> > >>>
> > >>>>
> > >
> > >
> >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Ahmed]

Hello Daniel,

I added the file to gdrive, and here is the link
https://drive.google.com/file/d/14JUpD78jJkXwjgJz5bY3nUzp-LFlZ6dC/view?usp=drivesdk

Let me know if you have any problem accessing the file.

Regards,

Youssef

On February 17, 2023 8:56:13 PM GMT+02:00, Daniel Dadap <ddadap@nvidia.com> wrote:
>On Fri, Feb 17, 2023 at 05:04:52PM +0200, Youssef Aly wrote:
>> Yes, I sent the data to daniel. I am currently just using an older kernel
>> (6.0) before the regression.
>
>Thanks, Youssef. I am also only seeing the test kernel module results as
>the most recent message I have from you. If you sent the ACPI table dumps
>as an attachment, there is a chance they got filtered out - this happened
>with another ACPI dump that somebody tried to send me. Perhaps posting the
>files to a file sharing site might work better - it would be interesting
>to compare your ACPI table dump to another from a different 5515 model.
>
>> On Fri, Feb 17, 2023, 2:36 PM Linux regression tracking (Thorsten Leemhuis)
>> <regressions@leemhuis.info> wrote:
>> 
>> > On 18.01.23 23:11, Daniel Dadap wrote:
>> > > On Thu, Jan 19, 2023 at 12:02:50AM +0200, Youssef Aly wrote:
>> > >> I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
>> > >> x_state contained "integrated".
>> > >>
>> > >> I ran
>> > >> echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
>> > >> now it contained ''discrete' and the screen turned off.
>> > >> then I return it to its initial state.
>> > >>
>> > >> Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
>> > >> but it didn't work, had to reboot, I am running gnome on wayland.
>> > >
>> > > Your system does allow you to switch the mux mode in the UEFI setup
>> > > screen, correct? If you could share your ACPI tables as well (see the
>> > > instructions in a fork of this thread) that would be helpful.
>> >
>> > I might be missing something, but it looks like this discussion stalled
>> > here.
>> >
>> > Youssef Aly, did you ever share the data Daniel asked for? Or did you
>> > stop caring? Maybe because it works / you found a workaround?
>> >
>> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>> > --
>> > Everything you wanna know about Linux kernel regression tracking:
>> > https://linux-regtracking.leemhuis.info/about/#tldr
>> > If I did something stupid, please tell me, as explained on that page.
>> >
>> > #regzbot poke
>> >
>> > > It sounds like your system has a functional dynamic mux, which would be
>> > > consistent with being able to choose different mux modes in UEFI setup.
>> > > The screen not coming back up isn't a big concern: triggering the
>> > > hotplug is something that's *supposed* to work (and it worked on the
>> > > AMD+NVIDIA system I tried it on), but I am not surprised if it doesn't
>> > > work everywhere.
>> > >
>> > >>
>> > >> On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
>> > >>>
>> > >>> After loading the updated module,
>> > /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
>> > >>>
>> > >>> Now, i ran the command
>> > >>> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
>> > >>>
>> > >>> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my
>> > screen didn't turn off... I changed it back to integrated, then to discrete
>> > again, it seems like nothing happened, or did i do something wrong?
>> > >>>
>> > >>>
>> > >>> ------- Original Message -------
>> > >>> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <
>> > ddadap@nvidia.com> wrote:
>> > >>>
>> > >>>
>> > >>>> Thanks, Iris:
>> > >>>>
>> > >>>
>> > >>>> On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
>> > >>>>
>> > >>>
>> > >>>>> I have followed Youssef's instructions to build the module, and
>> > after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
>> > >>>>
>> > >>>
>> > >>>>
>> > >>>
>> > >>>> That is unfortunate. I was hoping it would report a non-dynamic mode,
>> > which
>> > >>>> would make it easier to disambiguate between G15 5515 models which
>> > require
>> > >>>> EC backlight control and G15 5515 models which require native
>> > GPU-driven
>> > >>>> backlight control.
>> > >>>>
>> > >>>
>> > >>>> I have attached an updated version of the test module which will
>> > allow you
>> > >>>> to test if your system does have a dynamic mux. Build and load it the
>> > same
>> > >>>> way as the previous one (unload the previous one first if you haven't
>> > done
>> > >>>> so or rebooted already). This adds
>> > /sys/kernel/debug/acpi/mxds_mux_state: if
>> > >>>> you see this file, read out its contents. I expect that on your
>> > system it
>> > >>>> should report "integrated", since IIUC the amdgpu_bl backlight device
>> > is the
>> > >>>> one that works on your system. If you do not see this file, and the
>> > message
>> > >>>> "MXDS not found" appears in your kernel log, then your ACPI table
>> > doesn't
>> > >>>> expose the MXDS method, which could be a useful disambiguation test.
>> > >>>>
>> > >>>
>> > >>>> Another experiment to try would be to flip the state of the mux.
>> > Before
>> > >>>> attempting this experiment, make sure to save any work and log in
>> > remotely
>> > >>>> from another machine, since it is possible that your screen will go
>> > blank
>> > >>>> and will need a reboot in order to come back up. To change the mux
>> > state,
>> > >>>> write the target mux state to the mxds_mux_state file. Use whatever
>> > the
>> > >>>> opposite of the current value is, i.e., if it reads out as
>> > "integrated",
>> > >>>> then write "discrete", and vice versa. If the mux switch worked, your
>> > >>>> screen should go blank and reading the mxds_mux_state file again
>> > should
>> > >>>> reflect the new state. You can then flip the mux back to its original
>> > >>>> position, and you should be able to get the display back by forcing
>> > >>>> DPMS off and then on again. If you're not running X, writing a '0'
>> > then
>> > >>>> writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems
>> > to
>> > >>>> work on my AMD+NVIDIA system. (The DRI device and eDP connector ID
>> > might
>> > >>>> be enumerated differently on your system.) If neither of those work to
>> > >>>> bring your display back up, then reboot the computer.
>> > >>>>
>> > >>>
>> > >>>> The most interesting data would be to check whether MXDS is available
>> > in
>> > >>>> your system's ACPI tables, and if so, whether it is actually
>> > functional.
>> > >>>>
>> > >>>
>> > >>>>> As mentioned before, this RTX 3050 system does not have configurable
>> > GPU mode.
>> > >>>>>
>> > >>>
>> > >>>>> ------- Original Message -------
>> > >>>>> On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap
>> > ddadap@nvidia.com wrote:
>> > >>>>>
>> > >>>
>> > >>>>>> On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>> Hello Daniel,
>> > >>>>>
>> > >>>
>> > >>>>>>> I tried building the module using the instructions you provided,
>> > but
>> > >>>>>>> ran into some problems as I didn't have the /lib/modules/$(uname
>> > >>>>>>> -r)/source directory on my end.
>> > >>>>>>> I created a Makefile in a directory containing mxdm-debugfs.c file
>> > and
>> > >>>>>>> added the following to it:
>> > >>>>>
>> > >>>
>> > >>>>>>> obj-m += mxdm-debugfs.o
>> > >>>>>
>> > >>>
>> > >>>>>>> all:
>> > >>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
>> > >>>>>
>> > >>>
>> > >>>>>>> clean:
>> > >>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
>> > >>>>>
>> > >>>
>> > >>>>>>> I then ran "make" and loaded the module.
>> > >>>>>
>> > >>>
>> > >>>>>> Ah, yes, I should have mentioned specifically that the instructions
>> > >>>>>> assumed either a split Kbuild configuration with separate source and
>> > >>>>>> output directories, or a single combined source and output
>> > directory but
>> > >>>>>> with "source" and "build" both being symlinks to the same
>> > directory. I
>> > >>>>>> forget which distros do what exactly, but some ship a combined
>> > >>>>>> source/output directory but only have one of either "source" or
>> > "build";
>> > >>>>>> yours appears to be the latter configuration. I'm glad you were
>> > able to
>> > >>>>>> get it building anyway.
>> > >>>>>
>> > >>>
>> > >>>>>>> 1) Hybrid mode set to "Enabled" from the bios settings,
>> > >>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
>> > >>>>>>> 2) Hybrid mode set to "Disabled" from the bios settings,
>> > >>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
>> > >>>>>
>> > >>>
>> > >>>>>> Okay. This is consistent with my expectations. If we also find that
>> > the
>> > >>>>>> systems which require the quirk report either "discrete", "hybrid",
>> > or
>> > >>>>>> "integrated" (IIUC those systems do not have the mode configurable
>> > in the
>> > >>>>>> UEFI settings), then I think we can fix the quirk by checking the
>> > mux
>> > >>>>>> mode and only forcing to native if the system is not in hybrid mode.
>> > >>>>>
>> > >>>
>> > >>>>>> Or perhaps we should just get rid of the quirk, and unconditionally
>> > test
>> > >>>>>> the mux mode, and avoid using nvidia-wmi-ec-backlight on systems
>> > which
>> > >>>>>> are not in "dynamic" mode, regardless of whether they expose the
>> > WMI EC
>> > >>>>>> backlight interface and regardless of whether that interface reports
>> > >>>>>> that the EC backlight driver should be used. (On the systems that
>> > need
>> > >>>>>> the quirk, that interface is reporting that the backlight should be
>> > >>>>>> EC-controlled even when it shouldn't be.) I think that in theory, it
>> > >>>>>> should be possible for a system design to require EC backlight
>> > control
>> > >>>>>> even when the mux is in a non-dynamic mode, but in practice I don't
>> > know
>> > >>>>>> why anybody would do that, and am not aware of any systems which do
>> > so
>> > >>>>>> (although until the report of the broken backlight on the 3050
>> > version
>> > >>>>>> of the Dell G15 5515, I wasn't aware of any systems that reported EC
>> > >>>>>> backlight control when it was supposed to be native.)
>> > >>>>>
>> > >>>
>> > >>>>>> Hans, I think the most reasonable options are:
>> > >>>>>
>> > >>>
>> > >>>>>> 1) Remove the quirk, and check for MXDM when deciding whether a
>> > system
>> > >>>>>> should use the EC backlight driver. This has the disadvantage of
>> > adding
>> > >>>>>> a check where one isn't actually needed on some (most?) systems,
>> > and the
>> > >>>>>> advantage of most likely avoiding the need to add quirks for other
>> > >>>>>> systems where the system reports EC backlight control when native
>> > should
>> > >>>>>> be used. It also has the possibility of being wrong on a
>> > theoretically
>> > >>>>>> possible configuration, although if we ever encounter such a
>> > >>>>>> configuration we could handle it with a quirk or find some other
>> > way to
>> > >>>>>> distinguish between systems that do or do not require the EC
>> > backlight
>> > >>>>>> driver.
>> > >>>>>
>> > >>>
>> > >>>>>> 2) Keep the existing quirk, and only force to native if MXDM is
>> > missing
>> > >>>>>> or if MXDM reports that the system is in a non-dynamic mode.
>> > >>>>>
>> > >>>
>> > >>>>>> I'm inclined to go with (2), because it seems "safer", but am happy
>> > to
>> > >>>>>> implement (1) if you think that's the better option. For the MXDM
>> > check
>> > >>>>>> I think the first thing to do is to check whether the MXDM method is
>> > >>>>>> present at all: as observed on at least one system, there is no MXDM
>> > >>>>>> method when the system is in non-dynamic mode. Then if MXDM is
>> > present,
>> > >>>>>> check whether it reports that the mux is in dynamic mode. For (1),
>> > only
>> > >>>>>> query the WMI-wrapped API to determine the backlight control source
>> > if
>> > >>>>>> the mux is in dynamic mode. For (2), only force the backlight to
>> > native
>> > >>>>>> if the mux is not in dynamic mode.
>> > >>>>>
>> > >>>
>> > >>>>>> This, again, assumes that none of the systems which require the
>> > quirk
>> > >>>>>> report that the mux is in dynamic mode. If any of them do, we will
>> > need
>> > >>>>>> to find a different way to determine which systems are lying about
>> > how
>> > >>>>>> the backlight is supposed to be controlled.
>> > >>>>>
>> > >>>
>> > >>>>>>> Regards,
>> > >>>>>
>> > >>>
>> > >>>>>>> Youssef
>> > >>>>>
>> > >>>
>> > >>>>>>> On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com
>> > wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>> Hans pointed out a crucial omission in the build instructions in a
>> > >>>>>>>> different thread where I also shared this test module:
>> > >>>>>
>> > >>>
>> > >>>>>>>> On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> Thanks, Hans.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Hi All,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> On 1/11/23 10:51, Hans de Goede wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> Hi,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> On 1/11/23 01:40, Daniel Dadap wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Hi,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> On 1/10/23 16:19, Youssef Aly wrote:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Hi Hans,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>> > >>>>>>>>>>>>>> the kernel commandline for the patched kernel, it doesn't
>> > work without it.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> I have 2 modes in the bios Hybrid on/off (hybrid /
>> > discrete). I tried
>> > >>>>>>>>>>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>> > >>>>>>>>>>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Hybrid:
>> > >>>>>>>>>>>>>> "acpi_backlight=native": Does not work,
>> > /sys/class/backlight contains
>> > >>>>>>>>>>>>>> amdgpu_bl1.
>> > >>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>> > >>>>>>>>>>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>>> Discrete:
>> > >>>>>>>>>>>>>> "acpi_backlight=native": Works but when brightness from
>> > 0-10 is the
>> > >>>>>>>>>>>>>> same as 0-100, for example 10 is full brightness like 100,
>> > 8 is the
>> > >>>>>>>>>>>>>> same as 80, etc... ,
>> > >>>>>>>>>>>>>> /sys/class/backlight contains nvidia_0.
>> > >>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work,
>> > /sys/class/backlight
>> > >>>>>>>>>>>>>> contains nvidia_wmi_ec_backlight.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Thank you for testing!
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Ok so it seems there are 2 issues at play here:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> 1. Depending on the BIOS setting we need to use either
>> > native (discrete mode)
>> > >>>>>>>>>>>>> or nvidia_wmi_ec (hybrid mode)
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> 2. There is a bug in the nvidia binary drivers backlight
>> > control in native
>> > >>>>>>>>>>>>> mode on this system causing the range to be wrong
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>>> Daniel, we really need help from NVidia with fixing 1. can
>> > you see if
>> > >>>>>>>>>>>>> there is a way to check the BIOS setting/mode from inside
>> > the kernel ?
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>> Yes, the ACPI MXDM method should be able to do this. However,
>> > querying
>> > >>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical
>> > way to
>> > >>>>>>>>>>>> determine whether the backlight is supposed to be EC-driven,
>> > since there
>> > >>>>>>>>>>>> are EC-driven and non-EC-driven designs, so the BIOS mode is
>> > supposed to
>> > >>>>>>>>>>>> be orthogonal to whether or not the EC driver should be used.
>> > It sounds
>> > >>>>>>>>>>>> like the BIOS is possibly reporting a wrong value for that
>> > query.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>>> I guess we could wire up a quirk that checks MXDM and
>> > overrides the
>> > >>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from
>> > the current
>> > >>>>>>>>>>>> mux operation mode. Then that quirk could be applied to this
>> > system.
>> > >>>>>>>>>>>> I can put together a patch for that.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> If you can write a patch for this that would be great, thank
>> > you,
>> > >>>>>>>>>>> but I think we first need to root-cause this better:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> Currently the Dell G15 5515 is DMI quirked inside:
>> > drivers/apci/video_detect.c
>> > >>>>>>>>>>> to always use the native backlight. So I've gone back to the
>> > original email
>> > >>>>>>>>>>> thread which lead to me adding that quirk.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> We (I forwarded a mail from you to the reporter this was not
>> > on the list)
>> > >>>>>>>>>>> did ask to test with different BIOS settings their to and the
>> > reporter's
>> > >>>>>>>>>>> reply was:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> "Daniel wanted me to check different GPU modes, but my BIOS
>> > has no options
>> > >>>>>>>>>>> for GPU. It's always in hybrid mode with PRIME render offload."
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> And perhaps even more interesting in their case with
>> > acpi_backlight=native
>> > >>>>>>>>>>> to disable nvidia-wmi-ec they have a working amdgpu_bl#
>> > device. Where as
>> > >>>>>>>>>>> in Youssef's case when running in discrete mode there is an
>> > nvidia backlight
>> > >>>>>>>>>>> device and in Youssef's case the amdgpu_bl# device never works.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H
>> > CPU (with iGPU)
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> While the dGPU can be one of:
>> > >>>>>>>>>>> NVIDIA GeForce RTX 3060
>> > >>>>>>>>>>> NVIDIA GeForce GTX 3050 Ti
>> > >>>>>>>>>>> NVIDIA GeForce GTX 3050
>> > >>>>>
>> > >>>
>> > >>>>>>>>>>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code
>> > may only
>> > >>>>>>>>>>> be relevant to the model with the 3060 and that nvidia-wmi-ec
>> > should
>> > >>>>>>>>>>> maybe not load at all on the model with the 3050 versions.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> A quick status update on this.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Iris (added to the Cc), the reporter with the Dell G15 5515
>> > which lead me
>> > >>>>>>>>>> to add the acpi_backlight=native DMI quirk for the Dell G15
>> > 5515 has
>> > >>>>>>>>>> gotten back to me with lspci output on their G15 and it indeed
>> > has
>> > >>>>>>>>>> a GTX 3050.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> So atm we have the following models which are affected one way
>> > >>>>>>>>>> or the other:
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> -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
>> > :(
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> With the models which need acpi_backlight=native being broken
>> > >>>>>>>>>> by (false positive) detection of the laptop needing
>> > nvidia-wmi-ec
>> > >>>>>>>>>> for backlight control while they actually should not be using
>> > that.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> and with the Dell G15 5515 with RTX 3060 atm being broken
>> > because
>> > >>>>>>>>>> of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> I've attached a simple kernel module which adds a debugfs file
>> > that
>> > >>>>>>>>> reports the current mux mode. As mentioned elsewhere, I suspect
>> > that the
>> > >>>>>>>>> systems which need the quirk may be in one of the non-dynamic
>> > modes, and
>> > >>>>>>>>> the systems which are broken by the quirk may be in dynamic mux
>> > mode. It
>> > >>>>>>>>> should be pretty straightforward to compile this as an
>> > out-of-tree
>> > >>>>>>>>> module using the Kbuild extmod infrastructure, as follows:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> 1) Change to the directory containing the mxdm-debugfs.c file
>> > (you may
>> > >>>>>>>>> wish to create an empty directory to put it in) and create a
>> > file in
>> > >>>>>>>>> that directory containing the following line:
>> > >>>>>
>> > >>>
>> > >>>>>>>> The name of this file should be 'Kbuild'. Sorry for the noise.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> obj-m += mxdm-debugfs.o
>> > >>>>>
>> > >>>
>> > >>>>>>>>> 2) Build the kernel module:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname
>> > -r)/build M=$(pwd)
>> > >>>>>
>> > >>>
>> > >>>>>>>>> (The "source" and "build" paths under /lib/modules/`uname -r`
>> > should
>> > >>>>>>>>> be the correct paths in almost all cases; if your system uses
>> > >>>>>>>>> different paths, substitute those. You will need the development
>> > >>>>>>>>> headers for external kernel modules, and the relevant toolchain
>> > bits,
>> > >>>>>>>>> but if you're already using the NVIDIA proprietary driver you
>> > almost
>> > >>>>>>>>> certainly already have all of that.)
>> > >>>>>
>> > >>>
>> > >>>>>>>>> 3) Load the kernel module:
>> > >>>>>
>> > >>>
>> > >>>>>>>>> insmod ./mxdm-debugfs.ko
>> > >>>>>
>> > >>>
>> > >>>>>>>>> This should create a file at
>> > /sys/kernel/debug/acpi/mxdm_mux_mode.
>> > >>>>>>>>> Reading this file should report the current mux operation mode.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> While switching mux modes on a dynamic mux system to test this
>> > kernel
>> > >>>>>>>>> module, I noticed that the ACPI tables no longer exposed the
>> > MXDM method
>> > >>>>>>>>> when the mux mode was set to discrete only on that particular
>> > system.
>> > >>>>>>>>> This contradicted the behavior I had previously observed on other
>> > >>>>>>>>> systems; i.e., that MXDM is always available regardless of the
>> > currently
>> > >>>>>>>>> set mux mode, so I tried it on another dynamic mux system and
>> > observed
>> > >>>>>>>>> that the other system does always expose MXDM regardless of the
>> > mux
>> > >>>>>>>>> mode, and the contents of the debugfs file matched the selected
>> > mode.
>> > >>>>>
>> > >>>
>> > >>>>>>>>> So if the module fails to load with ENODEV and prints the "MXDM
>> > not
>> > >>>>>>>>> found" message to the kernel log, the system is most likely
>> > configured
>> > >>>>>>>>> to a non-dynamic mux mode. My usual expectation is that it
>> > should load
>> > >>>>>>>>> and create the file on most dynamic mux systems. I do not have
>> > direct
>> > >>>>>>>>> access to any of the above listed systems at the moment, so I do
>> > not
>> > >>>>>>>>> know whether MXDM will be exposed when the system is not in
>> > dynamic mux
>> > >>>>>>>>> mode.
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Regards,
>> > >>>>>
>> > >>>
>> > >>>>>>>>>> Hans
>> > >>>>>
>> > >>>
>> > >>>>>>>>> // SPDX-License-Identifier: GPL-2.0-only
>> > >>>>>>>>> /*
>> > >>>>>>>>> * Copyright (C) 2020 NVIDIA Corporation
>> > >>>>>>>>> *
>> > >>>>>>>>> */
>> > >>>>>
>> > >>>
>> > >>>>>>>>> #include <linux/acpi.h>
>> > >>>>>>>>> #include <acpi/acoutput.h>
>> > >>>>>>>>> #include <linux/module.h>
>> > >>>>>>>>> #include <linux/pci.h>
>> > >>>>>>>>> #include <linux/debugfs.h>
>> > >>>>>
>> > >>>
>> > >>>>>>>>> extern struct dentry *acpi_debugfs_dir;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> enum mux_mode {
>> > >>>>>>>>> MUX_MODE_UNKNOWN = 0,
>> > >>>>>>>>> MUX_MODE_INTEGRATED = 1, /* iGPU only /
>> > >>>>>>>>> MUX_MODE_DISCRETE = 2, / dGPU only /
>> > >>>>>>>>> MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
>> > >>>>>>>>> MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
>> > >>>>>>>>> MUX_MODE_MAX
>> > >>>>>>>>> };
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static char * mode_names[] = {
>> > >>>>>>>>> [MUX_MODE_UNKNOWN] = "unknown\n",
>> > >>>>>>>>> [MUX_MODE_INTEGRATED] = "integrated\n",
>> > >>>>>>>>> [MUX_MODE_DISCRETE] = "discrete\n",
>> > >>>>>>>>> [MUX_MODE_HYBRID] = "hybrid\n",
>> > >>>>>>>>> [MUX_MODE_DYNAMIC] = "dynamic\n",
>> > >>>>>>>>> };
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static struct debugfs_blob_wrapper muxmode_blob;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static void store_mux_mode(acpi_handle handle)
>> > >>>>>>>>> {
>> > >>>>>>>>> union acpi_object arg = { .integer = { .type =
>> > ACPI_TYPE_INTEGER, .value = 0 } };
>> > >>>>>>>>> struct acpi_object_list in = { .count = 1, .pointer = &arg };
>> > >>>>>
>> > >>>
>> > >>>>>>>>> acpi_integer ret;
>> > >>>>>>>>> acpi_status status;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> if (ACPI_FAILURE(status)) {
>> > >>>>>>>>> acpi_handle_err(handle, "ACPI MXDM failed: %s\n",
>> > acpi_format_exception(status));
>> > >>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>> > >>>>>>>>> } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
>> > >>>>>>>>> acpi_handle_err(handle, "Mux mode value out of range");
>> > >>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>> > >>>>>>>>> } else {
>> > >>>>>>>>> muxmode_blob.data = mode_names[ret];
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> muxmode_blob.size = strlen(muxmode_blob.data);
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static acpi_status find_mxdm(acpi_handle obj, u32 level, void
>> > *ctx, void **ret)
>> > >>>>>>>>> {
>> > >>>>>>>>> acpi_handle search;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> if (acpi_get_handle(obj, "MXDM", &search) == 0) {
>> > >>>>>>>>> /* Found the parent object of the MXDM method; pass it back
>> > >>>>>>>>> * to the caller and stop searching. */
>> > >>>>>>>>> *ret = obj;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> return AE_CTRL_TERMINATE;
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> /* No MXDM; keep looking */
>> > >>>>>>>>> return AE_OK;
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static struct dentry *muxmode_file_dentry;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static int __init mxdm_debugfs_init(void)
>> > >>>>>>>>> {
>> > >>>>>>>>> acpi_handle mxdm_handle = NULL;
>> > >>>>>>>>> acpi_status ret;
>> > >>>>>
>> > >>>
>> > >>>>>>>>> ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
>> > >>>>>>>>> find_mxdm, NULL, NULL, &mxdm_handle);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> if (ACPI_FAILURE(ret) || !mxdm_handle) {
>> > >>>>>>>>> pr_err("MXDM not found.\n");
>> > >>>>>>>>> return -ENODEV;
>> > >>>>>>>>> }
>> > >>>>>
>> > >>>
>> > >>>>>>>>> /* Populate the blob wrapper: the mux mode cannot change without
>> > rebooting
>> > >>>>>>>>> * so this only needs to be done once. */
>> > >>>>>>>>> store_mux_mode(mxdm_handle);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
>> > >>>>>>>>> acpi_debugfs_dir,
>> > >>>>>>>>> &muxmode_blob);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> return muxmode_file_dentry ? 0 : -EIO;
>> > >>>>>>>>> }
>> > >>>>>>>>> module_init(mxdm_debugfs_init);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> static void __exit mxdm_debugfs_exit(void)
>> > >>>>>>>>> {
>> > >>>>>>>>> if (muxmode_file_dentry) {
>> > >>>>>>>>> debugfs_remove(muxmode_file_dentry);
>> > >>>>>>>>> muxmode_file_dentry = NULL;
>> > >>>>>>>>> }
>> > >>>>>>>>> }
>> > >>>>>>>>> module_exit(mxdm_debugfs_exit);
>> > >>>>>
>> > >>>
>> > >>>>>>>>> MODULE_LICENSE("GPL v2");
>> > >>>>>>>>> MODULE_DESCRIPTION("MXDM mux mode test module");
>> > >>>>>>>>> MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
>> > >>>>>
>> > >>>
>> > >>>>>>>>> /*
>> > >>>>>>>>> * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so
>> > key off of
>> > >>>>>>>>> * the WMI wrapper for the related WMAA method for backlight
>> > control.
>> > >>>>>>>>> */
>> > >>>>>>>>> MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
>> > >>>>
>> > >>>
>> > >>>>
>> > >>>
>> > >>>>
>> > >
>> > >
>> >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Linux regression tracking (Thorsten Leemhuis)]

On 17.02.23 21:47, Youssef Ahmed wrote:
> Hello Daniel,
> 
> I added the file to gdrive, and here is the link
> https://drive.google.com/file/d/14JUpD78jJkXwjgJz5bY3nUzp-LFlZ6dC/view?usp=drivesdk
> 
> Let me know if you have any problem accessing the file.

Daniel, did you get a chance to look at this? Would be good to get this
regression finally solved, as it was reported more than two month ago
already. Which leads to another question, while at it:

Youssef, did you try if latest mainline is still broken?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

> On February 17, 2023 8:56:13 PM GMT+02:00, Daniel Dadap <ddadap@nvidia.com> wrote:
>> On Fri, Feb 17, 2023 at 05:04:52PM +0200, Youssef Aly wrote:
>>> Yes, I sent the data to daniel. I am currently just using an older kernel
>>> (6.0) before the regression.
>>
>> Thanks, Youssef. I am also only seeing the test kernel module results as
>> the most recent message I have from you. If you sent the ACPI table dumps
>> as an attachment, there is a chance they got filtered out - this happened
>> with another ACPI dump that somebody tried to send me. Perhaps posting the
>> files to a file sharing site might work better - it would be interesting
>> to compare your ACPI table dump to another from a different 5515 model.
>>
>>> On Fri, Feb 17, 2023, 2:36 PM Linux regression tracking (Thorsten Leemhuis)
>>> <regressions@leemhuis.info> wrote:
>>>
>>>> On 18.01.23 23:11, Daniel Dadap wrote:
>>>>> On Thu, Jan 19, 2023 at 12:02:50AM +0200, Youssef Aly wrote:
>>>>>> I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
>>>>>> x_state contained "integrated".
>>>>>>
>>>>>> I ran
>>>>>> echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
>>>>>> now it contained ''discrete' and the screen turned off.
>>>>>> then I return it to its initial state.
>>>>>>
>>>>>> Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
>>>>>> but it didn't work, had to reboot, I am running gnome on wayland.
>>>>>
>>>>> Your system does allow you to switch the mux mode in the UEFI setup
>>>>> screen, correct? If you could share your ACPI tables as well (see the
>>>>> instructions in a fork of this thread) that would be helpful.
>>>>
>>>> I might be missing something, but it looks like this discussion stalled
>>>> here.
>>>>
>>>> Youssef Aly, did you ever share the data Daniel asked for? Or did you
>>>> stop caring? Maybe because it works / you found a workaround?
>>>>
>>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>> --
>>>> Everything you wanna know about Linux kernel regression tracking:
>>>> https://linux-regtracking.leemhuis.info/about/#tldr
>>>> If I did something stupid, please tell me, as explained on that page.
>>>>
>>>> #regzbot poke
>>>>
>>>>> It sounds like your system has a functional dynamic mux, which would be
>>>>> consistent with being able to choose different mux modes in UEFI setup.
>>>>> The screen not coming back up isn't a big concern: triggering the
>>>>> hotplug is something that's *supposed* to work (and it worked on the
>>>>> AMD+NVIDIA system I tried it on), but I am not surprised if it doesn't
>>>>> work everywhere.
>>>>>
>>>>>>
>>>>>> On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
>>>>>>>
>>>>>>> After loading the updated module,
>>>> /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
>>>>>>>
>>>>>>> Now, i ran the command
>>>>>>> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
>>>>>>>
>>>>>>> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my
>>>> screen didn't turn off... I changed it back to integrated, then to discrete
>>>> again, it seems like nothing happened, or did i do something wrong?
>>>>>>>
>>>>>>>
>>>>>>> ------- Original Message -------
>>>>>>> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <
>>>> ddadap@nvidia.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Thanks, Iris:
>>>>>>>>
>>>>>>>
>>>>>>>> On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
>>>>>>>>
>>>>>>>
>>>>>>>>> I have followed Youssef's instructions to build the module, and
>>>> after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> That is unfortunate. I was hoping it would report a non-dynamic mode,
>>>> which
>>>>>>>> would make it easier to disambiguate between G15 5515 models which
>>>> require
>>>>>>>> EC backlight control and G15 5515 models which require native
>>>> GPU-driven
>>>>>>>> backlight control.
>>>>>>>>
>>>>>>>
>>>>>>>> I have attached an updated version of the test module which will
>>>> allow you
>>>>>>>> to test if your system does have a dynamic mux. Build and load it the
>>>> same
>>>>>>>> way as the previous one (unload the previous one first if you haven't
>>>> done
>>>>>>>> so or rebooted already). This adds
>>>> /sys/kernel/debug/acpi/mxds_mux_state: if
>>>>>>>> you see this file, read out its contents. I expect that on your
>>>> system it
>>>>>>>> should report "integrated", since IIUC the amdgpu_bl backlight device
>>>> is the
>>>>>>>> one that works on your system. If you do not see this file, and the
>>>> message
>>>>>>>> "MXDS not found" appears in your kernel log, then your ACPI table
>>>> doesn't
>>>>>>>> expose the MXDS method, which could be a useful disambiguation test.
>>>>>>>>
>>>>>>>
>>>>>>>> Another experiment to try would be to flip the state of the mux.
>>>> Before
>>>>>>>> attempting this experiment, make sure to save any work and log in
>>>> remotely
>>>>>>>> from another machine, since it is possible that your screen will go
>>>> blank
>>>>>>>> and will need a reboot in order to come back up. To change the mux
>>>> state,
>>>>>>>> write the target mux state to the mxds_mux_state file. Use whatever
>>>> the
>>>>>>>> opposite of the current value is, i.e., if it reads out as
>>>> "integrated",
>>>>>>>> then write "discrete", and vice versa. If the mux switch worked, your
>>>>>>>> screen should go blank and reading the mxds_mux_state file again
>>>> should
>>>>>>>> reflect the new state. You can then flip the mux back to its original
>>>>>>>> position, and you should be able to get the display back by forcing
>>>>>>>> DPMS off and then on again. If you're not running X, writing a '0'
>>>> then
>>>>>>>> writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems
>>>> to
>>>>>>>> work on my AMD+NVIDIA system. (The DRI device and eDP connector ID
>>>> might
>>>>>>>> be enumerated differently on your system.) If neither of those work to
>>>>>>>> bring your display back up, then reboot the computer.
>>>>>>>>
>>>>>>>
>>>>>>>> The most interesting data would be to check whether MXDS is available
>>>> in
>>>>>>>> your system's ACPI tables, and if so, whether it is actually
>>>> functional.
>>>>>>>>
>>>>>>>
>>>>>>>>> As mentioned before, this RTX 3050 system does not have configurable
>>>> GPU mode.
>>>>>>>>>
>>>>>>>
>>>>>>>>> ------- Original Message -------
>>>>>>>>> On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap
>>>> ddadap@nvidia.com wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>> On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> Hello Daniel,
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> I tried building the module using the instructions you provided,
>>>> but
>>>>>>>>>>> ran into some problems as I didn't have the /lib/modules/$(uname
>>>>>>>>>>> -r)/source directory on my end.
>>>>>>>>>>> I created a Makefile in a directory containing mxdm-debugfs.c file
>>>> and
>>>>>>>>>>> added the following to it:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> obj-m += mxdm-debugfs.o
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> all:
>>>>>>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> clean:
>>>>>>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> I then ran "make" and loaded the module.
>>>>>>>>>
>>>>>>>
>>>>>>>>>> Ah, yes, I should have mentioned specifically that the instructions
>>>>>>>>>> assumed either a split Kbuild configuration with separate source and
>>>>>>>>>> output directories, or a single combined source and output
>>>> directory but
>>>>>>>>>> with "source" and "build" both being symlinks to the same
>>>> directory. I
>>>>>>>>>> forget which distros do what exactly, but some ship a combined
>>>>>>>>>> source/output directory but only have one of either "source" or
>>>> "build";
>>>>>>>>>> yours appears to be the latter configuration. I'm glad you were
>>>> able to
>>>>>>>>>> get it building anyway.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> 1) Hybrid mode set to "Enabled" from the bios settings,
>>>>>>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
>>>>>>>>>>> 2) Hybrid mode set to "Disabled" from the bios settings,
>>>>>>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
>>>>>>>>>
>>>>>>>
>>>>>>>>>> Okay. This is consistent with my expectations. If we also find that
>>>> the
>>>>>>>>>> systems which require the quirk report either "discrete", "hybrid",
>>>> or
>>>>>>>>>> "integrated" (IIUC those systems do not have the mode configurable
>>>> in the
>>>>>>>>>> UEFI settings), then I think we can fix the quirk by checking the
>>>> mux
>>>>>>>>>> mode and only forcing to native if the system is not in hybrid mode.
>>>>>>>>>
>>>>>>>
>>>>>>>>>> Or perhaps we should just get rid of the quirk, and unconditionally
>>>> test
>>>>>>>>>> the mux mode, and avoid using nvidia-wmi-ec-backlight on systems
>>>> which
>>>>>>>>>> are not in "dynamic" mode, regardless of whether they expose the
>>>> WMI EC
>>>>>>>>>> backlight interface and regardless of whether that interface reports
>>>>>>>>>> that the EC backlight driver should be used. (On the systems that
>>>> need
>>>>>>>>>> the quirk, that interface is reporting that the backlight should be
>>>>>>>>>> EC-controlled even when it shouldn't be.) I think that in theory, it
>>>>>>>>>> should be possible for a system design to require EC backlight
>>>> control
>>>>>>>>>> even when the mux is in a non-dynamic mode, but in practice I don't
>>>> know
>>>>>>>>>> why anybody would do that, and am not aware of any systems which do
>>>> so
>>>>>>>>>> (although until the report of the broken backlight on the 3050
>>>> version
>>>>>>>>>> of the Dell G15 5515, I wasn't aware of any systems that reported EC
>>>>>>>>>> backlight control when it was supposed to be native.)
>>>>>>>>>
>>>>>>>
>>>>>>>>>> Hans, I think the most reasonable options are:
>>>>>>>>>
>>>>>>>
>>>>>>>>>> 1) Remove the quirk, and check for MXDM when deciding whether a
>>>> system
>>>>>>>>>> should use the EC backlight driver. This has the disadvantage of
>>>> adding
>>>>>>>>>> a check where one isn't actually needed on some (most?) systems,
>>>> and the
>>>>>>>>>> advantage of most likely avoiding the need to add quirks for other
>>>>>>>>>> systems where the system reports EC backlight control when native
>>>> should
>>>>>>>>>> be used. It also has the possibility of being wrong on a
>>>> theoretically
>>>>>>>>>> possible configuration, although if we ever encounter such a
>>>>>>>>>> configuration we could handle it with a quirk or find some other
>>>> way to
>>>>>>>>>> distinguish between systems that do or do not require the EC
>>>> backlight
>>>>>>>>>> driver.
>>>>>>>>>
>>>>>>>
>>>>>>>>>> 2) Keep the existing quirk, and only force to native if MXDM is
>>>> missing
>>>>>>>>>> or if MXDM reports that the system is in a non-dynamic mode.
>>>>>>>>>
>>>>>>>
>>>>>>>>>> I'm inclined to go with (2), because it seems "safer", but am happy
>>>> to
>>>>>>>>>> implement (1) if you think that's the better option. For the MXDM
>>>> check
>>>>>>>>>> I think the first thing to do is to check whether the MXDM method is
>>>>>>>>>> present at all: as observed on at least one system, there is no MXDM
>>>>>>>>>> method when the system is in non-dynamic mode. Then if MXDM is
>>>> present,
>>>>>>>>>> check whether it reports that the mux is in dynamic mode. For (1),
>>>> only
>>>>>>>>>> query the WMI-wrapped API to determine the backlight control source
>>>> if
>>>>>>>>>> the mux is in dynamic mode. For (2), only force the backlight to
>>>> native
>>>>>>>>>> if the mux is not in dynamic mode.
>>>>>>>>>
>>>>>>>
>>>>>>>>>> This, again, assumes that none of the systems which require the
>>>> quirk
>>>>>>>>>> report that the mux is in dynamic mode. If any of them do, we will
>>>> need
>>>>>>>>>> to find a different way to determine which systems are lying about
>>>> how
>>>>>>>>>> the backlight is supposed to be controlled.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> Youssef
>>>>>>>>>
>>>>>>>
>>>>>>>>>>> On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com
>>>> wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>> Hans pointed out a crucial omission in the build instructions in a
>>>>>>>>>>>> different thread where I also shared this test module:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>> On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> Thanks, Hans.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> On 1/11/23 10:51, Hans de Goede wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> On 1/11/23 01:40, Daniel Dadap wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> On 1/10/23 16:19, Youssef Aly wrote:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Hans,
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
>>>>>>>>>>>>>>>>>> the kernel commandline for the patched kernel, it doesn't
>>>> work without it.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>> I have 2 modes in the bios Hybrid on/off (hybrid /
>>>> discrete). I tried
>>>>>>>>>>>>>>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
>>>>>>>>>>>>>>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>> Hybrid:
>>>>>>>>>>>>>>>>>> "acpi_backlight=native": Does not work,
>>>> /sys/class/backlight contains
>>>>>>>>>>>>>>>>>> amdgpu_bl1.
>>>>>>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
>>>>>>>>>>>>>>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>> Discrete:
>>>>>>>>>>>>>>>>>> "acpi_backlight=native": Works but when brightness from
>>>> 0-10 is the
>>>>>>>>>>>>>>>>>> same as 0-100, for example 10 is full brightness like 100,
>>>> 8 is the
>>>>>>>>>>>>>>>>>> same as 80, etc... ,
>>>>>>>>>>>>>>>>>> /sys/class/backlight contains nvidia_0.
>>>>>>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work,
>>>> /sys/class/backlight
>>>>>>>>>>>>>>>>>> contains nvidia_wmi_ec_backlight.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> Thank you for testing!
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> Ok so it seems there are 2 issues at play here:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> 1. Depending on the BIOS setting we need to use either
>>>> native (discrete mode)
>>>>>>>>>>>>>>>>> or nvidia_wmi_ec (hybrid mode)
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> 2. There is a bug in the nvidia binary drivers backlight
>>>> control in native
>>>>>>>>>>>>>>>>> mode on this system causing the range to be wrong
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>> Daniel, we really need help from NVidia with fixing 1. can
>>>> you see if
>>>>>>>>>>>>>>>>> there is a way to check the BIOS setting/mode from inside
>>>> the kernel ?
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>> Yes, the ACPI MXDM method should be able to do this. However,
>>>> querying
>>>>>>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical
>>>> way to
>>>>>>>>>>>>>>>> determine whether the backlight is supposed to be EC-driven,
>>>> since there
>>>>>>>>>>>>>>>> are EC-driven and non-EC-driven designs, so the BIOS mode is
>>>> supposed to
>>>>>>>>>>>>>>>> be orthogonal to whether or not the EC driver should be used.
>>>> It sounds
>>>>>>>>>>>>>>>> like the BIOS is possibly reporting a wrong value for that
>>>> query.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>>> I guess we could wire up a quirk that checks MXDM and
>>>> overrides the
>>>>>>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from
>>>> the current
>>>>>>>>>>>>>>>> mux operation mode. Then that quirk could be applied to this
>>>> system.
>>>>>>>>>>>>>>>> I can put together a patch for that.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> If you can write a patch for this that would be great, thank
>>>> you,
>>>>>>>>>>>>>>> but I think we first need to root-cause this better:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> Currently the Dell G15 5515 is DMI quirked inside:
>>>> drivers/apci/video_detect.c
>>>>>>>>>>>>>>> to always use the native backlight. So I've gone back to the
>>>> original email
>>>>>>>>>>>>>>> thread which lead to me adding that quirk.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> We (I forwarded a mail from you to the reporter this was not
>>>> on the list)
>>>>>>>>>>>>>>> did ask to test with different BIOS settings their to and the
>>>> reporter's
>>>>>>>>>>>>>>> reply was:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> "Daniel wanted me to check different GPU modes, but my BIOS
>>>> has no options
>>>>>>>>>>>>>>> for GPU. It's always in hybrid mode with PRIME render offload."
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> And perhaps even more interesting in their case with
>>>> acpi_backlight=native
>>>>>>>>>>>>>>> to disable nvidia-wmi-ec they have a working amdgpu_bl#
>>>> device. Where as
>>>>>>>>>>>>>>> in Youssef's case when running in discrete mode there is an
>>>> nvidia backlight
>>>>>>>>>>>>>>> device and in Youssef's case the amdgpu_bl# device never works.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H
>>>> CPU (with iGPU)
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> While the dGPU can be one of:
>>>>>>>>>>>>>>> NVIDIA GeForce RTX 3060
>>>>>>>>>>>>>>> NVIDIA GeForce GTX 3050 Ti
>>>>>>>>>>>>>>> NVIDIA GeForce GTX 3050
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code
>>>> may only
>>>>>>>>>>>>>>> be relevant to the model with the 3060 and that nvidia-wmi-ec
>>>> should
>>>>>>>>>>>>>>> maybe not load at all on the model with the 3050 versions.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> A quick status update on this.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> Iris (added to the Cc), the reporter with the Dell G15 5515
>>>> which lead me
>>>>>>>>>>>>>> to add the acpi_backlight=native DMI quirk for the Dell G15
>>>> 5515 has
>>>>>>>>>>>>>> gotten back to me with lspci output on their G15 and it indeed
>>>> has
>>>>>>>>>>>>>> a GTX 3050.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> So atm we have the following models which are affected one way
>>>>>>>>>>>>>> or the other:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> -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
>>>> :(
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> With the models which need acpi_backlight=native being broken
>>>>>>>>>>>>>> by (false positive) detection of the laptop needing
>>>> nvidia-wmi-ec
>>>>>>>>>>>>>> for backlight control while they actually should not be using
>>>> that.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> and with the Dell G15 5515 with RTX 3060 atm being broken
>>>> because
>>>>>>>>>>>>>> of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> I've attached a simple kernel module which adds a debugfs file
>>>> that
>>>>>>>>>>>>> reports the current mux mode. As mentioned elsewhere, I suspect
>>>> that the
>>>>>>>>>>>>> systems which need the quirk may be in one of the non-dynamic
>>>> modes, and
>>>>>>>>>>>>> the systems which are broken by the quirk may be in dynamic mux
>>>> mode. It
>>>>>>>>>>>>> should be pretty straightforward to compile this as an
>>>> out-of-tree
>>>>>>>>>>>>> module using the Kbuild extmod infrastructure, as follows:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> 1) Change to the directory containing the mxdm-debugfs.c file
>>>> (you may
>>>>>>>>>>>>> wish to create an empty directory to put it in) and create a
>>>> file in
>>>>>>>>>>>>> that directory containing the following line:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>> The name of this file should be 'Kbuild'. Sorry for the noise.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> obj-m += mxdm-debugfs.o
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> 2) Build the kernel module:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname
>>>> -r)/build M=$(pwd)
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> (The "source" and "build" paths under /lib/modules/`uname -r`
>>>> should
>>>>>>>>>>>>> be the correct paths in almost all cases; if your system uses
>>>>>>>>>>>>> different paths, substitute those. You will need the development
>>>>>>>>>>>>> headers for external kernel modules, and the relevant toolchain
>>>> bits,
>>>>>>>>>>>>> but if you're already using the NVIDIA proprietary driver you
>>>> almost
>>>>>>>>>>>>> certainly already have all of that.)
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> 3) Load the kernel module:
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> insmod ./mxdm-debugfs.ko
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> This should create a file at
>>>> /sys/kernel/debug/acpi/mxdm_mux_mode.
>>>>>>>>>>>>> Reading this file should report the current mux operation mode.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> While switching mux modes on a dynamic mux system to test this
>>>> kernel
>>>>>>>>>>>>> module, I noticed that the ACPI tables no longer exposed the
>>>> MXDM method
>>>>>>>>>>>>> when the mux mode was set to discrete only on that particular
>>>> system.
>>>>>>>>>>>>> This contradicted the behavior I had previously observed on other
>>>>>>>>>>>>> systems; i.e., that MXDM is always available regardless of the
>>>> currently
>>>>>>>>>>>>> set mux mode, so I tried it on another dynamic mux system and
>>>> observed
>>>>>>>>>>>>> that the other system does always expose MXDM regardless of the
>>>> mux
>>>>>>>>>>>>> mode, and the contents of the debugfs file matched the selected
>>>> mode.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> So if the module fails to load with ENODEV and prints the "MXDM
>>>> not
>>>>>>>>>>>>> found" message to the kernel log, the system is most likely
>>>> configured
>>>>>>>>>>>>> to a non-dynamic mux mode. My usual expectation is that it
>>>> should load
>>>>>>>>>>>>> and create the file on most dynamic mux systems. I do not have
>>>> direct
>>>>>>>>>>>>> access to any of the above listed systems at the moment, so I do
>>>> not
>>>>>>>>>>>>> know whether MXDM will be exposed when the system is not in
>>>> dynamic mux
>>>>>>>>>>>>> mode.
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> // SPDX-License-Identifier: GPL-2.0-only
>>>>>>>>>>>>> /*
>>>>>>>>>>>>> * Copyright (C) 2020 NVIDIA Corporation
>>>>>>>>>>>>> *
>>>>>>>>>>>>> */
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> #include <linux/acpi.h>
>>>>>>>>>>>>> #include <acpi/acoutput.h>
>>>>>>>>>>>>> #include <linux/module.h>
>>>>>>>>>>>>> #include <linux/pci.h>
>>>>>>>>>>>>> #include <linux/debugfs.h>
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> extern struct dentry *acpi_debugfs_dir;
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> enum mux_mode {
>>>>>>>>>>>>> MUX_MODE_UNKNOWN = 0,
>>>>>>>>>>>>> MUX_MODE_INTEGRATED = 1, /* iGPU only /
>>>>>>>>>>>>> MUX_MODE_DISCRETE = 2, / dGPU only /
>>>>>>>>>>>>> MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
>>>>>>>>>>>>> MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
>>>>>>>>>>>>> MUX_MODE_MAX
>>>>>>>>>>>>> };
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> static char * mode_names[] = {
>>>>>>>>>>>>> [MUX_MODE_UNKNOWN] = "unknown\n",
>>>>>>>>>>>>> [MUX_MODE_INTEGRATED] = "integrated\n",
>>>>>>>>>>>>> [MUX_MODE_DISCRETE] = "discrete\n",
>>>>>>>>>>>>> [MUX_MODE_HYBRID] = "hybrid\n",
>>>>>>>>>>>>> [MUX_MODE_DYNAMIC] = "dynamic\n",
>>>>>>>>>>>>> };
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> static struct debugfs_blob_wrapper muxmode_blob;
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> static void store_mux_mode(acpi_handle handle)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> union acpi_object arg = { .integer = { .type =
>>>> ACPI_TYPE_INTEGER, .value = 0 } };
>>>>>>>>>>>>> struct acpi_object_list in = { .count = 1, .pointer = &arg };
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> acpi_integer ret;
>>>>>>>>>>>>> acpi_status status;
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> if (ACPI_FAILURE(status)) {
>>>>>>>>>>>>> acpi_handle_err(handle, "ACPI MXDM failed: %s\n",
>>>> acpi_format_exception(status));
>>>>>>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>>>>>>>>>>>>> } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
>>>>>>>>>>>>> acpi_handle_err(handle, "Mux mode value out of range");
>>>>>>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
>>>>>>>>>>>>> } else {
>>>>>>>>>>>>> muxmode_blob.data = mode_names[ret];
>>>>>>>>>>>>> }
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> muxmode_blob.size = strlen(muxmode_blob.data);
>>>>>>>>>>>>> }
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> static acpi_status find_mxdm(acpi_handle obj, u32 level, void
>>>> *ctx, void **ret)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> acpi_handle search;
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> if (acpi_get_handle(obj, "MXDM", &search) == 0) {
>>>>>>>>>>>>> /* Found the parent object of the MXDM method; pass it back
>>>>>>>>>>>>> * to the caller and stop searching. */
>>>>>>>>>>>>> *ret = obj;
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> return AE_CTRL_TERMINATE;
>>>>>>>>>>>>> }
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> /* No MXDM; keep looking */
>>>>>>>>>>>>> return AE_OK;
>>>>>>>>>>>>> }
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> static struct dentry *muxmode_file_dentry;
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> static int __init mxdm_debugfs_init(void)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> acpi_handle mxdm_handle = NULL;
>>>>>>>>>>>>> acpi_status ret;
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
>>>>>>>>>>>>> find_mxdm, NULL, NULL, &mxdm_handle);
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> if (ACPI_FAILURE(ret) || !mxdm_handle) {
>>>>>>>>>>>>> pr_err("MXDM not found.\n");
>>>>>>>>>>>>> return -ENODEV;
>>>>>>>>>>>>> }
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> /* Populate the blob wrapper: the mux mode cannot change without
>>>> rebooting
>>>>>>>>>>>>> * so this only needs to be done once. */
>>>>>>>>>>>>> store_mux_mode(mxdm_handle);
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
>>>>>>>>>>>>> acpi_debugfs_dir,
>>>>>>>>>>>>> &muxmode_blob);
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> return muxmode_file_dentry ? 0 : -EIO;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> module_init(mxdm_debugfs_init);
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> static void __exit mxdm_debugfs_exit(void)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> if (muxmode_file_dentry) {
>>>>>>>>>>>>> debugfs_remove(muxmode_file_dentry);
>>>>>>>>>>>>> muxmode_file_dentry = NULL;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> }
>>>>>>>>>>>>> module_exit(mxdm_debugfs_exit);
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> MODULE_LICENSE("GPL v2");
>>>>>>>>>>>>> MODULE_DESCRIPTION("MXDM mux mode test module");
>>>>>>>>>>>>> MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>> * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so
>>>> key off of
>>>>>>>>>>>>> * the WMI wrapper for the related WMAA method for backlight
>>>> control.
>>>>>>>>>>>>> */
>>>>>>>>>>>>> MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
> 
> 

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Youssef Aly]

I  just tried 6.3-rc1, still the same.

On Mon, 13 Mar 2023 at 16:58, Linux regression tracking (Thorsten
Leemhuis) <regressions@leemhuis.info> wrote:
>
> On 17.02.23 21:47, Youssef Ahmed wrote:
> > Hello Daniel,
> >
> > I added the file to gdrive, and here is the link
> > https://drive.google.com/file/d/14JUpD78jJkXwjgJz5bY3nUzp-LFlZ6dC/view?usp=drivesdk
> >
> > Let me know if you have any problem accessing the file.
>
> Daniel, did you get a chance to look at this? Would be good to get this
> regression finally solved, as it was reported more than two month ago
> already. Which leads to another question, while at it:
>
> Youssef, did you try if latest mainline is still broken?
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> #regzbot poke
>
> > On February 17, 2023 8:56:13 PM GMT+02:00, Daniel Dadap <ddadap@nvidia.com> wrote:
> >> On Fri, Feb 17, 2023 at 05:04:52PM +0200, Youssef Aly wrote:
> >>> Yes, I sent the data to daniel. I am currently just using an older kernel
> >>> (6.0) before the regression.
> >>
> >> Thanks, Youssef. I am also only seeing the test kernel module results as
> >> the most recent message I have from you. If you sent the ACPI table dumps
> >> as an attachment, there is a chance they got filtered out - this happened
> >> with another ACPI dump that somebody tried to send me. Perhaps posting the
> >> files to a file sharing site might work better - it would be interesting
> >> to compare your ACPI table dump to another from a different 5515 model.
> >>
> >>> On Fri, Feb 17, 2023, 2:36 PM Linux regression tracking (Thorsten Leemhuis)
> >>> <regressions@leemhuis.info> wrote:
> >>>
> >>>> On 18.01.23 23:11, Daniel Dadap wrote:
> >>>>> On Thu, Jan 19, 2023 at 12:02:50AM +0200, Youssef Aly wrote:
> >>>>>> I loaded the updated module and /sys/kernel/debug/acpi/mxds_mu
> >>>>>> x_state contained "integrated".
> >>>>>>
> >>>>>> I ran
> >>>>>> echo "discrete" > /sys/kernel/debug/acpi/mxds_mux_state
> >>>>>> now it contained ''discrete' and the screen turned off.
> >>>>>> then I return it to its initial state.
> >>>>>>
> >>>>>> Tried echo '0' > /sys/kernel/debug/dri/1/eDP-1/trigger_hotplug then '1'
> >>>>>> but it didn't work, had to reboot, I am running gnome on wayland.
> >>>>>
> >>>>> Your system does allow you to switch the mux mode in the UEFI setup
> >>>>> screen, correct? If you could share your ACPI tables as well (see the
> >>>>> instructions in a fork of this thread) that would be helpful.
> >>>>
> >>>> I might be missing something, but it looks like this discussion stalled
> >>>> here.
> >>>>
> >>>> Youssef Aly, did you ever share the data Daniel asked for? Or did you
> >>>> stop caring? Maybe because it works / you found a workaround?
> >>>>
> >>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >>>> --
> >>>> Everything you wanna know about Linux kernel regression tracking:
> >>>> https://linux-regtracking.leemhuis.info/about/#tldr
> >>>> If I did something stupid, please tell me, as explained on that page.
> >>>>
> >>>> #regzbot poke
> >>>>
> >>>>> It sounds like your system has a functional dynamic mux, which would be
> >>>>> consistent with being able to choose different mux modes in UEFI setup.
> >>>>> The screen not coming back up isn't a big concern: triggering the
> >>>>> hotplug is something that's *supposed* to work (and it worked on the
> >>>>> AMD+NVIDIA system I tried it on), but I am not surprised if it doesn't
> >>>>> work everywhere.
> >>>>>
> >>>>>>
> >>>>>> On Wed, 18 Jan 2023 at 23:20, Iris <pawel.js@protonmail.com> wrote:
> >>>>>>>
> >>>>>>> After loading the updated module,
> >>>> /sys/kernel/debug/acpi/mxds_mux_state reports "integrated".
> >>>>>>>
> >>>>>>> Now, i ran the command
> >>>>>>> sudo sh -c "echo discrete > /sys/kernel/debug/acpi/mxds_mux_state"
> >>>>>>>
> >>>>>>> /sys/kernel/debug/acpi/mxds_mux_state now reads "discrete", but my
> >>>> screen didn't turn off... I changed it back to integrated, then to discrete
> >>>> again, it seems like nothing happened, or did i do something wrong?
> >>>>>>>
> >>>>>>>
> >>>>>>> ------- Original Message -------
> >>>>>>> On Wednesday, January 18th, 2023 at 21:41, Daniel Dadap <
> >>>> ddadap@nvidia.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Thanks, Iris:
> >>>>>>>>
> >>>>>>>
> >>>>>>>> On Wed, Jan 18, 2023 at 09:33:19AM +0000, Iris wrote:
> >>>>>>>>
> >>>>>>>
> >>>>>>>>> I have followed Youssef's instructions to build the module, and
> >>>> after loading it, /sys/kernel/debug/acpi/mxdm_mux_mode reports "dynamic"
> >>>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>> That is unfortunate. I was hoping it would report a non-dynamic mode,
> >>>> which
> >>>>>>>> would make it easier to disambiguate between G15 5515 models which
> >>>> require
> >>>>>>>> EC backlight control and G15 5515 models which require native
> >>>> GPU-driven
> >>>>>>>> backlight control.
> >>>>>>>>
> >>>>>>>
> >>>>>>>> I have attached an updated version of the test module which will
> >>>> allow you
> >>>>>>>> to test if your system does have a dynamic mux. Build and load it the
> >>>> same
> >>>>>>>> way as the previous one (unload the previous one first if you haven't
> >>>> done
> >>>>>>>> so or rebooted already). This adds
> >>>> /sys/kernel/debug/acpi/mxds_mux_state: if
> >>>>>>>> you see this file, read out its contents. I expect that on your
> >>>> system it
> >>>>>>>> should report "integrated", since IIUC the amdgpu_bl backlight device
> >>>> is the
> >>>>>>>> one that works on your system. If you do not see this file, and the
> >>>> message
> >>>>>>>> "MXDS not found" appears in your kernel log, then your ACPI table
> >>>> doesn't
> >>>>>>>> expose the MXDS method, which could be a useful disambiguation test.
> >>>>>>>>
> >>>>>>>
> >>>>>>>> Another experiment to try would be to flip the state of the mux.
> >>>> Before
> >>>>>>>> attempting this experiment, make sure to save any work and log in
> >>>> remotely
> >>>>>>>> from another machine, since it is possible that your screen will go
> >>>> blank
> >>>>>>>> and will need a reboot in order to come back up. To change the mux
> >>>> state,
> >>>>>>>> write the target mux state to the mxds_mux_state file. Use whatever
> >>>> the
> >>>>>>>> opposite of the current value is, i.e., if it reads out as
> >>>> "integrated",
> >>>>>>>> then write "discrete", and vice versa. If the mux switch worked, your
> >>>>>>>> screen should go blank and reading the mxds_mux_state file again
> >>>> should
> >>>>>>>> reflect the new state. You can then flip the mux back to its original
> >>>>>>>> position, and you should be able to get the display back by forcing
> >>>>>>>> DPMS off and then on again. If you're not running X, writing a '0'
> >>>> then
> >>>>>>>> writing a '1' to /sys/kernel/debug/dri/0/eDP-1/trigger_hotplug seems
> >>>> to
> >>>>>>>> work on my AMD+NVIDIA system. (The DRI device and eDP connector ID
> >>>> might
> >>>>>>>> be enumerated differently on your system.) If neither of those work to
> >>>>>>>> bring your display back up, then reboot the computer.
> >>>>>>>>
> >>>>>>>
> >>>>>>>> The most interesting data would be to check whether MXDS is available
> >>>> in
> >>>>>>>> your system's ACPI tables, and if so, whether it is actually
> >>>> functional.
> >>>>>>>>
> >>>>>>>
> >>>>>>>>> As mentioned before, this RTX 3050 system does not have configurable
> >>>> GPU mode.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>> ------- Original Message -------
> >>>>>>>>> On Wednesday, January 18th, 2023 at 01:20, Daniel Dadap
> >>>> ddadap@nvidia.com wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> On Wed, Jan 18, 2023 at 01:13:54AM +0200, Youssef Aly wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> Hello Daniel,
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> I tried building the module using the instructions you provided,
> >>>> but
> >>>>>>>>>>> ran into some problems as I didn't have the /lib/modules/$(uname
> >>>>>>>>>>> -r)/source directory on my end.
> >>>>>>>>>>> I created a Makefile in a directory containing mxdm-debugfs.c file
> >>>> and
> >>>>>>>>>>> added the following to it:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> obj-m += mxdm-debugfs.o
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> all:
> >>>>>>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> clean:
> >>>>>>>>>>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> I then ran "make" and loaded the module.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> Ah, yes, I should have mentioned specifically that the instructions
> >>>>>>>>>> assumed either a split Kbuild configuration with separate source and
> >>>>>>>>>> output directories, or a single combined source and output
> >>>> directory but
> >>>>>>>>>> with "source" and "build" both being symlinks to the same
> >>>> directory. I
> >>>>>>>>>> forget which distros do what exactly, but some ship a combined
> >>>>>>>>>> source/output directory but only have one of either "source" or
> >>>> "build";
> >>>>>>>>>> yours appears to be the latter configuration. I'm glad you were
> >>>> able to
> >>>>>>>>>> get it building anyway.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> 1) Hybrid mode set to "Enabled" from the bios settings,
> >>>>>>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained dynamic.
> >>>>>>>>>>> 2) Hybrid mode set to "Disabled" from the bios settings,
> >>>>>>>>>>> /sys/kernel/debug/acpi/mxdm_mux_mode contained discrete.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> Okay. This is consistent with my expectations. If we also find that
> >>>> the
> >>>>>>>>>> systems which require the quirk report either "discrete", "hybrid",
> >>>> or
> >>>>>>>>>> "integrated" (IIUC those systems do not have the mode configurable
> >>>> in the
> >>>>>>>>>> UEFI settings), then I think we can fix the quirk by checking the
> >>>> mux
> >>>>>>>>>> mode and only forcing to native if the system is not in hybrid mode.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> Or perhaps we should just get rid of the quirk, and unconditionally
> >>>> test
> >>>>>>>>>> the mux mode, and avoid using nvidia-wmi-ec-backlight on systems
> >>>> which
> >>>>>>>>>> are not in "dynamic" mode, regardless of whether they expose the
> >>>> WMI EC
> >>>>>>>>>> backlight interface and regardless of whether that interface reports
> >>>>>>>>>> that the EC backlight driver should be used. (On the systems that
> >>>> need
> >>>>>>>>>> the quirk, that interface is reporting that the backlight should be
> >>>>>>>>>> EC-controlled even when it shouldn't be.) I think that in theory, it
> >>>>>>>>>> should be possible for a system design to require EC backlight
> >>>> control
> >>>>>>>>>> even when the mux is in a non-dynamic mode, but in practice I don't
> >>>> know
> >>>>>>>>>> why anybody would do that, and am not aware of any systems which do
> >>>> so
> >>>>>>>>>> (although until the report of the broken backlight on the 3050
> >>>> version
> >>>>>>>>>> of the Dell G15 5515, I wasn't aware of any systems that reported EC
> >>>>>>>>>> backlight control when it was supposed to be native.)
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> Hans, I think the most reasonable options are:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> 1) Remove the quirk, and check for MXDM when deciding whether a
> >>>> system
> >>>>>>>>>> should use the EC backlight driver. This has the disadvantage of
> >>>> adding
> >>>>>>>>>> a check where one isn't actually needed on some (most?) systems,
> >>>> and the
> >>>>>>>>>> advantage of most likely avoiding the need to add quirks for other
> >>>>>>>>>> systems where the system reports EC backlight control when native
> >>>> should
> >>>>>>>>>> be used. It also has the possibility of being wrong on a
> >>>> theoretically
> >>>>>>>>>> possible configuration, although if we ever encounter such a
> >>>>>>>>>> configuration we could handle it with a quirk or find some other
> >>>> way to
> >>>>>>>>>> distinguish between systems that do or do not require the EC
> >>>> backlight
> >>>>>>>>>> driver.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> 2) Keep the existing quirk, and only force to native if MXDM is
> >>>> missing
> >>>>>>>>>> or if MXDM reports that the system is in a non-dynamic mode.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> I'm inclined to go with (2), because it seems "safer", but am happy
> >>>> to
> >>>>>>>>>> implement (1) if you think that's the better option. For the MXDM
> >>>> check
> >>>>>>>>>> I think the first thing to do is to check whether the MXDM method is
> >>>>>>>>>> present at all: as observed on at least one system, there is no MXDM
> >>>>>>>>>> method when the system is in non-dynamic mode. Then if MXDM is
> >>>> present,
> >>>>>>>>>> check whether it reports that the mux is in dynamic mode. For (1),
> >>>> only
> >>>>>>>>>> query the WMI-wrapped API to determine the backlight control source
> >>>> if
> >>>>>>>>>> the mux is in dynamic mode. For (2), only force the backlight to
> >>>> native
> >>>>>>>>>> if the mux is not in dynamic mode.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>> This, again, assumes that none of the systems which require the
> >>>> quirk
> >>>>>>>>>> report that the mux is in dynamic mode. If any of them do, we will
> >>>> need
> >>>>>>>>>> to find a different way to determine which systems are lying about
> >>>> how
> >>>>>>>>>> the backlight is supposed to be controlled.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> Youssef
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>> On Tue, 17 Jan 2023 at 23:24, Daniel Dadap ddadap@nvidia.com
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>> Hans pointed out a crucial omission in the build instructions in a
> >>>>>>>>>>>> different thread where I also shared this test module:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>> On Tue, Jan 17, 2023 at 02:56:46PM -0600, Daniel Dadap wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> Thanks, Hans.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> On Mon, Jan 16, 2023 at 05:46:46PM +0100, Hans de Goede wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> Hi All,
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> On 1/11/23 10:51, Hans de Goede wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> On 1/11/23 01:40, Daniel Dadap wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Jan 10, 2023 at 04:27:56PM +0100, Hans de Goede wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>> On 1/10/23 16:19, Youssef Aly wrote:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>>> Hi Hans,
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>>> Yes, I added "acpi_backlight=nvidia_wmi_ec" to
> >>>>>>>>>>>>>>>>>> the kernel commandline for the patched kernel, it doesn't
> >>>> work without it.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>>> I have 2 modes in the bios Hybrid on/off (hybrid /
> >>>> discrete). I tried
> >>>>>>>>>>>>>>>>>> the modes with "acpi_backlight=nvidia_wmi_ec" and
> >>>>>>>>>>>>>>>>>> "acpi_backlight=native" using the patched kernel (v6.1.4):
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>>> Hybrid:
> >>>>>>>>>>>>>>>>>> "acpi_backlight=native": Does not work,
> >>>> /sys/class/backlight contains
> >>>>>>>>>>>>>>>>>> amdgpu_bl1.
> >>>>>>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Works as expected,
> >>>>>>>>>>>>>>>>>> /sys/class/backlight contains nvidia_wmi_ec_backlight.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>>> Discrete:
> >>>>>>>>>>>>>>>>>> "acpi_backlight=native": Works but when brightness from
> >>>> 0-10 is the
> >>>>>>>>>>>>>>>>>> same as 0-100, for example 10 is full brightness like 100,
> >>>> 8 is the
> >>>>>>>>>>>>>>>>>> same as 80, etc... ,
> >>>>>>>>>>>>>>>>>> /sys/class/backlight contains nvidia_0.
> >>>>>>>>>>>>>>>>>> "acpi_backlight=nvidia_wmi_ec": Does not work,
> >>>> /sys/class/backlight
> >>>>>>>>>>>>>>>>>> contains nvidia_wmi_ec_backlight.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>> Thank you for testing!
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>> Ok so it seems there are 2 issues at play here:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>> 1. Depending on the BIOS setting we need to use either
> >>>> native (discrete mode)
> >>>>>>>>>>>>>>>>> or nvidia_wmi_ec (hybrid mode)
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>> 2. There is a bug in the nvidia binary drivers backlight
> >>>> control in native
> >>>>>>>>>>>>>>>>> mode on this system causing the range to be wrong
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>>> Daniel, we really need help from NVidia with fixing 1. can
> >>>> you see if
> >>>>>>>>>>>>>>>>> there is a way to check the BIOS setting/mode from inside
> >>>> the kernel ?
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>> Yes, the ACPI MXDM method should be able to do this. However,
> >>>> querying
> >>>>>>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE is supposed to be the canonical
> >>>> way to
> >>>>>>>>>>>>>>>> determine whether the backlight is supposed to be EC-driven,
> >>>> since there
> >>>>>>>>>>>>>>>> are EC-driven and non-EC-driven designs, so the BIOS mode is
> >>>> supposed to
> >>>>>>>>>>>>>>>> be orthogonal to whether or not the EC driver should be used.
> >>>> It sounds
> >>>>>>>>>>>>>>>> like the BIOS is possibly reporting a wrong value for that
> >>>> query.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>>> I guess we could wire up a quirk that checks MXDM and
> >>>> overrides the
> >>>>>>>>>>>>>>>> WMI_BRIGHTNESS_METHOD_SOURCE query with a value derived from
> >>>> the current
> >>>>>>>>>>>>>>>> mux operation mode. Then that quirk could be applied to this
> >>>> system.
> >>>>>>>>>>>>>>>> I can put together a patch for that.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> If you can write a patch for this that would be great, thank
> >>>> you,
> >>>>>>>>>>>>>>> but I think we first need to root-cause this better:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> Currently the Dell G15 5515 is DMI quirked inside:
> >>>> drivers/apci/video_detect.c
> >>>>>>>>>>>>>>> to always use the native backlight. So I've gone back to the
> >>>> original email
> >>>>>>>>>>>>>>> thread which lead to me adding that quirk.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> We (I forwarded a mail from you to the reporter this was not
> >>>> on the list)
> >>>>>>>>>>>>>>> did ask to test with different BIOS settings their to and the
> >>>> reporter's
> >>>>>>>>>>>>>>> reply was:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> "Daniel wanted me to check different GPU modes, but my BIOS
> >>>> has no options
> >>>>>>>>>>>>>>> for GPU. It's always in hybrid mode with PRIME render offload."
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> And perhaps even more interesting in their case with
> >>>> acpi_backlight=native
> >>>>>>>>>>>>>>> to disable nvidia-wmi-ec they have a working amdgpu_bl#
> >>>> device. Where as
> >>>>>>>>>>>>>>> in Youssef's case when running in discrete mode there is an
> >>>> nvidia backlight
> >>>>>>>>>>>>>>> device and in Youssef's case the amdgpu_bl# device never works.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> The Dell G15 5515 always uses an AMD Ryzen 5 5600H or 5800H
> >>>> CPU (with iGPU)
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> While the dGPU can be one of:
> >>>>>>>>>>>>>>> NVIDIA GeForce RTX 3060
> >>>>>>>>>>>>>>> NVIDIA GeForce GTX 3050 Ti
> >>>>>>>>>>>>>>> NVIDIA GeForce GTX 3050
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>>> I'm guessing that the dynamic-mux mode / nvidia-wmi-ec code
> >>>> may only
> >>>>>>>>>>>>>>> be relevant to the model with the 3060 and that nvidia-wmi-ec
> >>>> should
> >>>>>>>>>>>>>>> maybe not load at all on the model with the 3050 versions.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> A quick status update on this.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> Iris (added to the Cc), the reporter with the Dell G15 5515
> >>>> which lead me
> >>>>>>>>>>>>>> to add the acpi_backlight=native DMI quirk for the Dell G15
> >>>> 5515 has
> >>>>>>>>>>>>>> gotten back to me with lspci output on their G15 and it indeed
> >>>> has
> >>>>>>>>>>>>>> a GTX 3050.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> So atm we have the following models which are affected one way
> >>>>>>>>>>>>>> or the other:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> -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
> >>>> :(
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> With the models which need acpi_backlight=native being broken
> >>>>>>>>>>>>>> by (false positive) detection of the laptop needing
> >>>> nvidia-wmi-ec
> >>>>>>>>>>>>>> for backlight control while they actually should not be using
> >>>> that.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> and with the Dell G15 5515 with RTX 3060 atm being broken
> >>>> because
> >>>>>>>>>>>>>> of the DMI quirk added to fix the Dell G15 5515 with RTX 3050.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> I've attached a simple kernel module which adds a debugfs file
> >>>> that
> >>>>>>>>>>>>> reports the current mux mode. As mentioned elsewhere, I suspect
> >>>> that the
> >>>>>>>>>>>>> systems which need the quirk may be in one of the non-dynamic
> >>>> modes, and
> >>>>>>>>>>>>> the systems which are broken by the quirk may be in dynamic mux
> >>>> mode. It
> >>>>>>>>>>>>> should be pretty straightforward to compile this as an
> >>>> out-of-tree
> >>>>>>>>>>>>> module using the Kbuild extmod infrastructure, as follows:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> 1) Change to the directory containing the mxdm-debugfs.c file
> >>>> (you may
> >>>>>>>>>>>>> wish to create an empty directory to put it in) and create a
> >>>> file in
> >>>>>>>>>>>>> that directory containing the following line:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>> The name of this file should be 'Kbuild'. Sorry for the noise.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> obj-m += mxdm-debugfs.o
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> 2) Build the kernel module:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> make -C /lib/modules/$(uname -r)/source O=/lib/modules/$(uname
> >>>> -r)/build M=$(pwd)
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> (The "source" and "build" paths under /lib/modules/`uname -r`
> >>>> should
> >>>>>>>>>>>>> be the correct paths in almost all cases; if your system uses
> >>>>>>>>>>>>> different paths, substitute those. You will need the development
> >>>>>>>>>>>>> headers for external kernel modules, and the relevant toolchain
> >>>> bits,
> >>>>>>>>>>>>> but if you're already using the NVIDIA proprietary driver you
> >>>> almost
> >>>>>>>>>>>>> certainly already have all of that.)
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> 3) Load the kernel module:
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> insmod ./mxdm-debugfs.ko
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> This should create a file at
> >>>> /sys/kernel/debug/acpi/mxdm_mux_mode.
> >>>>>>>>>>>>> Reading this file should report the current mux operation mode.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> While switching mux modes on a dynamic mux system to test this
> >>>> kernel
> >>>>>>>>>>>>> module, I noticed that the ACPI tables no longer exposed the
> >>>> MXDM method
> >>>>>>>>>>>>> when the mux mode was set to discrete only on that particular
> >>>> system.
> >>>>>>>>>>>>> This contradicted the behavior I had previously observed on other
> >>>>>>>>>>>>> systems; i.e., that MXDM is always available regardless of the
> >>>> currently
> >>>>>>>>>>>>> set mux mode, so I tried it on another dynamic mux system and
> >>>> observed
> >>>>>>>>>>>>> that the other system does always expose MXDM regardless of the
> >>>> mux
> >>>>>>>>>>>>> mode, and the contents of the debugfs file matched the selected
> >>>> mode.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> So if the module fails to load with ENODEV and prints the "MXDM
> >>>> not
> >>>>>>>>>>>>> found" message to the kernel log, the system is most likely
> >>>> configured
> >>>>>>>>>>>>> to a non-dynamic mux mode. My usual expectation is that it
> >>>> should load
> >>>>>>>>>>>>> and create the file on most dynamic mux systems. I do not have
> >>>> direct
> >>>>>>>>>>>>> access to any of the above listed systems at the moment, so I do
> >>>> not
> >>>>>>>>>>>>> know whether MXDM will be exposed when the system is not in
> >>>> dynamic mux
> >>>>>>>>>>>>> mode.
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>>> Hans
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> // SPDX-License-Identifier: GPL-2.0-only
> >>>>>>>>>>>>> /*
> >>>>>>>>>>>>> * Copyright (C) 2020 NVIDIA Corporation
> >>>>>>>>>>>>> *
> >>>>>>>>>>>>> */
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> #include <linux/acpi.h>
> >>>>>>>>>>>>> #include <acpi/acoutput.h>
> >>>>>>>>>>>>> #include <linux/module.h>
> >>>>>>>>>>>>> #include <linux/pci.h>
> >>>>>>>>>>>>> #include <linux/debugfs.h>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> extern struct dentry *acpi_debugfs_dir;
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> enum mux_mode {
> >>>>>>>>>>>>> MUX_MODE_UNKNOWN = 0,
> >>>>>>>>>>>>> MUX_MODE_INTEGRATED = 1, /* iGPU only /
> >>>>>>>>>>>>> MUX_MODE_DISCRETE = 2, / dGPU only /
> >>>>>>>>>>>>> MUX_MODE_HYBRID = 3, / Dual GPU, mux switched to iGPU /
> >>>>>>>>>>>>> MUX_MODE_DYNAMIC = 4, / Dual GPU, dynamic mux switching */
> >>>>>>>>>>>>> MUX_MODE_MAX
> >>>>>>>>>>>>> };
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> static char * mode_names[] = {
> >>>>>>>>>>>>> [MUX_MODE_UNKNOWN] = "unknown\n",
> >>>>>>>>>>>>> [MUX_MODE_INTEGRATED] = "integrated\n",
> >>>>>>>>>>>>> [MUX_MODE_DISCRETE] = "discrete\n",
> >>>>>>>>>>>>> [MUX_MODE_HYBRID] = "hybrid\n",
> >>>>>>>>>>>>> [MUX_MODE_DYNAMIC] = "dynamic\n",
> >>>>>>>>>>>>> };
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> static struct debugfs_blob_wrapper muxmode_blob;
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> static void store_mux_mode(acpi_handle handle)
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> union acpi_object arg = { .integer = { .type =
> >>>> ACPI_TYPE_INTEGER, .value = 0 } };
> >>>>>>>>>>>>> struct acpi_object_list in = { .count = 1, .pointer = &arg };
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> acpi_integer ret;
> >>>>>>>>>>>>> acpi_status status;
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> status = acpi_evaluate_integer(handle, "MXDM", &in, &ret);
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> if (ACPI_FAILURE(status)) {
> >>>>>>>>>>>>> acpi_handle_err(handle, "ACPI MXDM failed: %s\n",
> >>>> acpi_format_exception(status));
> >>>>>>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> >>>>>>>>>>>>> } else if (ret < MUX_MODE_UNKNOWN || ret >= MUX_MODE_MAX) {
> >>>>>>>>>>>>> acpi_handle_err(handle, "Mux mode value out of range");
> >>>>>>>>>>>>> muxmode_blob.data = mode_names[MUX_MODE_UNKNOWN];
> >>>>>>>>>>>>> } else {
> >>>>>>>>>>>>> muxmode_blob.data = mode_names[ret];
> >>>>>>>>>>>>> }
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> muxmode_blob.size = strlen(muxmode_blob.data);
> >>>>>>>>>>>>> }
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> static acpi_status find_mxdm(acpi_handle obj, u32 level, void
> >>>> *ctx, void **ret)
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> acpi_handle search;
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> if (acpi_get_handle(obj, "MXDM", &search) == 0) {
> >>>>>>>>>>>>> /* Found the parent object of the MXDM method; pass it back
> >>>>>>>>>>>>> * to the caller and stop searching. */
> >>>>>>>>>>>>> *ret = obj;
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> return AE_CTRL_TERMINATE;
> >>>>>>>>>>>>> }
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> /* No MXDM; keep looking */
> >>>>>>>>>>>>> return AE_OK;
> >>>>>>>>>>>>> }
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> static struct dentry *muxmode_file_dentry;
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> static int __init mxdm_debugfs_init(void)
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> acpi_handle mxdm_handle = NULL;
> >>>>>>>>>>>>> acpi_status ret;
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> ret = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, 5,
> >>>>>>>>>>>>> find_mxdm, NULL, NULL, &mxdm_handle);
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> if (ACPI_FAILURE(ret) || !mxdm_handle) {
> >>>>>>>>>>>>> pr_err("MXDM not found.\n");
> >>>>>>>>>>>>> return -ENODEV;
> >>>>>>>>>>>>> }
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> /* Populate the blob wrapper: the mux mode cannot change without
> >>>> rebooting
> >>>>>>>>>>>>> * so this only needs to be done once. */
> >>>>>>>>>>>>> store_mux_mode(mxdm_handle);
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> muxmode_file_dentry = debugfs_create_blob("mxdm_mux_mode", 0444,
> >>>>>>>>>>>>> acpi_debugfs_dir,
> >>>>>>>>>>>>> &muxmode_blob);
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> return muxmode_file_dentry ? 0 : -EIO;
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>> module_init(mxdm_debugfs_init);
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> static void __exit mxdm_debugfs_exit(void)
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> if (muxmode_file_dentry) {
> >>>>>>>>>>>>> debugfs_remove(muxmode_file_dentry);
> >>>>>>>>>>>>> muxmode_file_dentry = NULL;
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>> module_exit(mxdm_debugfs_exit);
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> MODULE_LICENSE("GPL v2");
> >>>>>>>>>>>>> MODULE_DESCRIPTION("MXDM mux mode test module");
> >>>>>>>>>>>>> MODULE_AUTHOR("Daniel Dadap ddadap@nvidia.com");
> >>>>>>>>>
> >>>>>>>
> >>>>>>>>>>>>> /*
> >>>>>>>>>>>>> * The mux doesn't have its own ACPI HID/CID, or WMI wrapper, so
> >>>> key off of
> >>>>>>>>>>>>> * the WMI wrapper for the related WMAA method for backlight
> >>>> control.
> >>>>>>>>>>>>> */
> >>>>>>>>>>>>> MODULE_ALIAS("wmi:603E9613-EF25-4338-A3D0-C46177516DB7");
> >>>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>
> >
> >

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Mon, Mar 13, 2023 at 05:20:32PM +0200, Youssef Aly wrote:
> I  just tried 6.3-rc1, still the same.
> 

Thanks for the update. I'm telling regzbot on this:

#regzbot introduced: v6.1..v6.3-rc1

PS: Youssef, when replying to public mailing list (like here and LKML),
don't top-post; reply inline with appropriate context instead.
I have to trim the context as a result.

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Bagas Sanjaya]

On Wed, Apr 12, 2023 at 11:39:10AM +0700, Bagas Sanjaya wrote:
> #regzbot introduced: v6.1..v6.3-rc1
> 

Oops, I forget to add additional commands:

#regzbot dup: https://lore.kernel.org/regressions/CAKsK3AkWhAx6cvt5ABRecun+24FVQa441OrYfzYQ5fJpJHCqmw@mail.gmail.com/

Sorry for inconvenience.

-- 
An old man doll... just what I always wanted! - Clara

Re: [REGRESSION] Backlight control broken on Dell G15 5515 since 6.1

[Bagas Sanjaya]

On Wed, Apr 12, 2023 at 03:01:47PM +0700, Bagas Sanjaya wrote:
> On Wed, Apr 12, 2023 at 11:39:10AM +0700, Bagas Sanjaya wrote:
> > #regzbot introduced: v6.1..v6.3-rc1
> > 
> 
> Oops, I forget to add additional commands:
> 
> #regzbot dup: https://lore.kernel.org/regressions/CAKsK3AkWhAx6cvt5ABRecun+24FVQa441OrYfzYQ5fJpJHCqmw@mail.gmail.com/
> 

Oops, I have to mark this duplicate as inconclusive:

#regzbot inconclusive: mess up as duplicate (originally menat updating introducing range)

-- 
An old man doll... just what I always wanted! - Clara