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.
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?
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"