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

[yakui_zhao <yakui.zhao@intel.com>]

On Wed, 2009-02-04 at 12:25 +0800, Len Brown wrote:
> 
> --
> 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?
Name (PBCL, Package (0x07)
                        {
                            0x50,
                            0x32,
                            0x14,
                            0x28,
                            0x3C,
                            0x50,
                            0x64
                        })
Method (_BCL, 0, NotSerialized)
 {
       Return (PBCL)
}
> the above info is found in the bug 11166
Of course there exist the same issue on the bug 12037/12450.

> 
> 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?
Yes. 
> 
> > 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.
> 
It will be harmless that the brightness is changed even when the
_DOS=0(Of course it will be redundant). 
> 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
>