[Intel-gfx] BACKLIGHT property for KMS case

Jesse Barnes jbarnes at virtuousgeek.org
Tue Aug 18 02:52:28 CEST 2009


On Tue, 18 Aug 2009 01:09:00 +0100
Matthew Garrett <mjg59 at srcf.ucam.org> wrote:

> On Mon, Aug 17, 2009 at 04:57:43PM -0700, Jesse Barnes wrote:
> 
> > +static int intel_get_backlight_brightness(struct backlight_device
> > *bd) +{
> > +	return bd->props.brightness;
> > +}
> 
> This is what's called when the user reads actual_brightness, so
> should actually read the hardware rather than just returning the
> cached value.

Ok.

> 
> > +	/* FIXME: check whether /sys/class/backlight is populated
> > or not */
> 
> Calling acpi_video_backlight_support() will give you this for acpi.
> It's more complicated for the platform driver case, since that'll
> typically be loaded after us. We're going to need some sort of event
> generated and then unregister the drm backlight in response.

Ok cool, maybe the backlight class needs a notifier?  (I think you
talked about this awhile back...)

> 
> > +	backlight_device->props.max_brightness =
> > +		dev_priv->blc_info.inverter_polarity ? 0 : 255;
> 
> max_brightness is the maximum value that can be given to the
> interface, rather than the value at which the brightness is greatest.
> The polarity inversion stuff needs to be handled in the set function.
> I guess there's also an argument over what we do about the minimum
> being greater than 0 

Oh duh, yeah I probably would have noticed that had I dug out a test
platform. ;)

> - we should probably scale to cope with that, otherwise UI is going
> to look weird.

The VBIOS handles it by making anything below the min brightness
equivalent to "lowest", which is probably fine.  Scaling would work too
though.  Also, the PWM write is wrong for a range of 0-255, so I need
some scaling anyway...

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list