apm problem

[M. Warner Losh]

In message: <20040616221656.5e0febc0.liamfoy at sepulcrum.org>
            "Liam J. Foy" <liamfoy at sepulcrum.org> writes: Yeah. This
: has been causing utter confusion, needs to be fixed once and for
: all. The man page stages 255 is returned also, except for
: ai_batt_time (-t) since it is an int. To finalise, APM returns -1
: for UNKNOWN and so we should test for -1 or 0xff?

The APM BIOS returns 0xff in some cases to indicate unknown.
FreeBSD's apm driver shuffles these values into u_int as unsigned.  So
the right thing to do is to check against 0xff for those fields.

There's one case where FreeBSD's apm driver stores -1 in a u_int.  I
just chagned that one case to store the unsigned number 0xfffffffful
into that field.  For that field, and that field only (ai_batteries),
we need to check against 0xffffffff.  All others are properly checking
against 255 (0xff).  The BIOS call that returns values for
ai_batteries doesn't have an unknown option (see section 4.6.17).
Many others do, but this one doesn't.

This is arguably a bug in FreeBSD's api, but at this late date, it
would be painful to change it.  If we didn't have third party
applications, then it would be easy, but alas there are several that
use this interface.

: I recently lost a small disk with a specification on. I could of
: sworn it said 0xffffffff. Maybe Nate and I had the same document. Do
: you have a specification you could possibly email me privately with
: it?

It doesn't.  And even if it did, the FreeBSD apm driver masks off the
upper bits.  You can download the specs from
	http://www.microsoft.com/hwdev/busbios/apm_12.htm

Warner