Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jun 2004 23:14:28 +0100
From:      "Liam J. Foy" <liamfoy@sepulcrum.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        acpi@freebsd.org
Subject:   Re: apm problem
Message-ID:  <20040616231428.2b531dba.liamfoy@sepulcrum.org>
In-Reply-To: <20040616.153757.104034074.imp@bsdimp.com>
References:  <20040616215708.360cf786.liamfoy@sepulcrum.org> <20040616.150227.68884900.imp@bsdimp.com> <20040616221656.5e0febc0.liamfoy@sepulcrum.org> <20040616.153757.104034074.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jun 2004 15:37:57 -0600 (MDT)
"M. Warner Losh" <imp@bsdimp.com> wrote:

> In message: <20040616221656.5e0febc0.liamfoy@sepulcrum.org>
>             "Liam J. Foy" <liamfoy@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?

Ah, I got myself confused again hehe.

> 
> 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.
>

Right I understand now. So there are some minor things in the drivers
that need changing, and then change apm in accordance to this then.

You mentioned you had the driver patches, can you send these to me
in order for me to test them. Also to present them fully and see what
Nate and whoever think.

> : 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

That links seems to be bust man.

> 
> Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040616231428.2b531dba.liamfoy>