Brightness control does not work for laptop display on Dell Alienware m15 R5

This is also effecting the AMD 16ACH5 Legion lineup, all with 5000 series processors. My guess is that this is similar to #1438 (closed) just for the newer amd APU's. This has also been reported here - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1944094

@agd5f is there any hope of this being something simple or similar to the previous generations issue? Pinging you only because you were one of the people that fixed this the last time.

#1438 (closed) is not asic specific. Does this system have a MUX? Maybe the MUX has switched the backlight to the dGPU? Do you have multiple backlights in /sys/class/backlight/? If so does adjusting any of the other ones help?

Yes, if I add a kernel parameter enabling backlight control for Nvidia it adds an Nvidia backlight (I think it shows up as Nvidia0 or Nvidia1) which is how I was able to control the backlight when I set it to be dGPU only in the BIOS. It works as expected in dGPU only mode, but doesn't do anything in hybrid mode. When in hybrid mode, in xrandr the display shows up as eDP, and when in dGPU only mode it shows up as DP-1 or DP-0. I think the Nvidia card has brightness control over DP-1/DP-0, but not eDP. I don't think it's mux related as this original issue is without a mux switch, everything else is fairly close to the same, and it's having the exact same symptoms. My system has a 5800h and a 30 series card, like this original issue. I also have no idea what I'm talking about.

So there is a MUX. When you boot with the sbios set to dGPU only mode, the MUX (multiplexer - a software controlled switch which changes the routing of a single between multiple devices) switches everything (backlight, displays, etc.) to the dGPU. When you boot in hybrid mode, it's not clear what stuff gets MUXed to which GPU. Presumably the the display on the laptop gets MUXed to the APU, but the backlight is not clear. eDP vs DP-1/DP-0 are just driver labels. There is only one physical panel in the laptop. Some OEMs only use the MUX via the bios (to statically switch between dGPU and APU at boot), others expose the MUX at runtime so drivers can switch it at runtime to optimize gaming on the dGPU dynamically. All of the runtime interfaces for the MUX are vendor specific at this point. You might try using the nouveau driver for the nvidia chip. It may help shed some light on how the MUX is configured.

I'm pretty sure it is exposed somehow with my laptop, as with it having Advanced Optimus on windows, it dynamically switches the mux to the dGPU when a whitelisted application runs, all without a reboot, and I'm fairly sure it's done by the Nvidia driver. Seems like the OP does have a MUX, it just isn't exposed, that being a guess based on the fact that their laptop doesn't support advance Optimus? So just to clarify, with the dGPU only, in /sys/class/backlights the Nvidia one shows up and works correctly, the brightness can be changed. In hybrid mode, both the AMD and NVIDIA backlights show up, and neither of them work.

I tried the nouveau driver. When hybrid mode is enabled in BIOS, there is /sys/class/backlight/amdgpu_bl0/ with the same behavior as the original report.

When hybrid mode is disabled in BIOS (dGPU-only), there is nothing in /sys/class/backlight/ and brightness also can't change. This is different from the Nvidia proprietary driver which would allow brightness control in dGPU-only mode without any special tweaks. But it could be that nouveau just doesn't support the new GPUs very well?

Is there anything else I could look for?

dmesg_nouveau_hybrid.log dmesg_nouveau_dgpu.log

Some screen brightness related entries I noticed in dmesg:

[    3.328536] ACPI: \_SB_.PCI0.GPP0.PEGP.LCD0: _BCM evaluation failed
[    3.328804] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.GP17.VGA.LCD._BCM.AFN7], AE_NOT_FOUND (20210604/psargs-330)
[    3.328809] ACPI Error: Aborting method \_SB.PCI0.GP17.VGA.LCD._BCM due to previous error (AE_NOT_FOUND) (20210604/psparse-529)
[    3.328826] ACPI: \_SB_.PCI0.GP17.VGA_.LCD_: _BCM evaluation failed

These are only in dGPU-only mode. Same with Nvidia proprietary driver too although brightness actually works. Could this mean in hybrid mode the MUX would route the backlight not to AMD GPU but to some vendor-specific controller that doesn't have a driver in Linux? Then I wonder why in Windows the brightness control would require AMD GPU driver...

Some additional notes:

This issue is still here with kernel 5.14.16 (Fedora 5.14.16-301.fc35.x86_64).
I can confirm that I also have connection type eDP when it's connected to the AMD GPU but DP-0 when it's connected to Nvidia.
The Dell m15 R5 model comes with several different panel options including some with Advanced Optimus (switching without reboot). But my machine has the 165Hz 1080p panel without Advanced Optimus.
Similar reports for Dell G15 5515: https://bbs.archlinux.org/viewtopic.php?id=268392 https://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/backlight-controls-not-working-on-dell-g15-5515-ryzen-edition-4175702678/ Not surprising because the two models basically have the same internals.

There is no AMD proprietary kernel driver. The packaged drivers on amd.com include the same open source kernel driver as is upstream. The only closed source components are the optional user mode drivers for workstation (e.g., OpenGL).

Understood. That makes sense.

Does this patch fix it? https://patchwork.freedesktop.org/patch/463485/

I tested this patch (on top of 5.16 rc). It didn't fix this issue. dmesg-5.16.0+patch.log

I also have this problem with nearly identical symptoms (my backlight is named amdgpu_bl0 instead of _bl1). I have a Dell G15 5515 with AMD Ryzen 5800H CPU and Nvidia 3060 GPU, running Arch Linux with 5.15.6 kernel, which includes the OLED eDP brightness control patch. Running with the mux disabled works fine (except for draining the battery faster, of course).

So we know that this is affecting Dell and Lenovo laptops with Ryzen 5000 / NVIDIA 3000 hybrid systems with a MUX. In your searches, have any of you come across anyone with this issue on any other manufacturers devices with the same specs?

It does not affect my Lenovo laptop. I have a Legion 5 Pro 16ACH6H 82JQ (5800h/3060). Brightness control works perfectly in hybrid mode. In discrete graphics mode it started to work from 510.xx drivers. I am currently using 5.16 kernel. It used to work with 5.15 too. Do you experience #1758 ?

I'm not sure about #1758 , I think I may have the opposite problem; I only see 165hz, but that's all I see in windows too.

Sorry to ping you again @agd5f, just want to make sure you see this -- Is this the correct place for this or is there somewhere else you can think of that it might fit better? Is this likely going to be an issue with the AMDGPU driver, or something else?

I think this is the correct place for the bug. That said, I'm not really sure what the issue is without more insight into the hardware design. amdgpu supports the standard backlight configurations. So it should work assuming this platform uses a standard design. If it doesn't, we'd need to know more about how it's wired up. That fact that these systems use a MUX seems to indicate that there may be some issue with that. There may be some platform specific ACPI controls to switch the backlight MUX to the APU.

If there's a platform specific ACPI control we might be able to find it in an acpidump. Could you share it? That doesn't mean it for sure makes sense for the amdgpu driver to call it directly, but it might be the hint needed to add a new platform driver the amdgpu driver works with.

Attaching the acpidump with hybrid and nvidia-only modes selected in BIOS settings.

acpidump_hybrid.zip acpidump_nvidia_only.zip

I'm currently dealing with windows stupidity, I'll get that acpidump to you as soon as windows lets me.

I would guess the \_SB.PCI0.GPP0.PEGP.LCD0.MXDS or \_SB.PCI0.GPP0.PEGP.LCD0.MXDM methods are the most likely candidates for taking brightness as an argument. You can look at the values in _BCL for things you can put into them. You might try to interact with them with acpidbg to see if anything happens.

Or maybe AFN7, but _BCM should have been calling that already.

This may be an issue with the Nvidia proprietary driver. According to this post on their forums, Linux is able to adjust the backlight until the Nvidia driver is loaded, at which point neither works.

in that case I think we should probably close it here.

If the rest of you could confirm that the backlight works properly without the nvidia driver loaded, then we'd know that it's an issue with the nvidia driver.

Without any Nvidia driver (and nouveau as well) the backlight still doesn't work for me. There is still only amdgpu_bl1 in /sys/class/backlight/ which does not change the actual brightness.

