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. > 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. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
