Re: [PATCH]: ACPI: Skip the first two elements in the _BCL package

[Len Brown <lenb@kernel.org>]

--
Len Brown, Intel Open Source Technology Center

On Wed, 4 Feb 2009, yakui_zhao wrote:

> On Tue, 2009-02-03 at 21:56 +0800, Thomas Renninger wrote:
> > On Monday 02 February 2009 04:33:41 yakui_zhao wrote:
> > > Subject: ACPI: Skip the first two elements in the _BCL package
> > > From: Zhao Yakui <yakui.zhao@intel.com>
> > >    According to the Spec the first two elements in the _BCL package won't
> > > be regarded as the available brightness level. The first is the brightness
> > > when full power is connected to the box(It means that the AC adapter is
> > > plugged). The second is the brightness level when the box is on battery.
> > >     If the first two elements are still used while finding the next
> > > brightness level, it will fall back to the lowest level when keeping on
> > > pressing hotkey. (On some boxes the brightness will be changed twice when
> > > hotkey is pressed once. One is in the ACPI video driver. The other is
> > > changed by sys I/F. In the ACPI video driver the first two elements will be
> > > used while changing the brightness. But the first two elements is skipped
> > > while using sys I/F. In such case there exists the inconsistency).
> > >     So he first two elements had better be skipped while showing the
> > > available brightness or finding the next brightness level.
> > I remember that Rui pointed me to a brightness level list, which included
> > a value in AC/battery values which was not in the rest of the list.
> > I expect simply ignoring battery/AC values is not right.

> Understand what you said. On some boxes the AC/battery level is not
> included by the rest brightness level. 
> From the spec the rest are treated as the list of levels OSPM can cycle
> through when user toggles(via keystroke) the brightness level of the
> display. 
>     If so, the first two elements should be excluded in the available
> brightness levels for hotkey.

maybe, maybe not.

Thomas,
Do we have an example?

I suspect that users will prever to be able to get to the ac/dc
brightness via hotkeys rather than having to generate an ac/dc
event to get to them...

>     And the first two elements are only used for that the power is
> switched between AC and battery.  
>     Right?
> > I posted a patch a while ago which did:
> >   - Go through the brightness values and extract from all (including
> >     AC and battery) unique values
> >   - Sort them
> >   - Create a with the data a new list.
> > Not sure whether this would have worked, but something is still
> > missing. Currently we do not use battery/AC values, but what if we want
> > do that, e.g. exporting them to userspace?

>      In current driver the BIOS flag of the _DOD input argument is zero,

you mean _DOS bit 2?

> which means that the BIOS will automatically control the brightness of
> level when the power is switched between AC and DC. 
>      
>      If we expect to change the brightness when switching power between
> AC and DC, it is necessary to export them to user space. 

per my previous e-mail, i would recommend that if we export them
to user-space, that we allow user-space to override them
and have the kernel simply consume them.  That way things
would work normall even if user-space is ignorant.

>      Can we still use the brightness sys I/F to change the brightness
> for AC/DC? The current sys I/F only exports the available brightness
> level that can be changed via hotkey. Maybe we should use another I/F to
> change the brightness for AC/DC.

yes, i think we'd need to extend the I/F.

But the real question is if we want to keep using _DOS=0
or if we want to try _DOS=4

If we stick with _DOS=0, then the user-space I/F thing is moot.
Howver, adding (potentially) missing ac/dc values to the toggle
list applies in both cases.

thanks,
-Len