First, my thanks and congratulations to everyone who's been working on
ACPI -- I love some of the new abilities, and I can't wait until I can
switch to it.  It's almost there.

I do have some issues involving the user interface, though.

suspend/resume scripts
	 There don't seem to be any.  I do a lot in my /etc/apm/suspend
	 and resume scripts; acpi needs that ability

other states
	Do we support other ACPI states?  Are we going to?  Standby
	is nice...

lid open
	What does acpi do on a lid open event?  Yes, there's a
	script -- but how does the script run if the machine is
	still in state 3? If it's not in state 3 at that time, is
	there a purpose to the script?  On my T42, I can suspend
	with the proper sysctl, and wake up by hitting the Fn key.
	If I suspend and close the lid, though, opening it doesn't
	wake the machine up.  I haven't tried writing a lid_switch
	script that will do the sysctl when I close the lid, to
	see if that makes for useful behavior when I open it.

battery state
	'envstat' gives a lot of useful information, but it's
	missing some things.  The battery model and serial number
	really should be available that way; I'd love to write a
	daemon that tracked battery behavior over time.  (Windows
	has such a thing, at least for Thinkpads.)  There's no
	indication of 'time left', though arguably that should be
	calculated at a different layer.

	The values for the design capacity of the battery vs. the
	last full charge are *very* useful.  (My Ultrabattery,
	which I had felt was dead, really is -- it's last full-capacity
	charge was 3 Wh, compared to a design capacity of 23.76
	Wh...  My old main battery was only managing 46.66 Wh,
	compared to a 71.28 Wh design capacity.)

	This does pose an interesting question about what battery
	status tools should display.  sysutils/asapm, which has
	been patched to use the envstat interface if available,
	gives battery percentage relative to the design capacity.
	apm (and Windows) seem to give it relative to the last full
	charge.  It isn't clear to me which is correct.  It's good
	to know how worn out your battery is, but it's also good
	to know when it's as fully charged as it can be.

	acpibat did not seem to notice when I (suspended and)
	switched batteries; in particular, the design and last full
	charge capacities did not change.   This is a bug, though
	arguably I should have told it that I was doing this.  Of
	course, there's currently no way to tell acpi about switches,
	whether it's inserting or removing an Ultrabay DVD drive
	or simply switching batteries.

	I wish there were a single interface that scripts could
	use when talking to power management.  Right now, I use
	'apm' for various things, such as setting my screen background
	color and logging battery state information.  With acpi,
	I'll have to use envstat, and it doesn't given quite the
	same information (such as minutes remaining).

Recommendation:
	Preserve the kernel interface to the apm command.  On acpi
	systems, emulate it, keeping the current semantics.  It's
	simple and easy to use in scripts.  Keep envstat for more
	detailed information.

	Add support for suspend/resume scripts to powerd.  If we're
	going to support other ACPI states, have scripts for them, too.
	I'm not at all convinced that having a single lid_switch or
	acadapter script is correct, since the actions to be taken
	for close/open or disconnectd/connected are completely different.
	Add a configuration file to let some choices be controlled without
	hacking the code -- 'lidswitch_close: acpi3' versus
	'lidswitch_close: ignore' or some such.


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb