[Intel-gfx] BACKLIGHT property for KMS case

[Jesse Barnes]

On Tue, 18 Aug 2009 10:00:43 +0800
ykzhao <yakui.zhao at intel.com> wrote:

> On Tue, 2009-08-18 at 07:57 +0800, Jesse Barnes wrote:
> > On Mon, 17 Aug 2009 21:32:45 +0100
> > Matthew Garrett <mjg59 at srcf.ucam.org> wrote:
> > 
> > > On Mon, Aug 17, 2009 at 10:09:09AM -0700, Greg KH wrote:
> > > > On Mon, Aug 17, 2009 at 06:52:37PM +0200, Matthias Hopf wrote:
> > > 
> > > > So you want 2 different drivers controlling the same hardware?
> > > > That's a recipe for disaster :)
> > > 
> > > samsung-laptop (in its current form) is controlling the same
> > > hardware that i915 is already. Implementing it properly involves
> > > parsing the BIOS tables to tell you the minimum acceptable value
> > > (driving the backlight controller outside its specced range
> > > probably isn't a good idea) and potentially also touching the
> > > MMIO backlight registers. I'd really recommend not merging this
> > > as a separate driver. It's slightly more work to do it in the drm
> > > driver, but it's also the only way to do it properly.
> > 
> > Yeah, I mentioned that in another thread.  This patch (untested)
> > illustrates the sort of thing I'd rather see.  It integrates the
> > backlight detection and sysfs support into the i915 driver (as part
> > of the existing LVDS code), which should make it more reliable in
> > the face of the various machine types.  It still needs to detect
> > whether a backlight device has been registered already, and the i2c
> > code still needs to be written (should be easy, but I'm not sure if
> > I have a test platform for it).
> IMO it is unnecessary to get such a complex interface. In fact this
> interface is useful only when there is neither acpi generic nor
> platform driver interface.

The interface is simple: it's just a /sys/class/backlight dir just like
with ACPI or platform drivers.  Yes, it's only useful where one of
those is missing (and therefore mostly old machines) but we should
still try to get it right...

> At the same time the backlight section in VBIOS is not reliable. For
> example: On one box the length of backlight section is 21 and the
> lvds_panel_type is 13. In such case it is beyond the backlight
> section.

On recent platforms or old ones?  If the platform already supports ACPI
or a platform method, then the VBIOS data can be wrong and things will
still work...

> Another issue is that the brightness level is so big when the
> native/combo mode is used. For example: 0-65535 for the native control
> method. The user will be confused by so many brightness levels.

User won't see them directly, so there should be no confusion.
Brightness is generally exposed as a slider or a series of steps with
the brightness keys.

> How about using the legacy control method?

Yes, we have to modify the legacy registers in some cases.  But
modifying them exclusively would be a problem...

-- 
Jesse Barnes, Intel Open Source Technology Center