On Thu, 2009-01-08 at 20:43 +0800, Matthew Garrett wrote:
> On Thu, Jan 08, 2009 at 02:32:01PM +0800, Zhang Rui wrote:
> > > Why? These all seem to behave consistently, so I can't see any problem
> > > with us simply adding support for this varient.
> > the problem is that the ACPI backlight I/F and the platform I/F coexists
> > before commit c3d6de698c84efdbdd3781b7058bcc339ab43da8 applied, and the
> > platform I/F is preferred.
>
> For the machines you've looked at - we don't know if that's true for all
> hardware that behaves this way.
>
> > in bug 12249 and 12037,
> > 1. the first two elements in _BCL are NOT the backlight levels when the
> > platform is on AC or battery.
>
> We can detect that easily and adjust behaviour accordingly.
yes.
we can fake two elements when evaluating _BCL package.
>
> > 2. _BQC returns the index of the current brightness in _BCL package
> > rather than the value, which surely breaks the ACPI video driver.
>
> And again, we can handle that.
No, we can not handle this one.
For example,
Name (PCTG, Package (0x10)
{
0x64,
0x5A,
0x55,
0x50,
0x4B,
0x46,
0x41,
0x3C,
0x37,
0x32,
0x2D,
0x28,
0x23,
0x1E,
0x19,
0x14
})
_BQC returns 3 when the actual backlight level is 0x50.
We only know that the value returned by _BQC is invalid but we never
know the value is an index until we see the _AML code.
thanks,
rui
>
> > 2. every elements in the _BCL package is not a percentage of the maximum
> > brightness, which is also a violation of ACPI spec.
>
> This seems pretty irrelevant - nothing in the code depends on these
> being percentages.
>
> > yes, we can make the ACPI backlight control work by using customized
> > DSDT. But that's not the fix neither. I don't have any better ideas than
> > disable them.
>
> Just fix up video.c to handle these cases.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
