a backlight issue

a backlight issue

[yakui_zhao]

Hi, Len
    
    On some boxes there is neither generic ACPI backlight I/F nor
platform backlight I/F. That means that the backlight brightness can't
be changed by using sys backlight I/F. But the backlight brightness can
be changed by using the driver backlight I/F. For example: on the box
based on intel-integrated graphics card the backlight brightness can
also be changed by using the LBB register in pci device. 
    Can the graphics driver register the sys backlight I/F so that we
can change the backlight by using sys I/F? 
    
    If the graphics driver can also register the backlight I/F, it seems
that we can register three types of backlight I/F.
    a. generic ACPI backlight I/F. This is registered by acpi video
driver.
    b. platform backlight I/F. This is registered by the platform driver
    c. graphics backlight I/F. This can be registered by the graphics
driver.

    As there exist three types of backlight I/F, how can we make the
coordination among the three backlight I/F? In fact only one backlight
I/f is enough for user to change the brightness.

Rui provides a propose that use the backlight manager to choose the
appropriate the backlight I/F. 
    backlight manager only exports one single I/F to users, like:
----|
    |----brightness
    |----actual_brightness
    |----max_brightness
    |----...
    |----mode
and it supports multiple modes, e.g.
1. generic ---ACPI
2. platform---platform drivers
3. legacy-----i915

The sysfs backlight manager always chooses the mode with highest
priority (generic > platform > legacy), and call the respective
callbacks when backlight is changed.
For example, the backlight manager switches to the "generic" mode from
"legacy" mode automatically when ACPI video driver is loaded at runtime.
  
   How about the above propose?

 
BTW: now in the video driver only one of acpi generic backlight I/F and
platform backlight I/F is registered. That means that the acpi generic
backlight I/F is preferred if it exists. Of course we can switch to the
platform backlight I/F by adding the boot option of
"acpi_backlight=vendor".  In summary, the platform driver will check
whether the acpi generic backlight is supported before registering the
platform backlight I/F.


Thanks.

   

Re: a backlight issue

[Richard Purdie]

Hi,

On Thu, 2009-06-25 at 10:09 +0800, yakui_zhao wrote:
>     On some boxes there is neither generic ACPI backlight I/F nor
> platform backlight I/F. That means that the backlight brightness can't
> be changed by using sys backlight I/F. But the backlight brightness can
> be changed by using the driver backlight I/F. For example: on the box
> based on intel-integrated graphics card the backlight brightness can
> also be changed by using the LBB register in pci device. 
>     Can the graphics driver register the sys backlight I/F so that we
> can change the backlight by using sys I/F? 
>     
>     If the graphics driver can also register the backlight I/F, it seems
> that we can register three types of backlight I/F.
>     a. generic ACPI backlight I/F. This is registered by acpi video
> driver.
>     b. platform backlight I/F. This is registered by the platform driver
>     c. graphics backlight I/F. This can be registered by the graphics
> driver.
> 
>     As there exist three types of backlight I/F, how can we make the
> coordination among the three backlight I/F? In fact only one backlight
> I/f is enough for user to change the brightness.

I think in the short term you're right and that there needs to be
something acpi specific as a backlight arbitrator. This problem is quite
specific to acpi. Its worth thinking about the wider picture too though.

Taking a machine with say, three graphics cards in it, what should
happen? It should probably register one control for each screen with an
adjustable backlight so if each card was dual head you'd get 6 controls.

The key problem is knowing which backlight interface corresponds to
which driver+screen. If we had that information, exporting your three
interfaces above might be less of an issue as userspace could tell they
were for the same hardware. The kernel could pick the best interface
internally too, if it can tell they're for the same screen.

I suspect at this point we've gone far beyond the environment the sysfs
backlight interface was designed for and we'd be better off having the
backlight control in parallel with the other screen data which probably
runs through the DRM code.

Even then its not straightforward though as even just considering the
i915 driver, can it always use the i915 registers for the backlight or
does it sometimes have to make ACPI calls?

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre

Re: a backlight issue

[Thomas Renninger]

Hi,

while looking out for latest work in this area:
ACPI vs vendor vs KMS kernel backlight concurrency
I saw this one and even late, it looks like the appropriate mail to
answer as Yakui nicely describes the problem here...

