Summary: | Battery applet sets screen brightness to zero on click to open | ||
---|---|---|---|
Product: | [Plasma] plasma4 | Reporter: | Michael Zanetti <mzanetti> |
Component: | widget-battery | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ahartmetz, andrew.dorrell, asraniel, glua, jesperht, nweibley, shawn.starr |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Michael Zanetti
2009-06-12 19:52:05 UTC
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. *** |