Fixing X220 Video The Right Way
jhb at freebsd.org
Mon Feb 25 21:13:24 UTC 2013
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
> 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
> 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?
More information about the freebsd-current