Fixing X220 Video The Right Way
sendtomatt at gmail.com
Wed Feb 27 02:33:46 UTC 2013
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:
>>>  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:
> pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.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
> 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.
More information about the freebsd-current