Re: Fixing X220 Video The Right Way

On Sunday, February 24, 2013 2:54:39 pm matt wrote:
> I am working on fixing acpi_video for X220.
> 
> My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty.
> So I've set out to fix acpi_video to work naturally, as it does in linux
> land.
> 
> Background:
> Lenovo laptops boot in a mode where the brightness keys automagically
> work, under BIOS/EC control.
> This gets blown away (for us) shortly after Kernel attach.
> 
> At this point, the acpi method \NBCF will return 0, which means acpi
> cannot control video brightness.
> 
> Once we touch the _BCL method on the video output (even inactive ones),
> \NBCF returns 1 and will allow acpi control.
> 
> You may remember that acpi_video records some brightness value that
> changes with keypresses, but does not work on X220.
> 
> Current status:
> If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works
> via sysctl but not keypress (\NBCF = 1)
> 
> If I leave that alone, but just redirect the brightness set function to
> \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works
> 
> That is obviously a hack, but it indicates something is going on here.
> 
> I think that get_acpi_handle() on the X220 vgapci is returning the wrong
> ACPI_HANDLE.
> Perhaps this is why the screen stays off when resume used to work?
> 
> Obviously it can be fixed by hard coding this path into acpi_video, but
> I feel like that is definitely the wrong way.
> A tunable for an acpi_video override might be useful, but it still
> leaves potentially the wrong path in vgapci's IVARs.
> 
> Is there a better place to "correct" the ACPI_PATH that gets stored in
> vgapci's ivar? Is there already a tunable I can use to fix this?

vgapci's ivar is set by the PCI address.  Do you have multiple vgapci devices?

-- 
John Baldwin