Skip site navigation (1)Skip section navigation (2)
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>