Page MenuHomeFreeBSD

acpi_video: fall back to _BCL when _DOD matches no output
Needs ReviewPublic

Authored by seuros on Sun, Oct 18, 12:24 AM.
Referenced Files
F176662177: D60826.diff
Tue, Oct 20, 4:16 PM
F176552736: D60826.diff
Mon, Oct 19, 7:08 PM
Unknown Object (File)
Mon, Oct 19, 2:43 PM
Unknown Object (File)
Mon, Oct 19, 7:37 AM
Unknown Object (File)
Mon, Oct 19, 4:17 AM
Unknown Object (File)
Mon, Oct 19, 4:17 AM
Unknown Object (File)
Mon, Oct 19, 4:17 AM
Unknown Object (File)
Mon, Oct 19, 4:17 AM
Subscribers

Details

Summary

vid_enum_outputs() only registers a child whose _ADR appears in the
graphics controller's _DOD. _DOD is filled in from the graphics driver's
ACPI opregion on some platforms, so with no such driver attached it can
describe no device at all while the panel still implements _BCL, _BCM and
_BQC. The match then fails for every child and the machine is left with
no brightness control.

Fall back to registering the first child that implements _BCL when _DOD
matched nothing, so such a machine gets a working
hw.acpi.video.lcd0.brightness and the brightness keys that ride on it.

Test Plan

Tested on: HP, Gigabyte, Panasonic

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 78350
Build 75233: arc lint + arc unit

Event Timeline

vid_enum_outputs() only registers a child whose _ADR appears in the
graphics controller's _DOD. _DOD is filled in from the graphics driver's
ACPI opregion on some platforms, so with no such driver attached it can
describe no device at all while the panel still implements _BCL, _BCM and
_BQC. The match then fails for every child and the machine is left with
no brightness control.

This is a great technical description of the problem, but what's the punchline for the relevant end-user and/or average end-user: what does this change fix?

sys/dev/acpica/acpi_video.c
1109–1110

Does this message provide value to the average end-user? Where and how does the message get dumped out (it's not being prefixed with device_printf) (this looks like an existing "bug")?

1111–1113

Does this message provide value to the average end-user?
It seems like it should be hidden behind bootverbose or used in debug messages only.

...

This is a great technical description of the problem, but what's the punchline for the relevant end-user and/or average end-user: what does this change fix?

Here's an example (I should have included this in my prior comment):

This change allows platforms X{, Y, and Z} to control screen brightness via acpi_video(4).

This seems good to me -- I'd like for someone knowledgeable in ACPI to weigh in though before I go spelunking into the ACPI code in order to give a ship-it.