[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Fedora power management

Title: RE: Fedora power management

David, (cc-ing to hal-devel)

-----Original Message-----
From: David Zeuthen [mailto:david<at>fubar.dk]
Sent: Mon 15/11/2004 01:24
>On Fri, 2004-11-12 at 20:41 +0000, Hughes R Mr (UG - Electronic Eng)
>> Has this been done before? Or is it worth discussion? I thought I
>> would try you guys at f-d-l and then try the gnome people when I know
>> more good ideas/case studies.
>I think a better approach might be to teach hal about ACPI (for x86 and
>others), PMU (for PowerMac's etc.) and provide an abstraction using the
>functionality already in hal (e.g. properties on hal device objects and
>callouts, device information files). This abstraction should be made
>sufficiently extensible such that it may support more than ACPI and PMU
>as well as the varying features on different laptops [1].

Sounds good to me, cleanest and most portable across architectures.

> http://freedesktop.org/pipermail/hal/2004-July/000555.html
>Nothing really happened, though. Now that FC3 is out I hope to find some
>time to do this for FC4 - it shouldn't be too difficult.

Well, if you need a hand...

>An interesting question is how we allow the desktop session to say "put
>the system into standby". One trivial idea is to provide a 'system-
>suspend' command (through consolehelper or something), however I think
>that it might make more sense to make the hal daemon expose a D-BUS
>interface with the appropriate methods - e.g. perhaps just the method
>Suspend() on an interface org.freedesktop.Hal.Device.PowerManagement.

org.freedesktop.Hal.Device.PowerManagement sounds good. Then battstat could
then just call on this interface to do the suspend, and do away with that
nasty textbox configuration option for suspending.

>This method call should map to an appropriate script. That way we can
>leverage the D-BUS policy system for allowing/denying this action [2].
>Plus, that we'll need this in HAL anyway for other kind hardware/actions
>(e.g. Rename() and Eject() on storage volumes) and it makes it somewhat
>easier to use from e.g. GNOME applets.

So in this unified-HAL theory, where would the brightness of an LCD panel live?
Would a "LCD panel" be varient of monitor in the HAL tree? How can this
information be added to HAL?

Similarly, could we Implement an Eject() [to call cardctl eject?] on a PCMCIA
adaptor quite simply?

>[1] : Some laptops doesn't turn off the display when the lid is closed
>(my Powerbook 12" for instance); tablets PC's probably don't have a lid
>at all etc.
>[2] : which may be as simple as only allowing an authorized user at the
>console to perform the action.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]