nvidia_backlight class is NOT chosen by gnome-settings-daemon or KDE's power devil

[acimmarusti]

These two bug reports illustrate the problems two leading desktop environments have with the nvidia_backlight (nvidiabl) driver:

https://bugzilla.gnome.org/show_bug.cgi?id=721050

https://bugs.kde.org/show_bug.cgi?id=315506

Digging into the code of both backlight managers, they basically do the same thing. They use udev to look for the correct path to the interface to change the backlight brightness. Bottomline is that they have this hierarchy for classification of the interfaces:

firmware > platform > raw

They are NOT going to change this because it works well in most cases and they were told to do it this way by kernel developers.

The BIG problem is that the kernel thinks of nvidia_backlight as RAW, while (in the case of my laptop -> Asus G55VW) the erroneous acpi_video0 is considered FIRMWARE. Thus both gnome and KDE use acpi_video0 over nvidiabl, even though ONLY the latter works in changing the screen backlight brightness.

I quickly changed the code and advertised the driver as type FIRMWARE. This, however still didn't work. I think the acpi_video0 is still chosen just because it it is first in alphabetical order.

Is there no way around this problem?

[guillaumezin]

Hello,

You're right, I forgot to mention in README the bl_type option, but it exists, I corrected that. You can do add "options nvidiabl bl_type=firmware" to /etc/modprobe.d/nvidiabl.conf. Maybe this will become the default in next release.

[acimmarusti]

Well it matters not. It still does NOT integrate well with any desktop environment out there. If you look at the bug report I generated with GNOME's bugzilla, you will see that they responded saying "this is not the task of the desktop environment" but that of the kernel. I happen to agree.

Is there an outstanding reason why you haven't tried to push this module into the mainline kernel? this would definitely bring about the resolution of these issues without the need to remap keys and invoke homebrew scripts. Because it could be advertised as the acpi_video0 interface or subvert this one in favor or nvidia_backlight which would make everything work.

If mainlining is not an option at the moment, a "quick and dirty" workaround could be to do the following 2 things:

1. Advertise nvidiabl as FIRMWARE by default
2. Rename the /sys/class/backlight/nvidia_backlight folder to something that has alphabetical precedence over acpi_video0. This is ugly, but it might just work, like 0nvidia_backlight.

I'll try to give this a shot when I get some time

[guillaumezin]

Hi,

I don't agree with GNOME, this is general issue : kernel + desktop environment. It could happen that you have 2 devices to talk too because you have 2 GPU in a laptop, and deskop environment should change value on both. In the real life, usually only 1 GPU only responsible for backlight control. We should be able to disable easily a useless backlight driver and it becomes a kernel issue. The rename hack is ugly, but probably the best short term solution.

In an ideal world, I would try to integrate this driver in kernel and workaround this issue, but until now, I didn't for 3 reasons:

• it seems that (finally) there is some kind of support in the proprietary nvidia driver. I don't check how to enable it and what GPU are supported, but I received some feedbacks about it.
• Second reason: I have painful memories trying to integrate my little hacks in a big open source project (Drupal), this is time consuming, people are critical, and I did this driver the hackish and quick way .
• Third reason, related to the previous one, I hardly find free time, I have 3 young kids, the 4th is coming, I have higher priorities right now. I was hopping that someone could fork the project to integrate it, it never happened until now, as far as I know.

Best regards.