Re: Fixing X220 Video The Right Way

On Tuesday, February 26, 2013 9:32:33 pm matt wrote:
> 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.

If that is true, it's because your BIOS is lying.  Do you have a URL to your 
ASL lying around already?

-- 
John Baldwin