On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
