Table of Contents
Please read through these common questions and answers before emailing the mailing list.
You have to change the dpms suspend mode gnome-power-manager uses.
Open gconf-editor, and then change the keys
/apps/gnome-power-manager/ac_dpms_sleep_method
and
/apps/gnome-power-manager/battery_dpms_sleep_method
to one of the modes that work, e.g. standby, suspend or off.
gnome-screensaver is a session daemon that monitors user input, and if the mouse has not been moved, or the keyboard been pressed then it starts a timeout. When the value of this timeout reaches the value set in gnome-screensaver-preferences, then the login is marked as 'session idle'. This is when GNOME Power Manager performs all the session idle actions such as enabling low-power mode and lowering the laptop panel brightness.
As soon as the session is marked at idle, GNOME Power Manager starts it's own 'system' timer. When the timeout set in gnome-power-preferences is reached, and the CPU load is idle, then the idle action is performed, which is usually to turn off the screen, or to suspend or hibernate.
In gnome-power-manager 2-14 the timouts are not obviously linked to gnome-screensaver, but the timeouts are linked in reality. This is because the gnome-screensaver declares the session "idle" and then gnome-power-manager starts. Therefore the real time to suspend is actually the gnome-screensaver timeout PLUS the gnome-power-manager time.
In the g-p-m 2-15 development branch, the sliders in gnome-power-preferences are set to start at the value of the session-timout + 1 minute, as we cannot logically trigger before the session is marked as idle. If you adjust the value of the 'session idle' timeout in gnome-screensaver-preferences then the start of the sliders in gnome-power-preferences will change accordingly. This makes it more obvious for new users.
You might be able to use the percentage charge for g-p-m to use as the
policy data.
Open gconf-editor, and then change the key
/apps/gnome-power-manager/use_time_for_policy
to false.
You can do this easily by doing:
gconftool-2 --set --type bool /apps/gnome-power-manager/use_time_for_policy false
This should get the policy actions working for you, but of course the time remaining will still be incorrect.
You need to add to /etc/modprobe.conf the following text:
options ibm_acpi experimental=1
This will enable the experimental features and make the LCD work.
Well actually, yes. They are hosted on my personal website so please don't link to them from other places. They tend to change quite rapidly too, so you can see the current development work.
When you suspend and then resume, ACPI does not seem to send the "lid open" event like it should, which I presume is because userspace is not in a position to handle the kernel event when we start to thaw userspace processes.
What we have to do it manually refresh the lid device using HAL when we resume, so that the new "lid open" value is propagated to gnome-power-manager.
We can do this in the hal-system-power-suspend
and
hal-system-power-hibernate
files,
which are usually located in /usr/share/hal/scripts/
.
You have to edit this file, and change:
exit $RET
to:
#Refresh devices as a resume can do funny things for type in button battery ac_adapter do devices=`hal-find-by-capability --capability $type` for device in $devices do dbus-send --system --print-reply --dest=org.freedesktop.Hal \ $device org.freedesktop.Hal.Device.Rescan done done exit $RET
IMPORTANT: I may have told you to add these lines already which probably won't have worked. The "--print-reply" was the missing option - you must include this option for the Rescan() to work.
CVS HAL already has this fix upstream, but the next version may not be released for a while, hence why I'm providing this fix here.
Update3: All the fixes are present in released 2.14.3.
It supports whatever backends HAL supports! At the moment this includes APM (Pre-2000 Intel computers), ACPI (most modern Intel computers) and PMU (Powerbook, and iBook PPC computers).
Before showing items such as "Suspend" and "Hibernate" in the menu g-p-m checks two things.
If HAL can detect a sleep handler in the kernel. You can test this doing "lshal | grep can_suspend". HAL works this out from looking at /sys/power/state, and also checking for the presence of suspend2.
If your administrator (or you!) has disabled the ability to do a certain action. You can test this using "gconftool-2 -R /apps/gnome-power-manager | grep can" and change the values to be something more suitable.
For instance, my PowerBook reports from HAL that it can suspend and hibernate, but because I know my hibernate doesn't work, I can disable it in gconf-editor removing the option from gnome-power-preferences and the drop-down menu.
If HAL doesn't list the options you want, then maybe you need to check your BIOS to check that it's running in the correct mode, and also that you have compiled your kernel with the correct options.
If there are no gconf keys returned by the second check above, you need to reinstall your gconf schema as per gnomebug:341256: (as root)
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule data/gnome-power-manager.schemas killall -HUP gconfd-2
If you click the mouse, or scroll the scroll-wheel without moving the pointer, then gnome-screensaver will detect the session as being idle. This is a limitation of X.org, but is worked around in newer versions of gnome-screensaver.
If your application is doing a long operation, you might want to disable the ability to suspend for a little while. You should use this method if you really don't want the user to be able to suspend, or for the computer to save power by hibernating or suspending during:
Copying files in Nautilus
Doing a long kernel compile or Matlab simulation
During a SELinux relabel
Many others...
Then you can use the Inhibit() and UnInhibit() DBUS methods built into the newest versions of gnome-power-manager. Here is a simple demonstration in python:
#!/usr/bin/python import dbus import time bus = dbus.Bus(dbus.Bus.TYPE_SESSION) devobj = bus.get_object('org.gnome.PowerManager', '/org/gnome/PowerManager') dev = dbus.Interface(devobj, "org.gnome.PowerManager") cookie = dev.Inhibit('Nautilus', 'Copying files') time.sleep(100) dev.UnInhibit(cookie)
There is an example which shows developers how to add Inhibit and UnInhibit DBUS methods into existing programs.
If you call the inhibit methods on gnome-screensaver, then gnome-screensaver will not mark your session as idle. This means that the screen will not dim, the screensaver will not start and the computer will not suspend automatically.
While playing a movie fullscreen, totem should use the gnome-screensaver inhibit methods. The idea is that totem does not have to worry at all about power management. The only thing it wants to assert is that even though there are no key presses or mouse movements, the session is still being used.
The only applications that should use the gnome-power-manager inhibit method are things that want to assert that the session can be marked as idle, but important things are still happening, so it shouldn't power down. For example, when copying 4.5GB of files in Nautilus, you want the screensaver to display, and the LCD panel to dim, but you don't want the computer to think that it is idle and shutdown, suspend or hibernate.
When you suspend or hibernate due to critically low power, then plug in power and then resume, g-p-m might keep suspending again and again as it still thinks the power is critically low. This is fixed in 2.14.0, where a timeout was added so that we wait for the power subsystem (ACPI/PMU/APM) to settle down before we read the values again.
First, if you are using Fedora Core 5, then the menu has been disabled as g-p-m has been integrated into the gnome panel, just look under "System" for the functionality. If you compiled from source yourself, make sure you added the gconf schema correctly.
WARNING **: gpm_hal_suspend: A security policy in place prevents this sender from sending this message to this recepient, see message bus configuration (rejected message had interface "org.freedesktop.Hal.Device.SystemPowerManagement" member "Suspend" error name "(unset)" destination "org.freedesktop.Hal") WARNING **: org.freedesktop.Hal.Device.SystemPowerManagement.Suspend failed (HAL error)
Ubuntu ships a locked down DBUS by default for Dapper which prevents non-root from issuing methods to HAL. To allow the current logged in user to use these methods, just install the libpam-foreground package.
It's enabled for xscreensaver, not gnome-screensaver. XSS is the legacy system that will be replaced with gnome-screensaver very soon. You probably need to install this package, and then g-p-m will automatically work with gnome-screensaver to use the DPMS settings of your monitor.
After numerous debates, the consensus was that is was not a good idea to add this functionality to HAL. It's was decided user-configurable powermanagement was not really required when modern harddisks have really intelligent powermanagment.
Here the power consumption data for a typical notebook harddisk (ide/sata):
Startup (peak, max.) 5.5W NC Seek 2.3W 2.7W Read (avg.) 2.0W 2.3W Write (avg.) 2.0W 2.3W Active idle (avg.) 1.1W 1.2W Low power idle (avg.) 0.85W 0.9W Standby (avg.) 0.2W 0.25W Sleep 0.1W NC
The conclusions you can take from this are:
A disk on Low Power idle need less than 1 Watt per hour. For a normal battery with 50000mWh you could run the harddisk for over 50 hours.
If you do not read/write from/to the harddisk the disk regulates power, but never shuts down the device. The reason is easy: you lost more power with each startup than to leave the harddisk online somewhere between 'Active idle' and 'Low power idle' (depends on the model/manufacturer).
The other reason to leave this to the internal powermanagement of the disk is: the time needed to reactivate the device. You lose more performance than you lose power between 'Active idle' and 'Low power idle'.
If you use a journaling file system you normally need to flush periodically. This could run in a race between shut down device and restart device by system to flush. This means more power consumption as you change nothing.
You can't set powermanagement for exteral USB harddisks, because you can't send the needed commands over the USB link to the disk.
One of two things might be the problem.
HAL might not be running the addon that captures the acpi event.
You BIOS could be faulty, and might need a work-around. Please send a bug report.
For the first case, try to find the hal processes that are running:
ps -eaf | grep hal
And check for the process hald-addon-acpi. If it is not being run, then please make sure that HAL is being run with the --retain-privileges option in the haldaemon initscript. An alternative to this is to use acpid, rather than the kernel proc file.
You can use the dbus-send program. For example, you can set the DPMS mode by running the following:
dbus-send --session \ --dest=org.gnome.PowerManager \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/gnome/PowerManager \ org.gnome.PowerManager.SetDpmsMode \ string:suspend
You can put the system into hibernation using the following:
dbus-send --session \ --dest=org.gnome.PowerManager \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/gnome/PowerManager \ org.gnome.PowerManager.Hibernate
See the developers guide file in CVS for the full list.
HAL might not *yet* support your distro, or you might have found a bug in GNOME Power Manager. Refer to the reporting bugs section.
Before HAL had the method support (added in 0.5.4), GNOME Power Manager used an external daemon running as root to do all the dirty work. This daemon was called PowerManager. This is now obsolete with HAL 0.5.3, and with the new work that we have done, HAL far surpasses the capabilities of PowerManager. PowerManager and pmscripts are now obsolete.
You can get CVS updates from navi.cx in RSS format.
The DBUS interface API is changing frequently, and will continue to do so until DBUS 1.0 is released. Many DBUS apps have lots of configure logic and extra code that I could not maintain - and is a waste of my time to support a version of DBUS that is already obsolete. I will always track the latest released version. Also, some bugs in the newer DBUS's have been fixed that impact the operation of GNOME Power Manager. You are welcome to patch G-P-M to work with an older DBUS if you wish.
G-P-M uses advanced features of HAL that did not exist in past versions. You cannot patch G-P-M to support an older HAL, as it will not work. Encourage your distro to update their version of HAL, and then G-P-M will work.
You may need to add a s3 command to your kernel boot string so that the kernel can re-initialise your video card. See this document for more details, or to see if your system has been identified as needing any extra switches.
This works automatically using GNOME 2.14, using the new autostart functionality of gnome-session. For older versions of GNOME, you will have to run GNOME Power Manager from a terminal or use gnome-session to launch GNOME Power Manager for each session.