On Thursday 25 June 2009 04:09:09 yakui_zhao wrote:
> Hi, Len
>     
>     On some boxes there is neither generic ACPI backlight I/F nor
> platform backlight I/F. That means that the backlight brightness can't
> be changed by using sys backlight I/F. But the backlight brightness can
> be changed by using the driver backlight I/F. For example: on the box
> based on intel-integrated graphics card the backlight brightness can
> also be changed by using the LBB register in pci device. 
>     Can the graphics driver register the sys backlight I/F so that we
> can change the backlight by using sys I/F? 
>     
>     If the graphics driver can also register the backlight I/F, it seems
> that we can register three types of backlight I/F.
>     a. generic ACPI backlight I/F. This is registered by acpi video
> driver.
>     b. platform backlight I/F. This is registered by the platform driver
>     c. graphics backlight I/F. This can be registered by the graphics
> driver.
> 
>     As there exist three types of backlight I/F, how can we make the
> coordination among the three backlight I/F? In fact only one backlight
> I/f is enough for user to change the brightness.
> 
> Rui provides a propose that use the backlight manager to choose the
> appropriate the backlight I/F. 
>     backlight manager only exports one single I/F to users, like:
> ----|
>     |----brightness
>     |----actual_brightness
>     |----max_brightness
>     |----...
>     |----mode
> and it supports multiple modes, e.g.
> 1. generic ---ACPI
> 2. platform---platform drivers
> 3. legacy-----i915
> 
> The sysfs backlight manager always chooses the mode with highest
> priority (generic > platform > legacy), and call the respective
> callbacks when backlight is changed.
> For example, the backlight manager switches to the "generic" mode from
> "legacy" mode automatically when ACPI video driver is loaded at runtime.
>   
>    How about the above propose?
If I understand this right every machine/BIOS does either provide:
  - generic ACPI funcs
  - vendor specific BIOS interface (served by oem-laptop.ko drivers)

It's just that for some vendors the latter is not implemented (due to lack
of specifications), is that right?

In any case, what about this solution:

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.

That would be similar to current xorg driver approach which do try
to take over if no backlight sysfs interface found.

     Thomas

BTW: Which mailinglist would be appropriate to reach KMS developers?

> BTW: now in the video driver only one of acpi generic backlight I/F and
> platform backlight I/F is registered. That means that the acpi generic
> backlight I/F is preferred if it exists. Of course we can switch to the
> platform backlight I/F by adding the boot option of
> "acpi_backlight=vendor".  In summary, the platform driver will check
> whether the acpi generic backlight is supported before registering the
> platform backlight I/F.
> 
> 
> Thanks.
> 
>    
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: a backlight issue

[Henrique de Moraes Holschuh]

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.  We should use that,
and if it is complete/good enough to add the KMS scenario, improve it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: a backlight issue

[Thomas Renninger]

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

Re: a backlight issue

[Henrique de Moraes Holschuh]

On Thu, 06 Aug 2009, Thomas Renninger wrote:
> 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?

Yes. 

> > 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?

Yes, sorry about that.

> 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.

Or unload them, which should be fully supported...

> This complexity for a normally not needed fallback (ACPI or native 
> drivers should be available) is complicated and error-prone.

More error-prone than OpRegion and the SMM mess from hell on most laptops?

> 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.

I do, but I don't know if it is a better solution.  In its "purest" form it
would be:  Teach the backlight core to have backlight domains and add a
backlight domain controler there.

You get KMS, platform drivers taking care of the main LVDS screen, and ACPI
on a single domain, let the kernel select ACPI by default or a different one
by command line, and let userspace change it through sysfs.

Drivers need some change to actually just register their backlight hooks
(plus hooks for "activate driver" and "deactivate driver", which are new)
with the backlight domain controller instead of a full backlight
device/class.  Other backlight drivers just register their own device using
the existing API.

Now, is that a better solution? I don't know.  But it is more user-friendly
than what we have now, and more powerful.  It is also more complex.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: a backlight issue

[Thomas Renninger]

