Solus - Nvidia GTX 1070: brightness control not working

Hello Community,
I’m running a fully updated Solus on my Asus G752VS equipped with Nvidia GeForce GTX 1070 graphics card.

Nvidia driver version: 384.90
Xorg-server version: 1.18.4

Unfortunately I can’t change screen brightness and it’s a real pain for my eyes. There’s a slider to adjust the brightness, but nothing happens at all when I move it from minimum to maximum values.
I would very much appreciate any help in solving this annoying problem.

Please find attached the “nvidia-bug-report.log.gz” file.
nvidia-bug-report.log.gz (112 KB)

What desktop environment are you using?

Does the backlight brightness change if you use “xbacklight -set ” instead of the slider?

Hi aplattner, thank you very much for your reply.

Yesterday, when I tried to create Nvidia bug-report file, I followed Nvidia instruction but the command “startx – -logverbose 6” somehow broke my Solus. So I rebooted and from then every time I entered the login password, Solus returned back to the login screen. Since I wasn’t able to repair that in any way, I wiped out everything from my machine.
Just to make an experiment, I installed Ubuntu 17.10. In session and with Nvidia driver 384.90, brightness control didn’t work. The same as in Solus, moving the slider from minimum to maximum values didn’t produce any effect.

The “nvidia-bug-report.log.gz” file attached here yesterday was generated from freshly new installed, fully updated Solus, by applying only “sudo” (without sudo it didn’t work).
My desktop environment is budgie-desktop 10.4.

xbacklight is not installed in Solus by default, so via Software center I installed version 1.2.1-2.
If I apply command “xbacklight -dec 40” or “xbacklight -inc 40”, screen brightness changes :)
Unfortunately, the new brightness setting isn’t remembered after restart.

Thanks for checking! The bad news is that I still haven’t figured out why ACPI-based backlight control doesn’t work on these laptops. The good news is that the next 387.* release has an experimental (i.e. disabled by default) option to wire the sysfs backlight interface that GNOME is using to the same thing that xbacklight uses, rather than going through ACPI. Once that’s released, you should be able to enable that option to fix the slider.

Remembering and restoring the backlight brightness on restart isn’t the driver’s job, it’s the desktop environment’s (or maybe systemd-backlight@.service’s, I guess?)

Ok, very thanks.
Unlike the Ubuntu PPA situation, with Solus I don’t have a possibility to try Nvidia experimental/beta drivers. So I guess I have to wait another release within the 384 long lived branch version?

I have one additional question.
My girlfriend currently have a Lenovo Y700-17ISK laptop with switchable Intel/Nvidia graphics. She’s running Solus too. In her Lenovo BIOS, Nvidia is disabled - so she use only Intel. My Asus G752VS is without switchable graphics, so I use only Nvidia. Both laptops have identical display size of 17.3" and the same default resolution of 1920 x 1080 (16:9). While now with Solus, and before with Ubuntu, her Lenovo/Intel boot screen resolution is ok 1920 x 1080, my Asus/Nvidia boot screen resolution, both now with Solus and before with Ubuntu, is much smaller and ugly. Any idea of what could be the cause?

Notebook: MSI GT72 6QD
OS: Ubuntu 17.10 desktop

Behaviour: xbacklight -set works, FN+backlight keys don’t… they keys do work, and the brightness icon comes up like it’s working but the brightness does not change.

The notebook has also intel hd 530 graphic card and if I use that one (it’s switched at boot) then everything works. Maybe it’s not directly a driver problem but some “settings” must be changed maybe for it to work.

one year has passed since I reported this brightness control issue. I would like to kindly ask if there’s any hope to fix this problem.
Thanks for any info :)

From the changelog:

* Added an nvidia.ko kernel module parameter, NVreg_EnableBacklightHandler,
      which can be used to enable experimental handling of laptop backlight
      brightness through /sys/class/backlight/. This handler overrides the
      ACPI-based one provided by the video.ko kernel module.

This is probably the option that aplattner mentioned.
Looking at your logs, did you install the acpi daemon (acpid) meanwhile to check if that has an impact?

Thank you very much generix for your advice.
These are the 2 experiments that I performed after firstly uninstalling xbacklight:

I installed (Alternatives to) the package “acpilight”

sudo eopkg install acpilight-1.1-1-1-x86_64.eopkg

Nothing changes, brightness control still doesn’t work.
Then I followed the instructions from the “acpilight” webpage:
Setup an “udev” rule to allow users in the “video” group to set the display brightness. To do so, place a file in /etc/udev/rules.d/90-backlight.rules containing:

SUBSYSTEM=="backlight", ACTION=="add", \
  RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness", \
  RUN+="/bin/chmod g+w /sys/class/backlight/%k/brightness"

Nothing changes, brightness control still doesn’t work.
Before performing the second experiment, I uninstalled acpilight package and deleted its udev rule.

Here’s the simple reason why I think that I don’t have the suggested acpi daemon (acpid) installed in my Solus: Solus Development Portal: “acpid” - closed, wontfix:

I added a kernel boot parameter “nvidia.NVreg_EnableBacklightHandler=1” in this way:

$ sudo su
$ mkdir -p /etc/kernel
$ echo "nvidia.NVreg_EnableBacklightHandler=1" > /etc/kernel/cmdline
$ clr-boot-manager update
$ exit

Magically, the brightness control finally works, both by using the slider within Pover options and by using the keyboard FN keys.
My question is: one year after Nvidia started experimenting with this option, when it will be proclaimed as a stable and in what way it will be applied (automatic job or it will still required user’s manual intervention)?

Unfortunately, once again the new brightness setting isn’t remembered after restart. Since Aaron Plattner said that remembering and restoring the backlight brightness on restart isn’t the driver’s job, I will ask Solus developers for help…

Thanks for confirming that the option works. I made a change to enable it by default in a future release.