Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Feb 2013 13:30:56 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-acpi@freebsd.org
Cc:        freebsd-current@freebsd.org
Subject:   Re: Fixing X220 Video The Right Way
Message-ID:  <201302251330.57034.jhb@freebsd.org>
In-Reply-To: <512A6FFF.2060603@gmail.com>
References:  <512A6FFF.2060603@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201302251330.57034.jhb>