On Thursday 06 August 2009 21:50:32 Henrique de Moraes Holschuh wrote:
> On Thu, 06 Aug 2009, Thomas Renninger wrote:
> > 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?
> 
> Yes. 
> 
> > > 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?
> 
> Yes, sorry about that.
> 
> > 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.
> 
> Or unload them, which should be fully supported...
> 
> > This complexity for a normally not needed fallback (ACPI or native 
> > drivers should be available) is complicated and error-prone.
> 
> More error-prone than OpRegion and the SMM mess from hell on most laptops?
> 
> > 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.
> 
> I do, but I don't know if it is a better solution.  In its "purest" form it
> would be:  Teach the backlight core to have backlight domains and add a
> backlight domain controler there.
> 
> You get KMS, platform drivers taking care of the main LVDS screen, and ACPI
> on a single domain, let the kernel select ACPI by default or a different one
> by command line, and let userspace change it through sysfs.
> 
> Drivers need some change to actually just register their backlight hooks
> (plus hooks for "activate driver" and "deactivate driver", which are new)
> with the backlight domain controller instead of a full backlight
> device/class.  Other backlight drivers just register their own device using
> the existing API.
> 
> Now, is that a better solution? I don't know.
I don't think so. It sounds like quite some code/complexity that needs to be
added for no functional enhancement.
This is all about solving the complexity in kernel or in userspace.
As it is *much* easier in userspace, I'd go that way.

> But it is more user-friendly than what we have now, and more powerful.
Why is it more powerful?
It's about solving the problem in kernel or in userspace, while userspace
might have additional info for choosing the right thing.
> It is also more complex.
Which is a very strong argument.

   Thomas

BTW: How would several graphics cards/monitors and switching between them
be handled currently or in future?
I once had such a machine and IIRC you ended up in double steps using generic
ACPI backlight funcs on both graphics cards. When I saw the two active ACPI
graphics devices I was happy that this was the only related defect and
silently ignored it :)

Re: a backlight issue

[Henrique de Moraes Holschuh]

On Fri, 07 Aug 2009, Thomas Renninger wrote:
> > I do, but I don't know if it is a better solution.  In its "purest" form it
> > would be:  Teach the backlight core to have backlight domains and add a
> > backlight domain controler there.
> > 
> > You get KMS, platform drivers taking care of the main LVDS screen, and ACPI
> > on a single domain, let the kernel select ACPI by default or a different one
> > by command line, and let userspace change it through sysfs.
> > 
> > Drivers need some change to actually just register their backlight hooks
> > (plus hooks for "activate driver" and "deactivate driver", which are new)
> > with the backlight domain controller instead of a full backlight
> > device/class.  Other backlight drivers just register their own device using
> > the existing API.
> > 
> > Now, is that a better solution? I don't know.
> I don't think so. It sounds like quite some code/complexity that needs to be
> added for no functional enhancement.
> This is all about solving the complexity in kernel or in userspace.
> As it is *much* easier in userspace, I'd go that way.

I might even agree with you, but I object that any interface that publishes
broken controls to userspace is good.  We should only expose stuff that
works, if KMS is busted in a given platform, no KMS controls should be
exposed, etc.  Publishing two controls that "work" but fight each other is
worse.

Besides, we *have* the notion of a main screen on almost every platform, and
exposing the main screen backlight control in a single way (and allowing the
user to select the backlight control strategy at runtime, after we did our
best to select the proper one by default) is much more user-fiendly and
neat.

What we have currently just barely cuts it, and wouldn't handle secondary
displays of any sort.

> > But it is more user-friendly than what we have now, and more powerful.
> Why is it more powerful?

See above.  One can override the control strategy at runtime to select any
backlight driver that could work (this assumes backlight drivers refuse to
install when the support they need isn't there, which is a safe assumption
as that's exactly what we try to do already).

> It's about solving the problem in kernel or in userspace, while userspace
> might have additional info for choosing the right thing.

It can still choose.  But now almost every userspace app has a single
control point.  Just like we do in the API used for kernel drivers, we
should aim for userspace ABIs that are easy to use right.

> > It is also more complex.
> Which is a very strong argument.

Not that strong, the added complexity is NOT too high, as backlight
_already_ operates based on context that is passed around as a pointer, and
on hooks that are inside this context structure.  Also, the propler layering
already exists.

I'd say it is a matter of a few hundred lines of code in the backlight
class, and the change of one function call on the backend drivers, to
register the backlight class on the proper domain.

> BTW: How would several graphics cards/monitors and switching between them
> be handled currently or in future?

The above "backlight domain controller" could take care of it with very
small changes to the design.

> I once had such a machine and IIRC you ended up in double steps using generic
> ACPI backlight funcs on both graphics cards. When I saw the two active ACPI
> graphics devices I was happy that this was the only related defect and
> silently ignored it :)

I do expect we will have some headaches on the firmware side of things, yes
:-)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh