With Lenovo Legion 7 2021 is does not work even with 495.44 driver. What kernel parameters are you using?
Update> My laptop has AMD Ryzen 7 5800H CPU, RTX 3070 card, I’am running kernel 5.13.0-21 from Ubuntu repository and I have 495.44 driver.
Update 2> I’am running GPU in discrete mode. Surprisingly in hybrid mode backlight control works (probably because the integrated AMD GPU takes control then), but there are other problems, so I need to use discrete mode.
Sadly issue still persist on my Legion 5 Pro with 495.44. Had to downgrade to 460.91 again to get brightness working.
I use an HP Omen 17-an113nu with an i5-8300H and a GeForce GTX 1060 6 GB. I used to have this backlight issue but I’m happy to report that manually installing the 495.44 driver fixes it for me as well.
I’m currently running a fresh Manjaro installation.
same issues
laptop: Acer Predator Helios 500 PH517-51
Operating System: Manjaro Linux
KDE Plasma Version: 5.23.3
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.13.19-2-MANJARO (64-bit)
Graphics Platform: X11
Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2
Driver Version: 495.44
CUDA Version: 11.5
nvidia-bug-report.log.gz (412.4 KB)
same issues for me as well
laptop: Tuxedo Stellaris 15 Gen3
Operating System: Fedora 35
Gnome: 41
Kernel Version: 5.14.18-300.fc35.x86_64
Graphics Platform: X11
Processors: Intel(R) Core™ i7-11800H @ 2.30GHz
Memory: 64 GB of RAM
Graphics Processor: NVIDIA GeForce RTX 3060M
Driver Version: 495.44
nvidia-bug-report.log.gz (326.4 KB)
For me brightness buttons work with neither 460 nor 495.
Only 450 and older work.
However adjusting Brightness from Gnome and KDE settings works just fine.
Device: Clevo NV40MB with Intel i5-1135G7 and Nvidia 1650 Mobile
Tested Ubuntu 20.04 with kernel 5.11 and Manjaro with kernel 5.13
Same for me, brightness buttons work with neither 460 nor 470 nor 495.
Graphic: GA106M [GeForce RTX 3060 Mobile / Max-Q]
Operating System: Pop!_OS 21.10
Kernel: Linux 5.15.5-76051505-generic
Hardware Model: Lenovo Legion 5 Pro 16ACH6H
Can confirm the same issue here, still present. The last driver that worked for me is 460xx. Can somebody fix this shit already? This is beginning to get annoying now!
Make: Clevo/Eurocom
Model: P775TM1-G/Sky X7C
OS: Ubuntu 21.10 x86_64
Kernel: 5.13.0-22-generic
CPU: Intel i7-9700KF (8) @ 4.900GHz
GPU: NVIDIA GeForce RTX 2080 Mobile (150 Watts)
Last working driver version = 460.106.00
It’s beyond annoying. Even 495.46 still does not work.
It’s not just the brightness buttons/FN keys that don’t work. It’s everything.
Changing /sys/class/backlight/nvidia_0/brightness still does not have any effect.
Ironically, changing the brightness works BEFORE loading any nVidia module, but that’s through the more generic ACPI interface, since the only node available is /sys/class/backlight/acpi_video0 at that time. Once the nVidia driver takes over, everything stops working and the brightness is reset to 100 % without any way of changing it.
Can this please be fixed after almost a year of constant glare? It’s affecting battery time and probably also wearing out my display’s backlight more quickly than it’d need to.
So annoying indeed that it made me try to debug this issue.
And it gets more annoying.
Since I know (or, well, experimentally found out) that the backlight brightness can be changed by the Linux kernel via ACPI before loading the nVidia driver, I figured that I could disable the backlight handling in the nVidia driver in order to let the kernel handle this component.
To this effect, I found the documented kernel option NVreg_EnableBacklightHandler, but this one has been removed without notice or updating the documentation in the 465 version branch, like other users reported.
I reimplemented the kernel module option as a kernel module option local to nvidia-modeset instead, which merely stubs out nvkms_register_backlight() and nvkms_unregister_backlight(). This… worked, to some degree. Enabling it at least kept the acpi_video0 node instead of creating a nvidia_0 node, but upon loading the nVidia driver, the brightness is still reset to 100 % (even though I previously set it to, e.g., a value of 20).
So the workaround I had in mind (to let the kernel handle the backlight and the driver to not interfere) won’t work either.
The only workaround would be to not use the nVidia driver, but that’s probably even more annoying.
Why was the option suddenly removed without notice? Especially if it could have been a way to make the driver move out of the way in case it’s actually harmful, as it has been for 8 months now?
Hi folks,
I am facing the same issue with my Dell G15 5515 (Ryzen 7 5800h + RTX 3060), namely, brightness and keyboard leds control doesn’t work at all.
How about this?:
https://forums.developer.nvidia.com/t/ga106m-geforce-rtx-3060-mobile-misbehaves-on-kubuntu-with-nvidia-driver-version-470-57-01/195746/11?u=generix
thanks for your reply, but if you have been looking around on the internet you should be aware that what you propose is not working for the majority of us.
At least for my laptop “Lenovo P17 Gen 1”, the last working nVidia driver is 460.91.03
you can download the driver from the NVIDIA web site in the Beta and Older Drivers
my config:
$ inxi -SGc
System: Host: lenovo Kernel: 5.13.0-23-generic x86_64 bits: 64 Desktop: Xfce 4.16.0 Distro: Ubuntu 21.10 (Impish Indri)
Graphics: Device-1: NVIDIA TU117GLM [Quadro T2000 Mobile / Max-Q] driver: nvidia v: 460.91.03
Device-2: IMC Networks Integrated Camera type: USB driver: uvcvideo
Display: x11 server: X.Org 1.20.13 driver: loaded: nvidia resolution: 3840x2160~60Hz
OpenGL: renderer: Quadro T2000/PCIe/SSE2 v: 4.6.0 NVIDIA 460.91.03
I’ll have to check that.
In general, it naturally won’t work, since the backlight handler within the nVidia driver is exactly the reason why the backlight control is not working.
However, don’t be so quick to dismiss it, since his post brings up an interesting fact I haven’t been thinking about previously: generally, kernel module options can be substituted with NVreg_RegistryDwords=... parameters and the source code especially documents that each option is first checked against the static options list before applying to “the RM” (whatever that abbreviation stands for, I believe it’s Registry Msomething… Machinery?).
In any case, passing NVreg_RegistryDwords=EnableBacklightHandler=0 (not ...=1, of course) might actually stop the driver from interfering with the backlight even though the kernel module option has been removed and have the kernel handle this stuff. IF this stuff is still hooked up internally. Grepping the binary data shipped with the driver, it turns out that the string can still be found in the proprietary, binary part, so there’s a chance that we can still force/use it. It’s worth a try, but I’m too hold up to restart my graphical environment just now, so won’t be able to test for a while.
Yeah, the 460 series is the last version that worked across the board when it comes to backlight handling. I’m not keen on upgrading, though. Especially since 465+ fix quite a few lock up issues.
Please note the difference, not
EnableBacklightHandler
but
EnableBrightnessControl
just in case…
I’m already force-setting EnableBrightnessControl to true/1 in the X.Org configuration file without any effect, so that won’t help.
However, disabling the backlight handler is still on the table for me.
Finally I got it working thanks to someone answering to my Reddit question:
i915.enable_dpcd_backlight=0 that is the key, do not try it with 1 which does not work and is everywhere quoted… just change it to 0 and enjoy working backlight dimming…
grubby --info=ALL
index=0
kernel=“/boot/vmlinuz-5.15.12-200.fc35.x86_64”
args=“ro rootflags=subvol=root rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1i915.enable_dpcd_backlight=0”
root=“UUID=3f93ca69-acd9-4a7d-98f6-f9ae374ead12”
initrd=“/boot/initramfs-5.15.12-200.fc35.x86_64.img”
That probably works only for machines with Intel CPU. I’ll give it a try later, but I have an AMD CPU.
Downgrading, I meant downgrading, of course.
Sadly, it does not. Everything works fine up until loading nvidia-drm (or initializing the card by starting X), afterwards the backlight stays put on 100 %, no matter what value is written to the sysfs node.
The option doesn’t help to tell the driver to back off and let the kernel handle this part. It was worth a shot, though.
I’m glad that this worked for you. But it won’t work for everyone, merely users with hybrid graphic setups where the primary adapter is an Intel one.
Yep, pretty much. It also won’t work for machines where the Nvidia graphics card is hooked up to the display directly, without using a hybrid gmux/indirection through another framebuffer.
So… some of us are still stuck. I just hope that it won’t be a full year until Nvidia actually fixes the issue.