Messages in this thread | | | Date | Wed, 8 Sep 2010 13:04:31 -0400 | Subject | Re: [PATCH] radeon: Expose backlight class device for legacy LVDS encoder | From | Alex Deucher <> |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |