Date: Fri, 19 Oct 2012 10:53:19 -0400 From: John Baldwin <jhb@freebsd.org> To: Alberto Villa <avilla@freebsd.org> Cc: freebsd-acpi@freebsd.org, Juergen Lock <nox@jelal.kn-bremen.de>, mobile@freebsd.org Subject: Re: Dell acpi_video patch Message-ID: <201210191053.20041.jhb@freebsd.org> In-Reply-To: <CAJp7RHZcSWqsRHKjO-_iBj1Pb1thWR1fvan9mwtC5EaARz05qQ@mail.gmail.com> References: <20121005215316.GA38707@triton8.kn-bremen.de> <201210181716.31486.jhb@freebsd.org> <CAJp7RHZcSWqsRHKjO-_iBj1Pb1thWR1fvan9mwtC5EaARz05qQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, October 19, 2012 10:34:08 am Alberto Villa wrote:
> On Thu, Oct 18, 2012 at 11:16 PM, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210191053.20041.jhb>