Bug 257948

Summary: Powerdevil can no longer control brightness
Product: [Frameworks and Libraries] solid Reporter: Andreas Kuhl <mail>
Component: powermanagementAssignee: Lukáš Tinkl <lukas>
Status: RESOLVED FIXED    
Severity: wishlist CC: adgeruy, arequipeno, biasquez, casta, damigos, gilboad, igor.s.krivenko, kde, lonestar, mail, sanjay.slnarayanan, schnitzelkuchen, StormByte
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: .xsession-errors + /sys/class/backlight/*

Description Andreas Kuhl 2010-11-26 10:18:34 UTC
Version:           unspecified (using KDE 4.5.80) 
OS:                Linux

Coming from KDE SC 4.5, Powerdevil could control screen brightness. The brightness slider in battery plasmoid worked fine. After Upgrading to KDE SC 4.6 Beta 1, this no longer works:

Powerdevil does not change screen brightness when switching profiles and the screen brightness slider of the battery plasmoid does not work. Nevertheless, changing brightness with FN keys works fine although the brightness OSD no longer appears.

Interesting dettail: After having changed the brightness with FN keys, the brightness slider of the battery plasmoid shows the correct level when collapsing and opening it again. But using the slider does nothing.

I have a small workaround by letting  the profiles execute a script that changes brightness  by writing a brightness value directly to /sys/class/backlight/acpi_video0/backlight. But this is just a hackish solution, the original functionality should be restored.

Do you need me to provide any additional information in order to pinpoint the problem?

Reproducible: Always
Comment 1 zarzych 2010-11-26 15:37:43 UTC
I've also switched from 4.5 to 4.6 Beta 1. For me brightness setting only doesn't work if I'm *not* using HAL. With HAL turned on everything works fine.
Comment 2 Andreas Kuhl 2010-11-26 15:42:00 UTC
HAL daemon is running and is selected as powermanagement backend in systemsettings.
Comment 3 Dario Freddi 2010-11-26 15:53:02 UTC
The Hardware tab no longer applies to PowerDevil: if you have upower installed, then UPower is being used by PowerDevil. It's clearly a bug in the UPower/XRandR backend, will reassign to Lukas.
Comment 4 Andreas Kuhl 2010-11-26 15:58:58 UTC
UPower is installed.
Comment 5 Lukáš Tinkl 2010-11-26 16:02:05 UTC
Yup, it's a bug in the upower backend, one that I can't ATM fix. Do you happen to have an ATI card, using the radeon free driver?
Comment 6 Andreas Kuhl 2010-11-26 16:04:51 UTC
I have switchable graphics but the ATI card turned off. radeon driver is loaded though, because it is needed to switch the card off. Currently I am running on integrated Intel Arrandale graphics with i915 driver.
Comment 7 zarzych 2010-11-26 16:08:58 UTC
(In reply to comment #5)

I have upower-0.9.7 installed and nvidia card using the newest drivers
(216.19.21).
Comment 8 Lukáš Tinkl 2010-11-27 01:19:30 UTC
Please do "xrandr --properties" and look for "backlight"; in case of the intel driver, "rpm -q rpm -q xorg-x11-drv-intel" (or similar under SUSE), also please try to update it if there's a newer version and try again.
Comment 9 Andreas Kuhl 2010-11-27 14:17:55 UTC
xrandr knows nothing about backlight: http://paste.opensuse.org/44000614

The intel driver is part of this package: xorg-x11-driver-video-7.5-15.2.x86_64
According to its changelog, the latest driver version is contained: xf86-video-intel 2.12.0

To repeat myself: Backlight control with FN keys works fine.
Comment 10 Lukáš Tinkl 2010-11-29 16:33:07 UTC
Your brightness is probably handled by the HW itself; anyways we can't make it work on the PowerDevil level at the moment due to the lack of xrandr backlight support.
Comment 11 Andreas Kuhl 2010-11-29 23:05:54 UTC
How was this supposed to work in KDE 4.5 anyway? It worked there pretty well...
Comment 12 Andreas Kuhl 2010-11-29 23:08:21 UTC
I just noticed that "solid-powermanagement brightness set [value]" works pretty well! So shouldn't it work with powerdevil, too, when it is built upon solid?
Comment 13 Lukáš Tinkl 2010-11-30 12:53:21 UTC
In KDE 4.5, HAL used to handle the brightness
Comment 14 Andreas Kuhl 2010-11-30 13:03:14 UTC
I mean that "solid-powermanagement brightness set [value]" works in KDE 4.6 Beta 1! Does powerdevil not build upon solid?
Comment 15 Lukáš Tinkl 2010-11-30 14:43:15 UTC
solid-powermanagement is gone in KDE 4.6 post beta 1, and PowerDevil uses Solid only partially, not for brightness for example.
Comment 16 Andreas Kuhl 2010-11-30 14:51:10 UTC
Ah, crap! :-( Nevertheless: Thx for your comments!
Comment 17 Michael 2010-11-30 20:55:19 UTC
Looks to me like either upower has to add what hal can, or the intel-driver needs to be fixed to add xrandr support.

I also have an intel card, and it works for me :)

closing, but if anyone thinks this should stay open, just post and i will reopen.

thanks for reporting, Andreas!
Comment 18 george panta 2010-12-03 00:42:10 UTC
Hello everyone!

I think this issue should remain open and powerdevil/solid should implement support for the /sys/class/backlight/* interface that a lot of laptops have and do not support xbacklight/xrandr.

I was searching for this issue and I saw that upower developers do not intend to implement support for backlight like HAL did.

I also saw from my distro that gnome-power-manager faced the same issue at version 2.30 and the solution was to use HAL at runtime for all the laptops affected (sony, macbook, thinkpad laptops and a lot of those using proprietary drivers like nvidia etc.).
However they implemented support for the /sys kernel interfaces in version 2.32.

I searched about that and found out that ubuntu had backported a patch from upstream gnome. This is the link hoping that it helps in giving an idea about the idea/implementation:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/gnome-power-manager/maverick/revision/172#debian/patches/00git-kernel-backlight-interface.patch

KDE 4.6 is already solid (pun intended! :D) and you have done a great job in getting rid of HAL. However for a truly HAL-less KDE I believe this feature is needed.
I think that if it is not ready by 4.6, something totally understandable, it should be communicated in promo and to distros so that HAL is preferred or recommended at least to those who are using laptops not supporting xbacklight/xrandr.

Thank you very much and I hope my comments were helpful!
Comment 19 Andreas Kuhl 2010-12-03 08:01:35 UTC
@George: Thx for investigating, sounds like a great idea. I will reopen this issue as feature wish, ok?
Comment 20 Guillaume Castagnino 2010-12-08 17:37:53 UTC
I had this but too with 4.6_beta1
You should try beta2 just issued. For me, it fixes the problem !

(here laptop with intel graphic card)
Comment 21 george panta 2010-12-08 18:12:17 UTC
@Andreas Demmer

Thanks for reopening :)

@Guillaume Castagnino

Thanks for the feedback! I will test beta2 as soon as I can. I am just waiting for the packages to hit my distro's repos.
Comment 22 Christian (Fuchs) 2010-12-09 19:23:55 UTC
There are other drivers with no / limited xrandr support, such as the wide spread nvidia proprietary driver. 

So for all the nvidia users out there, this functionality is a must have. 

Fuchs (not working here, 4.6 Beta 2)
Comment 23 george panta 2010-12-09 23:17:15 UTC
Yes, I can confirm that it is not working here too in Beta 2. 
Probably bugs were squashed for the xrandr backend in powerdevil so that some users like Guillaume with Intel gpus have backlight working.

But since I use the proprietary nvidia driver with no xbacklight/xrandr support, I have no backlight control as expected by the reasoning above.
Comment 24 omega 2010-12-11 12:51:34 UTC
with kde 4.6 (beta 1 and beta 2), i have these problems:
- can't control brightness
- can't change profiles ( i have only performance)


note:
hal removed and upower installed
Comment 25 Gilboa Davara 2010-12-16 12:32:56 UTC
May, or may not be related, but screensaver display blanking no longer works when using 4.6 b1 and b2 on two different workstations (both w/ proprietary nVidia driver). Am I the only one seeing this?
I assume that this relates to the lack of xrander support on nVidia's part?

- Gilboa
Comment 26 george panta 2010-12-16 22:11:25 UTC
Well, good news and a big thanks to Lukas Tinkl!

I just recompiled kdebase-workspace using the patch from reviewboard and the backlight brightness now works great!

The only problem I had was a CMake error about missing the backlight_helper_actions.actions file in powerdevil/daemon/backends/upower/

So I created a very simple one:

[org.kde.powerdevil.backlighthelper.brightness]
Name=Read Backlight Brightness
Description=Read Backlight Brightness using kernel interface
Policy=yes
[org.kde.powerdevil.backlighthelper.setbrightness]
Name=Set Backlight Brightness
Description=Set Backlight Brightness using kernel interface
Policy=yes

After configuring my system's polkit permissions, I can confirm that this works great!

I hope this gets merged for 4.6! Really great and fast work!
Comment 27 Christian (Fuchs) 2010-12-16 22:53:43 UTC
Indeed the patch at the reviewboard works, 
the only minor glitch is that (probably due to a rounding error) the OSD does not show full brightness at level 15/15, but a little bit less than the maximum. 

But I think that I can live with that. 

Thanks a lot for the quick fix, I sure hope it makes it into RC or final. 

Kind regards
Comment 28 Lukáš Tinkl 2010-12-17 12:57:42 UTC
Thanks for testing and for noticing the missing file in the patch :) I will add it to the review.
Comment 29 Andreas Kuhl 2010-12-17 13:09:25 UTC
Ah, cool! I will test out the patch this weekend.
Comment 30 Lukáš Tinkl 2010-12-17 13:16:57 UTC
For the reference, the patch is in this review: http://svn.reviewboard.kde.org/r/6141/
Comment 31 Lukáš Tinkl 2010-12-17 20:07:02 UTC
SVN commit 1207385 by lukas:

This patch adds a fallback mechanism for setting the display brightness
to the PowerDevil upower's backend using the udev
(/sys/class/backlight/) interface. It uses the KAuth framework to setup
a helper application that does the actual read/writes.

Reviewed by drf: http://svn.reviewboard.kde.org/r/6141/

BUG:257948


 M  +7 -0      BackendConfig.cmake  
 A             backends/upower/backlight_helper_actions.actions  
 A             backends/upower/backlighthelper.cpp   [License: LGPL (v2)]
 A             backends/upower/backlighthelper.h   [License: LGPL (v2)]
 M  +37 -6     backends/upower/powerdevilupowerbackend.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1207385
Comment 32 Dimitris Damigos 2010-12-18 11:32:45 UTC
I use nvidiabl module from http://www.nvnews.net/vbulletin/showthread.php?t=143025
It creates /sys/class/backlight/nvidia_backlight that should be added to your patch for it to work.
Comment 33 Andreas Kuhl 2010-12-18 12:57:55 UTC
I just reviewed your patch. One question:

In BacklightHelper::init(), you define the interfaces:

---
    interfaces << "nv_backlight" << "asus_laptop" << "toshiba"
               << "eeepc" << "thinkpad_screen" << "acpi_video1"
               << "mbp_backlight" << "acpi_video0"
               << "fujitsu-laptop" << "sony" << "samsung";
---

Afterwards, you interate over the interfaces and take the first one found. 
Since I have a notebook with switchable graphics, I have the interfaces acpi_video0 and acpi_video1. Since your patch lists acpi_video1 first, your iteration would use acpi_video1. But my backlight is controllable only with acpi_video0.

Sure, I could work around this issue by redirecting the symlink for acpi_video1 to acpi_video0. But it would be better to fix this in your code, wouldn't it?
Comment 34 george panta 2010-12-18 16:02:50 UTC
This commit also fixes hardware brightness keys for me (Fn+F5 or F6) \o/ (I used an acpi script workaround beforefor my keys.) 

However while Hardware Brightness Key DOWN works as expected, lowering the backlight brightness in correct steps, Brightness Key UP does not work at all.

I believe it has something to do with the way some backlights register on the sys interface.
For example my backlight does not follow the normal 100 scale for brightness but simply has 8 as max brightness and actual_brightness ranges from 0-8.
Comment 35 Lukáš Tinkl 2010-12-18 17:44:09 UTC
SVN commit 1207576 by lukas:

- adjust to work also with the nvidia proprietary driver which creates 
  /sys/class/backlight/nvidia_backlight
- take acpi_video0 into account first in case of switachable graphics

CCBUG: 257948


 M  +4 -3      backlighthelper.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1207576
Comment 36 Lukáš Tinkl 2010-12-18 18:15:01 UTC
SVN commit 1207582 by lukas:

avoid rounding errors

CCBUG: 257948


 M  +1 -1      backlighthelper.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1207582
Comment 37 Dimitris Damigos 2010-12-18 18:34:50 UTC
Thank you for your fast fix. But there is a small problem. My laptop is a sony vaio, so "sony_laptop" module is loaded so I can control Fn keys. The problem is that it also creates /sys/class/backlight/sony interface, which is not useful. So I had to add nvidia_backlight before sony in your patch. Isn't it possible to alter the code so that powerdevil controls every interface that it finds and not the first one to avoid such problems. I guess that you can not predict for every system which is the right interface to control. Powerdevil with hal I think it worked that way.
Comment 38 Lukáš Tinkl 2010-12-18 19:08:53 UTC
Re comment #37: What have you got inside /sys/class/backlight/sony?

Anyways, I think I'll have a closer look at HAL sources how it worked there...
Comment 39 Dimitris Damigos 2010-12-18 19:16:37 UTC
(In reply to comment #38)
> Re comment #37: What have you got inside /sys/class/backlight/sony?
> 
> Anyways, I think I'll have a closer look at HAL sources how it worked there...

It contains:
actual_brightness
bl_power
brightness
max_brightness
power
subsystem
uevent

Changing brightness or actual_brightness value doesn't have an effect.
Comment 40 george panta 2010-12-19 00:40:59 UTC
@Lukas Tinkl

Thanks for the swift response and commit!

However rev 1207582 does not not fix my problem.

But Having the whole value be qRound-ed solves this. So it's just a matter of moving the parenthesis to the end :D

I have tested this and it's perfect:

--- backlighthelper.cpp.old     2010-12-19 01:36:39.513333338 +0200
+++ backlighthelper.cpp 2010-12-19 01:14:48.176666665 +0200

@@ -108,7 +107,7 @@
         return reply;
     }
 
-    int actual_brightness = qRound(args["brightness"].toFloat()) * maxBrightness() / 100;
+    int actual_brightness = qRound(args["brightness"].toFloat() * maxBrightness() / 100);
     qDebug() << "setting brightness:" << actual_brightness;
     int result = file.write(QByteArray::number(actual_brightness));
     file.close();
Comment 41 Lukáš Tinkl 2010-12-20 18:36:11 UTC
Fixed, can you try again? :)
Comment 42 george panta 2010-12-20 22:44:52 UTC
Yes, trunk fixes the issue. :D

Thanks a lot once again for this! Awesome work! :D
Comment 43 Andreas Kuhl 2010-12-25 23:36:13 UTC
Just tried with KDE SC 4.6 RC1. Seems like the brightness slider in Powerdevil still has no other effect than showing the OSD, no brightness change at all. What permissions do my /sys/class/backlight/acpi_video0 files need to have? Right now, they are only writable by root.

Any debugging I can do?
Comment 44 Lukáš Tinkl 2010-12-29 17:32:55 UTC
They should be writable by root only, that's fine. The helper process takes care of that; can you paste some debug info from .xsession-errors?
Comment 45 Andreas Kuhl 2010-12-30 09:13:20 UTC
Created attachment 55369 [details]
.xsession-errors + /sys/class/backlight/*

I could not find anything related in .xsession-errors. I attached my .xsession-errors, maybe you find anything useful in it. I also added the directory listings of my /sys/class/backlight subdirectories.
Comment 46 Andreas Kuhl 2011-01-15 19:58:58 UTC
Any news on this?
Comment 47 Igor Krivenko 2011-01-30 01:17:38 UTC
Could you please add "dell_backlight" to the list of interfaces. Kernel uses this interface for a number of Dell laptops (dell-laptop.ko module). Such an addition fixed the brightness control on my laptop without any further modification of the code.
Comment 48 Lukáš Tinkl 2011-01-31 16:59:11 UTC
Git commit 419492bc9dae66e743e1e33fea0a06e4c4ec07c6 by Lukas Tinkl.
Pushed by lukas into branch 'master'.

add Dell backlight interface

CCBUG:257948

M  +7    -7    powerdevil/daemon/backends/upower/backlighthelper.cpp     

http://commits.kde.org/a5d5b61a/419492bc9dae66e743e1e33fea0a06e4c4ec07c6
Comment 49 Lukáš Tinkl 2011-01-31 21:27:54 UTC
Git commit 4ed7b9020fe5f52aed1413ec15e3f035afc22863 by Lukas Tinkl.
Pushed by lukas into branch 'KDE/4.6'.

add Dell backlight interface

CCBUG:257948

M  +7    -7    powerdevil/daemon/backends/upower/backlighthelper.cpp     

http://commits.kde.org/a5d5b61a/4ed7b9020fe5f52aed1413ec15e3f035afc22863
Comment 50 Dimitris Damigos 2011-02-04 21:35:49 UTC
I don't know if this is too much to ask, but could you change the order of the interfaces and prefer nvidia_backlight over sony, because now every time kdebase-workspace is updated I have to recompile it with this modification. After all if nvidia_backlight is present in a system is intended, because only nvidiabl provides it.
Comment 51 LoneStar 2011-02-14 19:51:04 UTC
I want to add my +1 to request on #50.
Another possibility would be to give the user an option to pick which backlight interface to use when more than one are present.
Comment 52 Lukáš Tinkl 2011-02-15 13:42:11 UTC
Re comment #50: already fixed, will be in 4.6.1
Comment 53 Ian Pilcher 2011-04-06 21:47:36 UTC
I'm having an interesting problem that I believe is related to this.

Environment is Fedora 14 (x86_64) on a Lenovo ThinkPad T510 with a "nVidia
Corporation GT218 [NVS 3100M]" GPU.  Fedora 14 was recently updated from KDE
4.5 to KDE 4.6.1, and the built-in display on this laptop now becomes very,
very dim when I log in to KDE.  This happens even if I'm on AC power.

Digging into this, I believe the root cause is that this laptop exposes two
backlight interfaces -- acpi_video0 and nv_backlight.  acpi_video0 supports
levels 0-15, and I am able to use it to adjust the brightness of my display.

nv_backlight, OTOH, claims to support levels 0-255, but writing any value to
/sys/class/backlight/nv_backlight/brightness causes the display to dim ...
until the brightness is raised by writing to
/sys/class/backlight/acpi_video0/brightness.

So it appears that some component of the KDE/upower stack is trying to use
the nv_backlight interface to control my display, where I need it to use the
acpi_video0 interface.

There's obviously no way for the software to know that this hardware is
broken in this way.  What I need is a way to configure the appropriate
component to use acpi_video0 and/or ignore nv_backlight.

How can I do this?

Thanks!
Comment 54 Lukáš Tinkl 2011-04-07 12:53:08 UTC
I can change the order of the preference, stay tuned; I'll post a Fedora scratch build for you to test :)
Comment 55 Lukáš Tinkl 2011-04-07 12:56:11 UTC
Git commit 09f7dbda30fea57a83346bf6cfffaffef20e2e45 by Lukas Tinkl.
Committed on 07/04/2011 at 13:00.
Pushed by lukas into branch 'KDE/4.6'.

give nv_backlight lower preference

CCBUG: 257948

M  +2    -2    powerdevil/daemon/backends/upower/backlighthelper.cpp     

http://commits.kde.org/kde-workspace/09f7dbda30fea57a83346bf6cfffaffef20e2e45
Comment 56 Lukáš Tinkl 2011-04-07 12:56:36 UTC
Git commit 0e6a5cab6bb74dd27c0b2bd0ccdb3f7752e4cca4 by Lukas Tinkl.
Committed on 07/04/2011 at 13:00.
Pushed by lukas into branch 'master'.

give nv_backlight lower preference

CCBUG: 257948

M  +2    -2    powerdevil/daemon/backends/upower/backlighthelper.cpp     

http://commits.kde.org/kde-workspace/0e6a5cab6bb74dd27c0b2bd0ccdb3f7752e4cca4
Comment 57 Dimitris Damigos 2011-04-07 16:13:20 UTC
Is it possible to add a config file and later maybe a gui option to select which interface to use? I believe it's not possible to know every system, so the order method is not ideal to learn which interface is present...
Comment 58 Ian Pilcher 2011-04-12 22:00:38 UTC
(In reply to comment #55)
> give nv_backlight lower preference

I can confirm that this fixes the problem I was experiencing on my ThinkPad
T510.

I have to agree with what Dimitris said, however.  There's probably no
order that will work on all hardware.  In the short term, I would think that
an environment variable would be the easiest way to override the default
behavior -- POWERDEVIL_PREFERRED_BACKLIGHT or somesuch.
Comment 59 G Lambert 2011-07-08 15:25:03 UTC
Could you please add "apple_backlight" to the list of interfaces ? Kernel uses
this interface for Apple iMacs and it fixes the brightness control on my iMac.
Thanks.
Comment 60 David 2013-01-14 22:59:55 UTC
I am using KDE 4.9.5 and my nvidiabl ( /sys/class/backlight/nvidia_backlight/ ) does not work with powerdevil and KDE, however it works by echo 50 > /sys/class/backlight/nvidia_backlight/brightness
Comment 61 sanjay.slnarayanan 2013-01-30 06:17:06 UTC
I am also using KDE 4.9.5 with nvidiabl and it doesnt work with powerdevil. It works if i cat it to  /sys/class/backlight/nvidia_backlight/brightness . 
I tried booting with kernel parameters acpi_backlight=vendor. If i do this, then i have only 1 backlight interface ie nvidia_backlight else i have 3 backlight interfaces nvidia_backlight,acpi_video0 and acpi_video1. However I am not able to control brightness through KDE , if i try to change it using the KDE, the brightness always goes to max and stays there. Only echoing the value into /sys/class./backlight/nvidia_backlight/brightness works.
Comment 62 Lukáš Tinkl 2013-01-30 12:20:53 UTC
Most probably a bug with the nvidia drivers which announce the xrandr capability but fails to get/set any values