Hi, my brightness keys have stopped working in the upgrade from Kubuntu 12.10 to 13.04. The OSD appears, but there is no change. Using xbacklight via the CLI also has no effect.

FWIW, /etc/default/grub contains

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="acpi_backlight=vendor"

I attempted removing the part between the quotes and restarting. The screen was less bright, but when pressing the keys, again, the OSD appeared, but there was no change. In the past, if I didn't have this option, then I could never achieve 0% brightness. I had to have this option to be able to totally darken the screen.

I'm not sure if this is important, but in 12.10, I attempted enabling SNA once, which also had a similar effect on the brightness keys.

I also tried all four permutations in the system settings of (compositing type = OpenGL/XRender) and (Qt graphics system = Native/Raster), but this didn't help either.

==EDIT==
Not sure if it's relevant, but I'm using Bumblebee with an Nvidia Optimus card.

==EDIT==
I just tried adding

Code: Select all

Option "RegistryDwords" "EnableBrightnessControl=1"

To the Device section of `/etc/bumblebee/xorg.conf.nvidia` and `xorg.conf.nouveau`, but it made no difference.

I originally had to do this in Unity to get brightness keys working, although when I clean installed Kubuntu 12.10 six months ago, I didn't have to any more. I thought it was worth a try now, though.

It may be that your system is attempting to change the brightness of the Nvidia device, rather than the Intel device which your screen is actually attached to.

Can you check the content of "/sys/class/backlight/" please, in particular for "intel_backlight" and "acpi_video0".
It might also help if you could test your system without the Bumblebee modifications.

Ah, okay. It seems that part of my troubleshooting was inadequate since I forgot to run `sudo update-grub` after modifying `/etc/default/grub`. Nonetheless, it's still not entirely solved for me.

When `/etc/default/grub` contains

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="acpi_backlight=vendor"

`/sys/class/backlight/` contains `dell_backlight` and `intel_backlight`. Pressing the brightness keys does nothing to the display, but modifies the value in `dell_backlight/brightness`. However, if I manually modify the values in `intel_backlight/brightness`, the backlight changes as expected.

If I modify `/etc/default/grub` to contain

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT=""

`/sys/class/backlight/` now contains `acpi_video0`, `acpi_video1` and `intel_backlight`. Now, the brightness keys work (somewhat), and the value of `acpi_video1/brightness` is modified.

As stated in the OP, acpi_backlight=vendor appears to give me more control over the backlight. For example, I can reduce the backlight down to 0% and have the screen turn off. Without this grub option, I can reduce `acpi_video1/brightness` to 0 with the brightness keys, but the backlight is still on. Hence, it seems that the ideal situation is for the brightness keys to modify intel_backlight instead of acpi_video1.

I'm not exactly aware of the preference order which is used by Powerdevil to change brightness unfortunately, as I think it favours using X mechanisms first, then falls back to writing values into those /sys files - in a predetermined order depending on their presence.

You would have to ask the developers how to make it favour intel_backlight however. I suspect it would require a recompile though.

I have the same problem, I have an Acer Aspire V5-571p, I can't control the brightness with Fn + rigth or left arrows

Does manually echoing values into those files work for you? If driver support for changing the brightness is not available, then there is nothing KDE can do.

bcooksley wrote:I'm not exactly aware of the preference order which is used by Powerdevil to change brightness unfortunately, as I think it favours using X mechanisms first, then falls back to writing values into those /sys files - in a predetermined order depending on their presence.

You would have to ask the developers how to make it favour intel_backlight however. I suspect it would require a recompile though.

Thanks bcooksley. Which developers are you talking about though? Are you talking about kde/Powerdevil devs?

I'm referring to the Powerdevil developers here - who are also KDE developers (Powerdevil is the internal name of KDE's Power Manager).

bcooksley wrote:I'm referring to the Powerdevil developers here - who are also KDE developers (Powerdevil is the internal name of KDE's Power Manager).

Thanks again. And would the best way to contact them be by filing a bug report?

In this case, it probably would be better to ask on kde-hardware-devel@kde.org - as this is a more complicated question which may require a different avenue of debugging.

Thanks yet again, bcooksley. I've emailed the devs as suggested and I'll keep this thread updated when I hear back from them.

I've still haven't heard back from the mailing list that I posted to over ten days ago. However, I've found a bug that seems similar to my issues. A recent fix seems to have been implemented to make PowerDevil select the correct interface for some users, but (I assume) this has broken it for me! I've posted on that bug's page with my information.

That is unusual - Alex Fiestas responded to your mail 6 days ago.
Quoting his mail below:

Hi

There are a bunch of bug reports in bugs.kde.org about these kinds of issues,
bugzilla is the right place to discuss these things, not the mailist

I just wrote this small wiki page with some information about these issues:

http://community.kde.org/Solid/PowerDevil/Brightness

In summary brightness situation in Kernel sucks, There is no guarantee that 0
means "display turned off" (for that we should use DPMS) and in your case is
probably the GPU driver deciding which file to modify, not us.

Ah okay. I posted to the mailing list but was not subscribed to it. I guess he didn't reply all.

I've filed a bug with my distro (Ubuntu), although I'm yet to file to the kernel.

Thanks again for your help.