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.
possibly the same problem as bug 183137
*** This bug has been marked as a duplicate of bug 183137 ***
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...
This is related to bug 217316. Please also see Gentoo bugs: http://bugs.gentoo.org/show_bug.cgi?id=295600 and http://bugs.gentoo.org/show_bug.cgi?id=296544
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.
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: brightness(controls.keys(Solid::Control::PowerManager::Screen).at(0)) 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 -Nate
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
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 CCMAIL:nweibley@gmail.com BUG:196232 BUG:217316 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
*** Bug 181718 has been marked as a duplicate of this bug. ***