From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 10 13:06:26 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 CE74816A41F; Tue, 10 Jan 2006 13:06:26 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2706B43D49; Tue, 10 Jan 2006 13:06:25 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1EwJCi-0000i6-00; Tue, 10 Jan 2006 14:06:24 +0100 Date: Tue, 10 Jan 2006 14:06:24 +0100 To: Ariff Abdullah , Nate Lawson Message-ID: <20060110130624.GD32102@poupinou.org> References: <20060103155509.GE13887@poupinou.org> <20060103185047.GH13887@poupinou.org> <20060104161842.GK13887@poupinou.org> <20060105005441.029835c1.ariff@FreeBSD.org> <43C2C6AB.5060605@root.org> <20060110050828.100b026a.ariff@FreeBSD.org> <20060110094712.GB32102@poupinou.org> <20060110181931.57fd0d39.ariff@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060110181931.57fd0d39.ariff@FreeBSD.org> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-acpi@FreeBSD.org, lists@stringsutils.com Subject: Re: No APM yet for AMD? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2006 13:06:27 -0000 On Tue, Jan 10, 2006 at 06:19:31PM +0800, Ariff Abdullah wrote: > On Tue, 10 Jan 2006 10:47:12 +0100 > Bruno Ducrot wrote: > > > There are no functional changes at all. It simply trying to be > > > more verbose (and forgiving), in case the ioctl did not return > > > advance information (such as remaining time, so on) which I > > > believe few ACPI bioses incapable of providing such info. In this > > > case, it trying to calculate the percentage of remining battery > > > capacity based on Last Full Capacity, which current acpiconf > > > ignore. > > > > > > # acpiconf -i 0 (without patch) > > > Design capacity: 6000 mAh > > > Last full capacity: 4000 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 14800 mV > > > Capacity (warn): 207 mAh > > > Capacity (low): 125 mAh > > > Low/warn granularity: 10 mAh > > > Warn/full granularity: 25 mAh > > > Model number: JM-6 > > > Serial number: 0046713127 > > > Type: LION > > > OEM info: Hewlett-Packard > > > State: not present > > > ^^^^^^^^^^^ > > > Voltage: unknown > > > > > > # acpiconf -i 0 (patched) > > > Design capacity: 6000 mAh > > > Last full capacity: 4000 mAh > > > Technology: secondary (rechargeable) > > > Design voltage: 14800 mV > > > Capacity (warn): 207 mAh > > > Capacity (low): 125 mAh > > > Low/warn granularity: 10 mAh > > > Warn/full granularity: 25 mAh > > > Model number: JM-6 > > > Serial number: 0046713127 > > > Type: LION > > > OEM info: Hewlett-Packard > > > State: high > > > ^^^^ > > > Present rate: unknown > > > Remaining capacity: 100% > > > ^^^^ > > > > Well, I would much prefer the remaining capacity still being > > unknown in that case then. > > > Why? This is not because of buggy acpi/dst bios, this is the > limitation of the bios itself by not having a feature to calculate > remaining time, plus the inability of present acpiconf(8) that simply > ignore the fact there is other possible way to calculate it although > not as precise as "minutes left". On top of that, the output of sysctl > hw.acpi.battery only applicable for bioses with "remaining time" > feature. Note that this is nothing new, Windows and Linux does display > remaining capacity in terms of percentage remaining if it cannot > acquire the accurate remaining time. Oops, I miss read your patch. I'm pretty ok with it, but I would like that you verify bif.lfcap is not 0 before the printf. We can not assume the OEM did it right even if it's very unlikely the last full capacity will be zero :) > # acpiconf -i 0 > Design capacity: 6000 mAh > Last full capacity: 4000 mAh > Technology: secondary (rechargeable) > Design voltage: 14800 mV > Capacity (warn): 207 mAh > Capacity (low): 125 mAh > Low/warn granularity: 10 mAh > Warn/full granularity: 25 mAh > Model number: JM-6 > Serial number: 0046713127 > Type: LION > OEM info: Hewlett-Packard > State: discharging > ^^^^^^^^^^^ > Present rate: unknown > Remaining capacity: 91% > ^^^ > Voltage: unknown > AC line: off-line > # sysctl hw.acpi.battery > hw.acpi.battery.life: -1 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 7 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > > > At least I know when to plug in back my ac connector :) > > Well, I don't know much about FreeBSD ACPI. But at least, this > patch / fix / workaround does indeed help me and few others. > > Of course if the dsdt can be hacked to give accurate remaining battery > time, that would be better :) There is no way to get the remaining time from control method batteries other than by computing it. At this time, it's derived from the present rate and the remaining capacity IIRC. The smart battery is able to give it via smbus (time_to_empty and time_to_full). I think we may want to rewrite the acpi_battery driver and the low levels acpi_cmbat and acpi_smbat to handle all of those situations. (removed freebsd-amd64 btw) -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.