Re: a backlight issue

[Thomas Renninger <trenn@suse.de>]

On Thursday 06 August 2009 14:55:52 Henrique de Moraes Holschuh wrote:
> On Wed, 05 Aug 2009, Thomas Renninger wrote:
> > If in KMS drivers backlight switching method is implemented
> > and can register for the generic backlight driver, it should always
> > be
> > disabled by default. Instead, KMS drivers should export a simple
> > "backlight_enable" file somewhere in sysfs. If userspace doesn't
> > find a sysfs backlight interface, it can do:
> > echo 1 >/sys/path_to_graphics_card/backlight_enable
> > and a backlight sysfs interface should pop up on success.
> 
> IMO, we already have an in-kernel selector of the backlight control
> method for mutually-exclusive backlight control strategies.
You mean the ACPI vs native driver detection?

> We should use that, and if it is complete/good enough to add the KMS
> scenario, improve it.
You mean if it is *not* complete/good enough?

KMS popping in as a third kernel backlight provider makes things really
complicated for the kernel to choose the right thing.
Getting this prio:
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915
solved in kernel automatically you need something like Rui/Yakui 
suggested:
  - Let KMS register first as I expect it will always initialize first
  - Let ACPI or platform driver unregister KMS backlight interface
    and take over
You never know when userspace plans to load the native drivers.
This complexity for a normally not needed fallback (ACPI or native 
drivers should be available) is complicated and error-prone.
This complexity should really be put to userspace where it's easy 
(three lines in bash) to solve, like I suggested above.

Maybe someone has another, easier idea to perfectly solve this 
automatically in kernel, I do not see it.

    Thomas