KubuntuPowerManagement
Size: 2197
Comment: klaptop vs. kpowersave
|
← Revision 25 as of 2008-08-06 16:21:08 ⇥
Size: 9422
Comment: converted to 1.6 markup
|
Deletions are marked like this. | Additions are marked like this. |
Line 10: | Line 10: |
Make sure power management in Kubuntu is as good as it is in Ubuntu | Write a power management tool for KDE based on HAL. (Make this: '''an universal power management daemon with a KDE GUI'''. Read comments Elias12 for explanation.)''' |
Line 14: | Line 16: |
Power management in Kubuntu is flaky and unreliable. We should make sure it is a reliable as possible. | The existing klaptopdaemon uses obsolete technologies and is hard to maintain. The alternative kpowersave duplicates a lot of the power management support included in Ubuntu and exposed through HAL, this would make it very hard to support and it conflicts with Ubuntu packages. So we will write a new frontend to HAL. |
Line 18: | Line 20: |
Maisie wants to suspend her laptop but it doesn't work currently with Kubuntu. | Maisie wants to suspend her laptop but it doesn't work currently with Kubuntu because klaptopdaemon uses an obsolete method to detect if suspend is possible. Rhuaridh wants to change the brightness of his laptop but finds that klaptopdaemon has no option to do this. Boab wants to install kpowersave as the only reliable way to get power management in Kubuntu but finds this uninstalls several Ubuntu power management packages. |
Line 22: | Line 28: |
Find the best programme for the job and fix it up for Kubuntu. | KDE frontend to the properties exposed by HAL. Any laptop specific issues should be solved below HAL. |
Line 26: | Line 32: |
== Implementation == | The daemon will display a systray icon to show the battery level and plugged in status. It will have a tooltip to show more information and a menu which lets you configure or run suspend/hibernate. |
Line 28: | Line 34: |
=== Code === | The applet check if power management is supported (using HAL) and only run if it is on startup. |
Line 30: | Line 36: |
=== Data preservation and migration === | The applet will have different settings for when the laptop is powered and battery, when the laptop changes from powered to battery is will change the brightness according to the setting. |
Line 32: | Line 38: |
== Outstanding issues == | It will talk to HAL using libhal. It will listen to HAL signals for battery level. It will query HAL for suspend/hibernate abilities (if one is not available that will be disabled in the GUI), and it will use HAL for starting the suspend and hibernate. It will use hal-system-power-set-power-save for standby mode. |
Line 34: | Line 40: |
== BoF agenda and discussion == | Configuration dialogue: |
Line 36: | Line 42: |
What are planned changes in Ubuntu laptop support for Edgy (kernel/swsusp/uswsusp, powernowd, acpi-support, hotkey-setup, laptop-mode-tools, hal, pmi, )? Kubuntu should follow developments there as close as possible in order not to increase a gap between Ubuntu and Kubuntu laptop support. | {{http://kubuntu.org/~jriddell/power-config.png}} |
Line 38: | Line 44: |
KLaptopdaemon or KPowersave? More info on KubuntuPowersave page. * KLaptopdaemon directly works with /proc FS (acpi, apm) -> need to switch to hal (will work on more HW) * KLaptopdaemon config module is cluttered and complex -> needs simplification ang good defaults (+autoconfiguration) * KLaptopdaemon is missing nice-to-have features of KPowersave (brightness control, scheme...) * Powersave uses own scripts for power management -> need to use acpi-support/pmi/laptop-mode-tools as base (will work on more HW) * KPowersave would need configuration module (kde-guidance) to replace yast2 used in SuSE (+good defaults and autodetection) |
Tooltip when hovered over applet: |
Line 45: | Line 46: |
Should work out the box and make use of Ubuntu work as much as possible. | {{http://kubuntu.org/~jriddell/power-tooltip.png}} |
Line 47: | Line 48: |
Should offer stuff like a nice slider to dim the display. | Menu when clicking on applet: |
Line 49: | Line 50: |
Should recieve wider community testing as part of LaptopTestingTeam (e.g. Canonical supplied laptops should be tested also with Kubuntu). | {{http://kubuntu.org/~jriddell/power-menu.png}} |
Line 51: | Line 52: |
More info on power management: useful reading on [http://lwn.net/Articles/181888/ LWN]. | Design drafts can be found at * http://vizzzion.org/?id=viewpic&gcat=UbuntuDevSummitParis&gpic=IMG_7851.JPG#images * http://vizzzion.org/?id=viewpic&gcat=UbuntuDevSummitParis&gpic=IMG_7852.JPG#images |
Line 53: | Line 56: |
---- CategorySpec |
Code can be found at: http://websvn.kde.org/trunk/playground/base/guidance/powermanager/ == Comments == Elias12: * In order to make this thing successful I recommend to choose an approach similar to network-manager: A daemon running in the background and a KDE GUI to talk to it. Why? Because otherwise the point will come where you will throw away all your work and built a GUI for a daemon somebody else has written just like it was with knetworkmanager superseding kde-wireless-config or whatever it's name was. * The success of network-manager lies in the fact that KDE could use it's advantages eventhough it comes from the gnome community. Another example is dbus which will replace dcop in KDE4. Both nm and dbus could be used by anyone without having to install gnome. This freedom ensures a wide acceptance and potentially attracts a big community driving the development of the project. * On the contrary dcop did not survive since it was only available when installing all of kdelibs and all dependent packages (QT) as well. * Therefore I cannot stress enough, if you want to create something with sustained success, something long lasting, then split your project in a daemon and a GUI part. The daemon should exist as a seperate project and consequently as a seperate package with no dependency to KDE. This will make your work available for other desktops as well. Nobody will have to reinvent the wheel. And power management could finally be available even for puristic console users - I never understood why power-management should only be available if you are running a desktop environment anyway. The GUI would either be a subproject of the daemon in a seperate package or some time become an official part of KDE with a dependancy to the daemon package. LukaRenko: * I am missing configuration for action to perfom on Close Lid and Sleep/Hibernate/Power key. * close lid is fixed, key actions are not yet there --sebas * Since suspend/hibernate is also used by desktop users, we should also think about separating battery stuff (does hal support UPS battery) from suspend/hibernate config. * It would probably also make sense to separate brightness controls as they are not supported by all laptops (and probably no desktop) * brightness controls are not shown when HAL doesn't show a brightness device --sebas Ellen: * Didn't we agree on having three "Active Schemes" -> Powersave, Automatic and Performance that are added as an option to the plugged/unplugged profile? DannyKukawka: * Why do you try to develop a new application (I don't believe in a _temporary_ solution!) instead of work on KPowersave as proposed on powersave-devel@forge.novell.com? Why not spend your time to make KPowersave independend from powersave (also if I'm not a fan of powermanagement in HAL!) instead of develop yet an other KDE powermanagement applet? IMO it's a waste of time to develop such a temporary applet and we all (powersave/KPowersave developer, Luka, Michael Biebl and other) already spend enough time to get KPowersave in Kubuntu (I don't like to lose one's labour! ). * The KPowersave redesign would've taken too long (there's not code yet, after UVF) Ellen (2006-08-10): Beta Review * Brightness Slider: * Clicking onto the slider should move the handle to the closest tick. * fixed --sebas * Unclear what the ticks represent -> percentage? levels? Provide an indicator at least in the tooltip. * fixed --sebas * On my laptop (Samsung P30, Kubuntu Dapper), the maximum brightness I can set with the guidance power manager is only 47%. * fixed, please confirm --sebas * Battery Critical: What is battery critical? 5%? 10 Minutes? If the user can't set it himself, provide that information in the label: "When Battery Critical (5%)" * fixed, the number of minutes is configurable now, overriding HAL's poor defaults --sebas * Lid Closed: * Lid Closed should not be grouped with battery powered - it currently applies to both states. Alternatively, two lid closed might be introduced - having different settings for powered/battery is a use case for certain user groups. They may download huge files or compile in powered mode, but not in battery mode. * fixed --sebas * What is "blank"? "Screen Saver", "Blank Screen" or "Monitor off"? * There was no reaction on my Samsung P30 to this setting. * Confirmation: * The settings window is instant apply. We've not yet come to a final decision regarding instant apply for the HIG, but by consistency reasons I suggest not to use instant apply right now. In this case, there is also no direct feedback for battery critical or lid closed - as most KDE users are not used to instant apply, they might not know if the setting is applied immediately or if they have to click "close". In the worst case they expect the title close button to reset the changes. If you still decide to keep instant apply, add a button to revert changes. Changing to explicit apply would imply to make it a configuration dialog instead of the left-click action. Left click might then, for example, show a slider to set the current brightness (similar to KMix) (+ status info?). * fixed: It's now a KDialog with OK and apply buttons. --sebas * Brightness Preview: * Currently there is only a brightness preview for the currently active scheme (_either_ mains or battery powered). That means if you want to set the battery brightness when you are currently mains powered, you'll probably move the battery slider, realise that there is no preview, go to the mains slider, move it till you found a nice brightness level, then go back to the battery slider and set it there. Would be nicer to have a preview for both sliders: Whenever you move to a new location, the brightness is adjusted. Has to be tested if it should be set back to previous value after 5 seconds, or if it should remain till you either move the other slider or click save (assuming explicit apply). * 'somewhat fixed': You can set the brightness and will get immediate response. If cancel is pressed, settings are reverted, they're saved on [OK]. There is no 'preview' for the not-active state (on battery, on AC) --sebas Allee: * What I miss here is how 2 Batteries and 2 CPUs are handled. IMHO we need a place where status of all batteries and all CPU are shown. * multiple CPUs is implemented, multiple batteries is not (I don't have a second battery I can plug in) --sebas Chase: * Can we get an option to turn off the on-screen display? Even like the k3b OSD that you can right-click and ask it to go away. Feedback can be reported on KubuntuPowerManagementFeedback page. |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/kubuntu-power-management
Created: 6/6/06 by JonathanRiddell
Contributors: JonathanRiddell, LukaRenko
Packages affected: klaptopdaemon, powersave, kpowersave
Summary
Write a power management tool for KDE based on HAL.
(Make this: an universal power management daemon with a KDE GUI. Read comments Elias12 for explanation.)
The existing klaptopdaemon uses obsolete technologies and is hard to maintain. The alternative kpowersave duplicates a lot of the power management support included in Ubuntu and exposed through HAL, this would make it very hard to support and it conflicts with Ubuntu packages. So we will write a new frontend to HAL.
Maisie wants to suspend her laptop but it doesn't work currently with Kubuntu because klaptopdaemon uses an obsolete method to detect if suspend is possible. Rhuaridh wants to change the brightness of his laptop but finds that klaptopdaemon has no option to do this. Boab wants to install kpowersave as the only reliable way to get power management in Kubuntu but finds this uninstalls several Ubuntu power management packages.
KDE frontend to the properties exposed by HAL. Any laptop specific issues should be solved below HAL.
The daemon will display a systray icon to show the battery level and plugged in status. It will have a tooltip to show more information and a menu which lets you configure or run suspend/hibernate. The applet check if power management is supported (using HAL) and only run if it is on startup. The applet will have different settings for when the laptop is powered and battery, when the laptop changes from powered to battery is will change the brightness according to the setting. It will talk to HAL using libhal. It will listen to HAL signals for battery level. It will query HAL for suspend/hibernate abilities (if one is not available that will be disabled in the GUI), and it will use HAL for starting the suspend and hibernate. It will use hal-system-power-set-power-save for standby mode. Configuration dialogue: Tooltip when hovered over applet: Menu when clicking on applet: Design drafts can be found at http://vizzzion.org/?id=viewpic&gcat=UbuntuDevSummitParis&gpic=IMG_7851.JPG#images http://vizzzion.org/?id=viewpic&gcat=UbuntuDevSummitParis&gpic=IMG_7852.JPG#images Code can be found at: http://websvn.kde.org/trunk/playground/base/guidance/powermanager/
Elias12: Ellen: Didn't we agree on having three "Active Schemes" -> Powersave, Automatic and Performance that are added as an option to the plugged/unplugged profile? Why do you try to develop a new application (I don't believe in a _temporary_ solution!) instead of work on KPowersave as proposed on powersave-devel@forge.novell.com? Why not spend your time to make KPowersave independend from powersave (also if I'm not a fan of powermanagement in HAL!) instead of develop yet an other KDE powermanagement applet? IMO it's a waste of time to develop such a temporary applet and we all (powersave/KPowersave developer, Luka, Michael Biebl and other) already spend enough time to get KPowersave in Kubuntu (I don't like to lose one's labour! ). Ellen (2006-08-10): Beta Review Unclear what the ticks represent -> percentage? levels? Provide an indicator at least in the tooltip. Allee: Chase: Feedback can be reported on KubuntuPowerManagementFeedback page. Rationale
Use cases
Scope
Design
Comments
KubuntuPowerManagement (last edited 2008-08-06 16:21:08 by localhost)