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 MattReceived on Wed Feb 27 2013 - 01:33:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:35 UTC