Looking at https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/backlighthelper.cpp#L46 shows that for Linux 3.x, the whitelist approach is never used and instead the available kernel backlight controls are ranked purely by their type and "firmware > platform > raw". In my configuration, however, the binary nvidia driver registers /sys/class/backlight/acpi_video0 which is "firmware" but unfortunately is non-functional and I don't know a way to unregister that sys-control. Nevertheless, I also have /sys/class/backlight/nvidia_backlight which is provided by https://github.com/guillaumezin/nvidiabl which works and is a "raw" control. So, powerdevil does not pick it in favor of the non-functional device. Also, in a scenario where there are actually multiple "equivalent" (type-wise) sys-controls, it would just pick the alphabetically highest which is a non-robust guess. I think, there should be a way to override this or even better offer all available controls (with an option to hide some). Reproducible: Always Steps to Reproduce: 1. Install KDE 4.8.5 on an ASUS G55VW (Nvidia GTX 660M with binary drivers) 2. Install nvidiabl (see above) Actual Results: KDE brightness controls don't have any effect. Expected Results: KDE brightness controls do take effect.
This should be fixed with latest NVIDIA beta driver, can you check please?
(In reply to comment #1) > This should be fixed with latest NVIDIA beta driver, can you check please? I am running nvidia driver 313.09 here and KDE by default cannot change the backlight level. This is on an ASUS G55VW which has a GTX 660M with a Seiko/Epson panel.
we can't change the preference (firmware, platform, raw) since it is how downstream (kernel developers) want it to be, we can't workaround this. Can you fill perhaps a bug in nvidiabl ? Oh also, can you check if you have any message regarding this in dmesg ? Setting it as a Resolved/Downstream this does NOT mean that we can't continue talking and figuring things out here, it is just a pointer for other people.
(In reply to comment #3) Could you please elaborate on that because as put, it doesn't make sense to me: In what respect do the kernel developers care which backlight control you expose to the user? My suggestion was not to change anything kernel related but to give the user a way to influence which (or maybe even multiple) controls are exposed via the UI. (Requesting nvidiabl to change from "raw" to "platform" would not help at all because it does not fix the heuristics and ambiguities in the backlighthelper code.) As I don't think, this is a kernel issue at all, I don't see how dmesg output plays a role. What are you looking for?
Kernel developers (If you are interested I can point you to one) told us to implement this heuristic (give priority to firmware above platform above raw), so we did. This is working in the 99% of the cases so it seems to be right. I asked the dmesg output because I can see some prints in nvidiabl code .
Found one of the sources where we got this information from: https://bugs.kde.org/show_bug.cgi?id=288180
(In reply to comment #6) > Found one of the sources where we got this information from: > https://bugs.kde.org/show_bug.cgi?id=288180 May I quote from there: "" As described, type can be used to describe the preference. However, using the gpu backlight (intel, radeon, nouveau, nvidia) provide a better control most of the time, so maybe an hybrid approach should be taken: - Use a whitelist/priority list (containing only intel, radeon, etc...) ? - If not found, use a firmware backlight - If not found, use a platform backlight - If not found, use a raw backlight "" I am in fact asking for item (1) in that list plus I am asking for giving the user the power to control things when the heuristics don't work. Also, in said recommendation, he says that the priority applies to the case that multiple controls refer to the /same/ device. That constraint is not checked in the backlighthelper and in fact, it is difficult to check. As I already said in my report: How can you tell that these backlight controls in fact refer to the same physical backlight and pick one over the other? Maybe, the machine just has two backlight controls for different screens? Then, the user should get a chance to control both anyway regardless of their relative type. So, it appears to me that there needs to be some kind of configuration mechanism for picking which to show. Maybe a config file, maybe a UI dialog, maybe udev properties? And if that is missing, use the 99% approach of the built-in priorities.