[Intel-gfx] Legacy backlight control with KMS and BACKLIGHT property

ykzhao yakui.zhao at intel.com
Mon Aug 17 11:05:08 CEST 2009


On Mon, 2009-08-17 at 15:56 +0800, Zhenyu Wang wrote:
> On 2009.08.14 19:54:05 +0200, Matthias Hopf wrote:
> > What we're supposing is
> > 
> > - a kernel driver for the /sys/class/backlight/ api for the legacy method
> 
> yeah, I think /sys/class/backlight/ should be the only backlight interface for 
> any user space apps or X RandR property creation. So we need to add backlight
> device inside i915 KMS driver, when !acpi_video_backlight_support().
the function of acpi_video_backlight_support only checks whether the
generic acpi video method is supported.(_BCL/_BCM acpi video extension
method).

And we should also check whether the platform driver will register the
backlight interface.

Only when there is neither generic acpi video nor platform backlight
interface, we will register the i915 backlight interface. 
In such case the dependency is too strict. And it is not easy to handle
the three interface.
> 
> Current KMS driver like LVDS only do PWM operation, maybe combo will be better
> if it's supposed to be, Jesse?
> 
> > - support in the driver to actually open this one (trivial)
> 
> yeah.
> 
> > - support for the BACKLIGHT property in KMS case, *only* using the
> >   kernel api method for now (will need some abstraction)
> 
> Current x-v-i driver in KMS could setup any property for all connectors,
> like attached testing patch which will hook the property up. But if we just go 
> with opening /sys/class/backlight/ in xorg driver, we simply don't need it...
If the backlight is controlled by using the /sys/class/backlight/*
interface, then we can hook up this interface in video driver so that
the xrandr can adjust the brightness.

Thanks.
> 
> So for X BACKLIGHT property creation, we'll have a checklist for acpi_video,
> platform_driver, and new backlight device maybe like 'intel_lvds'.
> 




More information about the Intel-gfx mailing list