From owner-cvs-src@FreeBSD.ORG Fri Mar 5 16:48:42 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0E8416A4CE; Fri, 5 Mar 2004 16:48:42 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF6643D2F; Fri, 5 Mar 2004 16:48:41 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.dons.net.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id i260mXQ9007019; Sat, 6 Mar 2004 11:18:34 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "M. Warner Losh" Date: Sat, 6 Mar 2004 11:18:32 +1030 User-Agent: KMail/1.6 References: <200403051335.55836.doconnor@gsoft.com.au> <20040305101907.P30482@root.org> <20040305.113544.68047468.imp@bsdimp.com> In-Reply-To: <20040305.113544.68047468.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403061118.32829.doconnor@gsoft.com.au> X-Spam-Score: -1.2 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: cvs-src@freebsd.org cc: takawata@init-main.com cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: nate@root.org Subject: Re: cvs commit: src/usr.sbin/acpi/acpiconf acpiconf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 00:48:43 -0000 On Sat, 6 Mar 2004 05:05, M. Warner Losh wrote: > I've just added the following, based on the other ioctl that you can > get battery info from: > > State: Present > Rate: 50000 mWh > Cap: 50000 mWh > Volt: 10.0 V > > Note: My battery/ACPI has a bug where 'RATE' and 'CAP' are always the > same number. I have a second bug where the CAP is listed as being > more than the last full capacity of the battery. This makes it very > hard to do estimates for remaining battery life, but I'm not sure what > can be done about it. I think you have to massage the data a fair bit to throw obvious outliers away. Also I believe most implementations produce totally bogus values during charging so you ignore rate when the battery is charging. > I see value in being able to get to the raw battery information from > whatever system is present. > > Now, having said that, I have no problems with there being a unified > interface also. I don't think that we can shoe-horn all systems into > providing all this information. I think it would be sensible to leave /dev/apm as is since a lot of applications already know how to talk to it.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5