s2both
Holger Macht
hmacht at suse.de
Sun Mar 11 14:31:05 PDT 2007
On Sun 11. Mar - 23:24:49, S.Çağlar Onur wrote:
> 11 Mar 2007 Paz tarihinde, Holger Macht şunları yazmıştı:
> > Ok, what we already have is this:
> >
> > power_management.can_hibernate = true (bool)
> > power_management.can_suspend = true (bool)
> >
> > These values are just a reflexion of what the kernel thinks, namely
> > /sys/power/state. Another key like
> >
> > power_management.can_suspend_to_both = true (bool)
> >
> > would be needed. This key would come from userland though, so it can't be
> > treated like the others. So what about pm-utils installing a fdi file
> > containing the xml rule to add this key and to execute a script like the
> > ones from hibernate and suspend (hal-system-power-hibernate, etc.). Would
> > this be feasible?
>
> Why that key is coming from userland, i think its simply result of
> (power_management.can_hibernate and power_management.can_suspend). If im not
> wrong, if power_management.can_hibernate is true, that only means that
> machine has that support but we are not sure it can hibernate or resume
> correctly, right? So i think we can easily provide can_suspend_to_both and
> let GUI's/users select for themselves instead of using fdi's?
HAL having a key power_management.can_hibernate or can_suspend doesn't
mean anything to the desktop user. It just means that the kernel is
capable of doing it. These keys just give the desktop applications like
gpm or kpowersave the ability to know if the sleep methods are supported
at all. They can decide for their own if and how to present them to the
user.
Because s2both depends on userland software, the fdi file would just tell
HAL that the system would be capable of doing s2both.
Hope that clarifies a little bit.
Holger
More information about the hal
mailing list