From owner-acpi-jp@jp.freebsd.org  Thu Dec 21 14:42:41 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id OAA00333;
	Thu, 21 Dec 2000 14:42:41 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.osd.bsdi.com ([167.216.157.206])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id OAA00328
	for <acpi-jp@jp.freebsd.org>; Thu, 21 Dec 2000 14:42:40 +0900 (JST)
	(envelope-from msmith@mass.osd.bsdi.com)
Received: from mass.osd.bsdi.com (localhost [127.0.0.1])
	by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eBL5rTc00562
	for <acpi-jp@jp.freebsd.org>; Wed, 20 Dec 2000 21:53:29 -0800 (PST)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200012210553.eBL5rTc00562@mass.osd.bsdi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Mon, 18 Dec 2000 00:57:16 +0900."
             <20001218005716Q.iwasaki@jp.FreeBSD.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 20 Dec 2000 21:53:29 -0800
From: Mike Smith <msmith@freebsd.org>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 987
Subject: [acpi-jp 987] Re: Generalised power-management interface (was Re: Some power device driver. ) 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org

> > I'll try to make a simple prototype on PM info. in a few days.
> > Any other things to be considered?
> 
> I've created simple gpm driver, library and application.  Currently
> only APM has the interface for it, but I think it would be enough to
> start with.
> 
> Any comments welcome.  Thanks!

A couple of thoughts:

 - Calling the library 'gpm' is going to seriously confuse people that 
   immediately think of the Linux "gpm" mouse stuff.  I think "ospm" is 
   better, but that's probably ACPI infecting my brain.

 - This is just wrong:

+dev/gpm/gpm.c          count gpm 

   We should use a linker set to find ospm ioctl handlers.  The linker
   set entry should also have a flag to indicate whether the ospm handler
   is active, and a string pointer to its name/description.

 - I'm not sure that a single structure is enough yet.  There's a really 
   good argument for a very simple, generic power management interface,
   and also a good argument for a much more complex one.  I think the 
   current structure is trying to be both.

Thinking about the generic power management interface...

It should be possible to do the following things:

 - set power consumption policy to "high" or "low"
 - put the system into a "suspend" and/or a "sleep" state

The following information should be available:

 - the status of AC power
 - the charge state of attached batteries
     o percentage (optional)
     o high/low/etc (optional)
     o charging in progress (optional)

I think the interface that's been proposed actually covers almost all of 
this, so perhaps it's not really too specialised either.

The "specialised" interface is probably going to be *much* more complex, 
and perhaps we're better off just having per-management-style control 
tools for that.

On the whole though, it looks pretty good!



-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E