The linked post is about a very different issue. In that one, there is a acpi_video0 interface that works and the Nvidia driver would attempt to take over and create a nvidia_0 that doesn't work. Here, the acpi_video0 (enabled via kernel command line options) also does nothing, and Nvidia driver does not create the nvidia_0 interface at all in hybrid mode.

Also in that thread most people are on Intel/Nvidia setup, except for a few reports of Dell G15 and Lenovo Legion whose descriptions are more in line with what we have here instead of the other Intel/Nvidia posts.

I finally got into an arch install, and its all of a sudden working with the NVIDIA proprietary driver, as well as nouveau. My only guess is the 5.16 kernel had something in it that did it? I'm on 5.16.0-arch1-1 which is the stable arch kernel. In /sys/class/backlight I have nvidia_wmi_ec_backlight that i have never seen before, and it is properly functioning, and controlling the backlight. amdgpu_bl0 is still there, but its nonfunctional, sitting at 255 on brightness and actual_brightness and never changing.

@vtq can you please try 5.16? As reported by @ShaunTheQuietGamer you can enable NVIDIA_WMI_EC_BACKLIGHT on the Legion, maybe it will help you too.

The new nvidia_wmi_ec_backlight module from 5.16 indeed fixes the issue for me too!

Yup, at least for the Legion laptops this is fixed as of kernel 5.16 - https://github.com/torvalds/linux/blob/master/drivers/platform/x86/Kconfig#L94-L107

Ah great to hear!

I can also confirm that I have working backlight brightness with hybrid AMD/Nvidia graphics on the 5.16 kernel with the Nvidia 495.46 driver.

closing this issue - it's fixed by nvidia_wmi_ec_backlight available in 5.16.

closed

mentioned in issue #1791 (closed)

Hello,

It appears that nvidia_wmi_ec_backlight (i.e. on kernels >= 5.16) does indeed solve the brightness control.

However, this only works after putting the system to sleep, and then resuming. On a clean boot I can only control the brightness using the amdgpu_bl1 controller, via:

echo 50 | sudo tee /sys/class/backlight/amdgpu_bl1/brightness

After resuming from sleep, nvidia_wmi_ec_backlight becomes responsible.

I have detailed my findings here. I am suspecting a race condition or timing issue.

Any help with how I can debug this? Thank you!

From the link above, you said that the amdgpu backlight interface works on boot and then after suspend the nvidia backlight control works? It sounds like there is some mux state that the kernel isn't properly handling, so it ends up in whatever state the bios (boot) or default (resume) leaves it in. I would suggest reporting this to the nvidia_wmi_ec_backlight driver maintainers. They probably have a better idea of what is going on.

the amdgpu backlight interface works on boot and then after suspend the nvidia backlight control works?

Yes, this is correct.

I sent an email to Daniel Dadap, the author of nvidia_wmi_ec_backlight.

Will update with any relevant info, fingers crossed!

I contacted Daniel Dadap, who for the past week developed a workaround which solved my issues. You can follow the discussion from the mailing list here: https://patchwork.kernel.org/project/platform-driver-x86/patch/20220316012516.2233984-1-ddadap@nvidia.com/

Hi Alexandru,

This is exactly what I was looking for. I am facing the same problem. Could you please tell me how to apply the patch?

Hello,

I am going to assume you already have the nvidia-wmi-ec-backlight module (i.e. you're using a kernel >= 5.16) and that you have read the modifications that this patch addresses (written by Daniel Dadap on the mailing list).

Essentially, there are two things you need to be aware beforehand:

the patch assumes that the iGPU backlight interface is named amdgpu_bl1 (you can verify in /sys/class/backlight)
the patch also address the "backlight level not being restored on boot / resume" quirk. Daniel introduced a handy quirk table:

+static const struct dmi_system_id quirks_table[] = {
+	QUIRK_ENTRY(
+		/* This quirk is preset as of firmware revision HACN31WW */
+		"LENOVO", "Legion S7 15ACH6",
+		QUIRK(RESTORE_LEVEL_ON_RESUME) | QUIRK(PROXY_TO_AMDGPU_BL1)
+	),
+	{ }
+};

So, for my system (Legion S7 15ACH6), this patch addresses both quirks.

Now, what you have to do is to compile a custom nvidia-wmi-ec-backlight.ko kernel module and replace the current one in your modules directory.

NOTE: Make sure to backup the original module. You can verify its path by using modinfo nvidia_wmi_ec_backlight | grep filename.

First, get the patch from here -- there's a Diff button in the upper right corner which will download the actual patch. For convenience, here's the patch attached: v2-nvidia-wmi-ec-backlight-Add-workarounds-for-confused-firmware.diff.

Next, you need the original source for the nvidia-wmi-ec-backlight to apply the patch to. You can get the source from here. Again, for convenience, the source (taken from 5.16.14 tree) is attached: nvidia-wmi-ec-backlight.c.

Next, you apply the patch as follows (which will modify the file in-place)

patch --unified nvidia-wmi-ec-backlight.c --input=v2-nvidia-wmi-ec-backlight-Add-workarounds-for-confused-firmware.diff

Then, you need to compile this module against your kernel. Start with the following Kbuild file:

obj-m += nvidia-wmi-ec-backlight.o

Then define the following Makefile:

KERNEL_UNAME=$(shell uname -r)
KERNEL_DIR=/lib/modules/$(KERNEL_UNAME)

MODULE=nvidia-wmi-ec-backlight

modules:
	$(MAKE) -C ${KERNEL_DIR}/build M=$(PWD) modules

install: modules
	xz --check=crc32 --lzma2=dict=512KiB ${MODULE}.ko
	sudo cp ${MODULE}.ko.xz ${KERNEL_DIR}/kernel/drivers/platform/x86/
	sudo depmod -a

clean:
	$(MAKE) -C ${KERNEL_DIR}/build M=$(PWD) clean

.PHONY: modules install clean

and run make install -- which will compile the kernel module to nvidia-wmi-ec-backlight.ko, compress it using xz, copy it to the appropriate location (replacing the original), then finally regenerate all module dependencies using depmod.

Let me know if you encounter any issues.

Hi @alexandru-dinu I have this same issue here. But i dont feel confortble to make this patch by myself. Do you know if there is any work to upstream this in newer kernel version? Thanks

The mailing list discussion is here: https://patchwork.kernel.org/project/platform-driver-x86/patch/20220316203325.2242536-1-ddadap@nvidia.com/

It appears that the discussions have stalled. I don't know if there are ongoing plans to merge this upstream, so applying the patch by yourself may be the fastest fix.

You can see nvidia-wmi-ec-backlight.c file in various kernel versions here -- e.g. for 5.18 kernel: https://elixir.bootlin.com/linux/v5.18/source/drivers/platform/x86/nvidia-wmi-ec-backlight.c

I can confirm the issue is FIXED with kernel 5.16.0 (liquorix) in Ubuntu 21.10 on Lenovo Legion 5 15IMH05 laptop with NVIDIA GeForce GTX 1650.

It appears that Lenovo Legion 5 15IMH05 has an Intel CPU. Does this problem occur for Intel iGPUs as well?

Hi, I have Legion 5-15ARH05 with Ryzen 5 4600H and GTX 1650. With amdgpu.backlight=0 kernel parameter everything works perfectly. Here's what happened when I've tried modprobe the module: #1791 (comment 1312639). Do I have to patch the module similiar to #1671 (comment 1320165) or is it possible to include it in quirks for next kernel release or something?

Hi, I have the same issue on DELL g15 5515 AMD Ryzen 5600h and Nvidia RTX 3050. No amdgpu.backlight=0 neither acpi_backlight fixes the problem.

I'm running fedora 36 with kernel 5.17.

You need to use the nvidia-wmi-ec-backlight driver to control the backlight.

How does I do it?

mentioned in issue #2052 (closed)

mentioned in issue #2129 (closed)

Brightness control does not work for laptop display on Dell Alienware m15 R5

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Attached files:

Designs

Child items ...

Activity

Admin message

Admin message

Brightness control does not work for laptop display on Dell Alienware m15 R5

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Attached files:

Activity