From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 16 22:14:56 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 F018216A4CE for ; Wed, 16 Jun 2004 22:14:56 +0000 (GMT) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F11143D1F for ; Wed, 16 Jun 2004 22:14:56 +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 1Baify-0006oU-00; Thu, 17 Jun 2004 00:14:34 +0200 Received: from [81.154.134.17] (helo=Anarion) by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1) id 1Baifx-0004Br-00; Thu, 17 Jun 2004 00:14:34 +0200 Date: Wed, 16 Jun 2004 23:14:28 +0100 From: "Liam J. Foy" To: "M. Warner Losh" 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> Organization: None X-Mailer: Sylpheed version 0.9.9 (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 Subject: Re: apm problem 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, 16 Jun 2004 22:14:57 -0000 On Wed, 16 Jun 2004 15:37:57 -0600 (MDT) "M. Warner Losh" wrote: > In message: <20040616221656.5e0febc0.liamfoy@sepulcrum.org> > "Liam J. Foy" 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