On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
The only problem with this is that not all oems use the internal backlight controller; systems that don't need to use the acpi methods.
That's why we expose the backlight type. Userspace should use the acpi or platform mechanism when available, with this being a last-ditch fallback.
Ah, gotcha.
On atombios systems there is a bit in the ATOM_FIRMWARE_CAPABILITY_ACCESS struct in the FirmwareInfo data table to determine whether the backlight is controlled by the GPU or some external mechanism. Combios may have something similar. If the backlight is controlled via the GPU, it can be adjusting using the atom OutputControl and TransmitterControl control tables depending on the GPU family. However, if the driver chooses to control the backlight itself, it needs to set the appropriate bit in the bios scratch regs to tell the firmware not to attempt to change the backlight itself.
If there's support for probing this more reliably then I'm all for that, but I'm not keen on taking over control if the BIOS has previous asserted it.
Agreed.
Alex