Date: Tue, 26 Feb 2013 18:32:33 -0800 From: matt <sendtomatt@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org>, freebsd-current@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Fixing X220 Video The Right Way Message-ID: <512D7041.50608@gmail.com> In-Reply-To: <201302261346.46197.jhb@freebsd.org> References: <512A6FFF.2060603@gmail.com> <CAJ-VmomuKk-4yHbX3dmy5Hs=%2BEyEh7ytAdB_QBABEMG6XUWaOA@mail.gmail.com> <512C380D.5030506@gmail.com> <201302261346.46197.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/26/13 10:46, John Baldwin wrote: > On Monday, February 25, 2013 11:20:29 pm matt wrote: >> On 02/25/13 18:33, Adrian Chadd wrote: >>> [101232] acpi_video0: <ACPI video extension> on vgapci0 >>> found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 >>> >>> And what do I do with acpi_get_handle ? >>> >>> >>> >>> >> I threw printfs into acpi_video, not sure if that would work for both >> vgapci or not. >> I'm not sure if I wiped out my debug patches yet, I may have a patch. >> Basically the idea is to figure out which paths in the DSDT are getting >> attached to the vgapci devices. > devinfo -v already tells you that. > > For example: > > nexus0 > acpi0 > pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 > pci0 > hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 > subdevice=0x2010 class=0x060000 at slot=0 function=0 > pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 > subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 > pci1 > vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 > subdevice=0xc973 class=0x030000 at slot=0 function=0 > > (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the > vgapci device, but you can see how it displays the handle for other PCI > devices like pcib1 which are in the ACPI namespace.) > >> It seems like we could either try to find these paths on affected >> models, or have a tunable override for acpi_video. > Note that the Linux discussion you posted seems a bit off. The _ADR is > not supposed to be unique to the entire system. For PCI devices, _ADR > contains the PCI device (slot) and function (as slot << 16 | func), and > the domain:bus portion of the address is implied by the parent PCI bus > device in the ACPI namespace. Thus, the specific handle assigned by ACPI > is for the exact PCI location of the requisite vgapci device. If your > BIOS lies it is hard for us to do anything useful, at least automatically. > > Do the other devices in your system that have _DOD or _DOS methods show > up as unknown ACPI devices in your devinfo -v output? It's not in devinfo at all for me, Adrian may have a different situation. So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID Only _SB.PCI0.VID is represented in devinfo -rv. As far as I know, PEG is not a "real" device, but an abstraction, possibly for Optimus use. It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) This is potentially the broken bios part of things. I think I have multiple ACPI devices for a single physical device, and pci is attaching the wrong ACPI device to the physical device in an ivar. acpi_video happily uses this ivar to attempt to control video brightness. I could be entirely wrong on that, all I do know is that the working handle doesn't get used and the useless handle does. Matt Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512D7041.50608>