Bug 196232 - Battery applet sets screen brightness to zero on click to open
Summary: Battery applet sets screen brightness to zero on click to open
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-battery (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
: 181718 (view as bug list)
Depends on:
Reported: 2009-06-12 19:52 UTC by Michael Zanetti
Modified: 2010-11-09 17:01 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Zanetti 2009-06-12 19:52:05 UTC
Version:            (using KDE 4.2.90)
OS:                Linux
Installed from:    Unlisted Binary Package

On my nvidia graphics card I can change the backlight from 0 (off) to 15 (full brightnes).

Sometimes the battery plasmoid seems to forget or read wrong the current brightness and sets the slider in the plasmoid to 0. If I click on it to open the controls the actual brightness of my screen is set to 0 and I can't see anything any more. To turn the screen on again I need to guess the position of the slider or use other tools that I can use blindly with the keyboard.
Comment 1 andrew 2009-10-01 04:59:13 UTC
possibly the same problem as bug 183137
Comment 2 Beat Wolf 2009-12-09 20:04:10 UTC

*** This bug has been marked as a duplicate of bug 183137 ***
Comment 3 Michael Zanetti 2009-12-09 22:13:22 UTC
I'm not really sure if its the same bug as bug 183137. 183137 refers to a wrong initial value after start-up. In my case the startup brightness level is always ok, but when I click the battery plasmoid to open the Power Management popup the screen brightness is set to either the maximum (15) or the minimum (0). More often to 0 though...

I've tested it right now: I clicked the battery, and the brightness has been set to 15.

Btw. I'm using KDE-4.3.4 (kdemod packages on ArchLinux)now...
Comment 4 Nate Weibley 2009-12-11 20:11:00 UTC
This is related to bug 217316. Please also see Gentoo bugs:
http://bugs.gentoo.org/show_bug.cgi?id=295600 and
Comment 5 Nate Weibley 2009-12-13 00:41:33 UTC
I wrote a small test case app and found that (at least in my system) QStringList<double> was the wrong type for brightnessReply in halpower.cpp:395
Error:org.freedesktop.DBus.Error.InvalidSignature Message: Unexpected reply signature: got "i" (int), expected "d" (double)

Changing type to double (at least in my debug util) allowed the remainder of the function to work properly. Oddly I edited the patch in my portage tree to reflect that change and rebuilt solid, but the bug still persists for me. 

At least it's a start... after my Univ. finals I hope to get more done on this.
Comment 6 Nate Weibley 2009-12-13 07:33:24 UTC
Tracked the bug down to two problems:
SVN commit 1057980 had two bugs in it: lines 390 and 411 specified QDBusReply<double> but the correct template was QDBusReply<int> for both.

After I patched and recompiled solid I still had the same problem so I did some more debugging and came across a latent bug that was activated by hal-0.5.14 (see git commit here: http://cgit.freedesktop.org/hal/commit/?id=6a24907092f0ab835a4f4a1737e56ceb4ebe741a )

powermanager.cpp:199 is called when the Battery plasmoid is initially clicked and historically passed the last brightness control discovered to initialize the screen brightness. It hasn't been a problem (at least for most users) before the new hal handling of LEDs, but now a bunch of system LEDs are getting addee as keyboard_backlights and the last device isn't the screen (at least in my case).
The resolution was to lookup screens for the QHash parameter as follows:

It still seems as though the solution may not be complete since screens and keyboards may all need to be dimmed, so perhaps this entire codepath needs a look?

I don't pretend to be a KDE or Qt developer, so please review my changes/suggestions and modify as necessary. I submitted patches to the gentoo bug linked above. The patches are testing and working on my system with both hal-0.5.13 and 0.5.14
Comment 7 Beat Wolf 2009-12-13 10:45:46 UTC
could you please submitt your patches to reviewboard.kde.org ? that way we can get a quick review and hopefully get them in before kde sc 4.4 beta 2 or at least RC1
Comment 8 Sebastian Kügler 2009-12-15 00:02:58 UTC
SVN commit 1062504 by sebas:

Fixes implicit typecast from previous commit to halpower.cpp and addresses a new bug precipitated by hal-0.5.14 in which the battery plasmoid unconditionally reset screen brightness to 0

Patch by Nate Weibley


 M  +1 -1      libs/solid/control/powermanager.cpp  
 M  +2 -2      solid/hal/halpower.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1062504
Comment 9 Dario Freddi 2010-11-09 17:01:44 UTC
*** Bug 181718 has been marked as a duplicate of this bug. ***