From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 7 16:58:06 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DE7E16A4FA; Wed, 7 Jul 2004 16:58:06 +0000 (GMT) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CC3E43D2D; Wed, 7 Jul 2004 16:58:05 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.224] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BiFkB-0006bX-00; Wed, 07 Jul 2004 18:58:03 +0200 Received: from [217.43.131.144] (helo=liamfoy.ath.cx) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BiFkB-0004rb-00; Wed, 07 Jul 2004 18:58:03 +0200 Date: Wed, 7 Jul 2004 17:56:22 +0100 From: "Liam J. Foy" To: Niki Denev Message-Id: <20040707175622.1d5c9e45.liamfoy@sepulcrum.org> In-Reply-To: References: <20040704204353.26b4496b.liamfoy@sepulcrum.org> <20040704.140429.37607877.imp@bsdimp.com> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org cc: hackers@FreeBSD.ORG Subject: Re: APM Patches X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2004 16:58:06 -0000 On Wed, 07 Jul 2004 19:42:35 +0300 Niki Denev wrote: > Niki Denev writes: > > > M. Warner Losh writes: > > > >> In message: <20040704204353.26b4496b.liamfoy@sepulcrum.org> > >> "Liam J. Foy" writes: > >> : Hey guys, > >> : > >> : Since it was decided (http://lists.freebsd.org/pipermail/freebsd-acpi/2004-June/000352.html) > >> : we are going to stick with apm -l producing -1 and not 255 which is stated in the handbook would one > >> : of you guys please commit: > >> : > >> : --- /usr/src/usr.sbin/apm/apm.8 Thu Jun 24 17:32:55 2004 > >> : +++ /liamfoy/apm.8 Thu Jun 24 17:32:27 2004 > >> : @@ -106,7 +106,7 @@ > >> : state respectively. > >> : .It Fl t > >> : Display the estimated remaining battery lifetime in seconds. If > >> : -it is unknown, 255 is displayed. > >> : +it is unknown, -1 is displayed. > >> : .It Fl Z > >> : Transition the system into standby mode. This mode uses less power than > >> : full power mode, but more than suspend mode. Some laptops support > >> : > >> : ---- > >> : > >> : Another patch I would like you guys to review is this. Currently apm -t will output > >> : 0 when it cannot find a valid rate or the full battery time(as the comment mentions). > >> : I think it should return -1 (unknown) to reflect an error, which is stated in the man page. > >> : It should not return 0 since we do not have 0 seconds left, we have an unknown value > >> : remaining. Either that or the man page it edited. I believe the following patch should > >> : be commited really. > >> : > >> : The patch is: > >> : > >> : --- /usr/src/sys/dev/acpica/acpi_cmbat.c Sun Jul 4 20:41:43 2004 > >> : +++ /home/liamfoy/acpi_cmbat.c Sun Jul 4 20:39:14 2004 > >> : @@ -536,7 +536,7 @@ > >> : bat[i]->min = (bat[i]->full_charge_time * bat[i]->cap) / 100; > >> : } else { > >> : /* Couldn't find valid rate and full battery time */ > >> : - bat[i]->min = 0; > >> : + bat[i]->min = -1; > >> : } > >> : total_min += bat[i]->min; > >> : total_cap += bat[i]->cap; > >> > >> I don't like this patch, since we use ->min later for math... > >> > >> Warner > > > > What about this ? > > > > --- sys/dev/acpica/acpi_cmbat.c.orig Mon Jul 5 15:15:28 2004 > > +++ sys/dev/acpica/acpi_cmbat.c Mon Jul 5 16:37:02 2004 > > @@ -655,7 +655,7 @@ > > battinfo->state = ACPI_BATT_STAT_NOT_PRESENT; > > } else { > > battinfo->cap = sc->cap; > > - battinfo->min = sc->min; > > + battinfo->min = sc->min ? sc->min : -1; > > battinfo->state = sc->bst.state; > > } > > > > > > > > -- > > Regards, > > Niki > > > So, is this Ok or not? :) > I'm running with this for a few days... no probs... > But also the only time that this is used probably is in apm(8) ? > It seems to not affect the math with ->min, by maybe it is not the cleanest > solution to this cosmetic problem? I personally like this patch. It does not effect the math and is much better than returning 0 which would indicate to the user he/she has not battery life left. I believe this should be changed. Depends on what the other guys think. > :) > > -- > Cheers, > Niki > > -- -Liam J. Foy http://liamfoy.kerneled.org "Love is like maths -- the idea is simple but can be quite complicated."