No APM yet for AMD?

[Bruno Ducrot]

On Tue, Jan 10, 2006 at 06:19:31PM +0800, Ariff Abdullah wrote:
> On Tue, 10 Jan 2006 10:47:12 +0100
> Bruno Ducrot <ducrot at poupinou.org> 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.