From owner-freebsd-mobile@FreeBSD.ORG Fri Oct 19 15:32:33 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 20EC7D0; Fri, 19 Oct 2012 15:32:33 +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 E59A78FC17; Fri, 19 Oct 2012 15:32:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 518E8B98E; Fri, 19 Oct 2012 11:32:32 -0400 (EDT) From: John Baldwin To: Alberto Villa Subject: Re: Dell acpi_video patch Date: Fri, 19 Oct 2012 10:53:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210181716.31486.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201210191053.20041.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Oct 2012 11:32:32 -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: Fri, 19 Oct 2012 15:32:33 -0000 On Friday, October 19, 2012 10:34:08 am Alberto Villa wrote: > On Thu, Oct 18, 2012 at 11:16 PM, John Baldwin wrote: > > Ok, can you possibly hack acpi_video to output the values returned _DOD= (in > > hex) and the _ADR values (in hex) of your outputs? >=20 > I've read the ACPI spec and checked my dump, now I see what you mean. > Nonetheless, I think you have confused the _STD bit with the _BIOS > one: >=20 > 0x00010100, > 0x00010118, > 0x00010121 >=20 > So acpi_video.c behaves just as expected. By the way, the GFX device > has a _DOD method too, which returns 0x0400 (an LCD device)... I'm looking at section B.4.2 in the 3.0b spec, it has a sample _DOD of: Method (_DOD, 0) { Return ( Package() { 0x00000110, // Primary LCD panel, not detectable by BIOS 0x80000100, // CRT type display, not detectable by BIOS 0x80000220, // TV type display, not detectable by the BIOS 0x80000411, // Secondary LCD panel, not detectable by BIOS } ) } The description of bit 31 is quite clear: Device ID Scheme 31 1 =E2=80=93 Uses the bit-field definitions above (bits 15:0) 0 =E2=80=93 Other scheme, contact the Video Chip Vendor Then there is table B-3: Table B-3: Example Device Ids Bits Definition 0x000xyyyy Bit 31 =3D 0. Other proprietary scheme - 0x110 Device ID is an e= xception. (See Note 3) 0x00000110 Integrated LCD Panel #1 using a common, backwards compatible ID 0x80000100 Integrated VGA CRT or VESA compatible Monitor #1 on Port0 0x80000240 Integrated TV #1 on Port4 0x80000410 Integrated Internal LCD Panel #1 on Port1 0x80000421 LVDS Panel #2 Dual-Link using Port2 & 3. (See Note 4) 0x80000131 VGA CRT or VESA compatible Monitor #2 on Port3 0x80000121 Dual-Link VGA CRT or VESA compatible Monitor #2 using Port2 & 3.= (See Note 4.) 0x80000320 DVI Monitor #1 on Port2 (shares Port2 with a Dual-Function DVI/T= V Encoder). (See Note 5) 0x80000331 DVI Monitor #2 on Port3 0x80000330 Dual-Link DVI Monitor #1 using Port2 & 3 0x80000231 TV #2 on Port2 (shares Port2 with a Dual-Function DVI/TV Encoder= ). (See Note 5) Notes: 3. When Bit 31 is 0, no assumptions can be made on which ID will be used for any particular display type. Contact the Video Chip vendor for details of the ID scheme employed. Looking back at earlier ACPI specs (1.0b and 2.0c), they did not mention bit 31 at all (well, it was required to be zero). Their examples are different= as well, but they don't define any meaning to the low bits, so I think we are correct in calling all of them plain outputs. Specifically, the "Display Type" bitfield (Bits 8:11) are undefined in the earlier specs, and 3.0b only claims they are defined if bit 31 is set. =2D-=20 John Baldwin