[Intel-gfx] BACKLIGHT property for KMS case

[ykzhao]

On Tue, 2009-08-18 at 10:20 +0800, Jesse Barnes wrote:
> 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...
The two boxes are based on the g4x platform. And the acpi backlight
interface can work well on one box. And there is no acpi backlight
interface on another box.
In fact I check the vbios dump on several other boxes and the length of backlight section is 21. 
So IMO the backlight section is not reliable and we can't use it to parse the backlight interface.
> 
> > 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.
But this interface can be found in /sys/class/backlight/*. Maybe it is
used to adjust the brightness by user. In such case too many brightness
levels are exposed to user.
> 
> > 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...
How can we modify the legacy registers in the two different paths if we
expose only one interface to user space?
Thanks
>