From owner-freebsd-mobile@FreeBSD.ORG Sat Oct 20 12:53:05 2012 Return-Path: Delivered-To: mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25524EB0; Sat, 20 Oct 2012 12:53:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB6538FC17; Sat, 20 Oct 2012 12:53:04 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4845FB93B; Sat, 20 Oct 2012 08:53:04 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Sat, 20 Oct 2012 08:40:48 -0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210191313.14246.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210200840.48613.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sat, 20 Oct 2012 08:53:04 -0400 (EDT) Cc: freebsd-acpi@freebsd.org, Juergen Lock , mobile@freebsd.org X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 12:53:05 -0000 On Friday, October 19, 2012 06:21:00 PM Alberto Villa wrote: > On Fri, Oct 19, 2012 at 7:13 PM, John Baldwin wrote: > > Yes, unless bit 31 is set, we can't know anything about bits 0-15 except > > that they are "unique". Specifically, we can't look at the "Display > > Type" bits to determine if an output device is a CRT vs LCD vs TV, etc. > > You can only do that if bit 31 is set. > > I know, I was saying that you probably confused bit 31 with bit 16, so > the patch you proposed (about bit 31 being set in _DOD but not in > _ADR) was not correct. ;) Oh, no, I hadn't been able to tell from your ASL that bit 16 was set (it's not that easy to guess as it computes the ID's dynamically at runtime. I was merely guessing that since I had changed the matching logic to look at bit 31 that that was the cause, but it wasn't the matching logic that was different (comparing _ADR to _DOD), but the logic that parsed _DOD is what treated your laptop differently. -- John Baldwin