Re: [acpi-jp 1931] Re: acpid implementation?
Michael Smith wrote: On Saturday, November 9, 2002, at 04:12 AM, Terry Lambert wrote: Repeat: #1 is power profiles I don't see why this requires an 'acpid'. You want a control tool, sure, but power policy is not something that needs a daemon. The tool has to change the settings based on events, like unplugging external power from a laptop, resulting in the display backlighting being dimmed or turned off. This isn't necessarily something that can be handled just by selecing static initial sysctl settings. Think in terms of the PowerProfile system tray icon under Windows on a Sony VAIO laptop, as it comes configured from the factory. The control application that you get when you click on the system tray icon... that's just eye candy. I agree that any application can deal with that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1931] Re: acpid implementation?
On Sunday, November 10, 2002, at 12:19 AM, Terry Lambert wrote: Michael Smith wrote: On Saturday, November 9, 2002, at 04:12 AM, Terry Lambert wrote: Repeat: #1 is power profiles I don't see why this requires an 'acpid'. You want a control tool, sure, but power policy is not something that needs a daemon. The tool has to change the settings based on events, like unplugging external power from a laptop, resulting in the display backlighting being dimmed or turned off. Ok, so the basic problem here is that you think that these are discrete events that can be managed or tied together in userspace. The bad news is that they aren't. Policy management is trivial, and you can (and should) do it inside the kernel. The real work lies in implementing the base features and structuring it all in a fashion that will actually work with the hardware that's shipping. None of this requires a daemon. = Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1931] Re: acpid implementation?
On Saturday, November 9, 2002, at 04:12 AM, Terry Lambert wrote: Repeat: #1 is power profiles I don't see why this requires an 'acpid'. You want a control tool, sure, but power policy is not something that needs a daemon. o replacing devices in a multipurpose bay, which may take one of a number of devices, including a battery Does not require (and could not practically be assisted by) a daemon. o port replicators with devices in them Does not require (and could not practically be assisted by) a daemon. o Docking adaptors Does not require (and could not practically be assisted by) a daemon. o Forced hibernate and/or shutdown, pending an empty battery Does not require a daemon. o Software implementation of features (e.g. selective powerdown or operational level, based on idle time, user preferences, or other things not settable by sysctl In other words, misc stuff. Still nothing concrete. = Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
