[openbeos] Re: power_daemon vs _server.

> I never even thought of mail_daemon. Okay, you hereby have my 
> permission to name it power_daemon. ;)
> How will the updated framework look like? Will there be a new hook 
> for 
> each ACPI mode, or will they receive B_ACPI_... messages in their 
> _ioctl()?

The power management daemon isn't going to know anything at all about 
ACPI itself. There are going to be drivers, like acpi_button, that live 
in /dev/power and provide generic interfaces for fans, thermal sensors, 
batteries, etc. I want the daemon to work with APM as well, and with 
power management systems on other platforms, in order to handle ports. 
Each of these drivers will speak to the ACPI bus manager, thus removing 
any direct dependency the power_daemon has on ACPI.

Drivers for other hardware (e.g graphics, network cards) I think will 
register callbacks with the bus manager that are called at power 
transition states, just as the battery drivers and things will register 
callbacks for other events, like critical power levels, or thermal 
alerts. This part of the interface is as worked out yet, although it 
should begin taking shape in the next week.

Just for people who are interested, the general order I'm planning on 
implementing things is:
1. Thermal Zone support (fans, temp sensors, etc.)
2. Battery/power source
        (2a. Change APM driver so it works with the power daemon )
3. Standby/suspend

Just a heads up.
-Nathan

--
Fortune Cookie Says:

Q:  How many Oregonians does it take to screw in a light bulb?
A:  Three.  One to screw in the lightbulb and two to fend off all those
    Californians trying to share the experience.

Other related posts: