Date: Sun, 24 Feb 2013 11:54:39 -0800 From: matt <sendtomatt@gmail.com> To: freebsd-current@FreeBSD.org, freebsd-acpi <freebsd-acpi@freebsd.org> Subject: Fixing X220 Video The Right Way Message-ID: <512A6FFF.2060603@gmail.com>
next in thread | raw e-mail | index | archive | help
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? Thanks! Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512A6FFF.2060603>