Date: Wed, 06 Jul 2011 17:06:38 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Vitaly Magerya <vmagerya@gmail.com> Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook Message-ID: <4E146BEE.1060404@FreeBSD.org> In-Reply-To: <CAL409KyX0jDd9U=7GExvyPR1cDxPwsMHm2b%2B1Tvmijhpg0iWDQ@mail.gmail.com> References: <BANLkTim%2B1UwquMJ32WP8wZBGkYxPv78MLA@mail.gmail.com> <4E05EB91.9090509@FreeBSD.org> <BANLkTi=dyNx=TjyEqYMhSkRtddjVA4nAtw@mail.gmail.com> <4E0862A0.7060405@FreeBSD.org> <BANLkTikmVUtLyANBSqYb%2BL-xkwQ4Zo51Eg@mail.gmail.com> <4E09BADF.7050702@FreeBSD.org> <BANLkTin_%2BZH%2Bo7rdR9ijHMtrXcSdH9ZSdQ@mail.gmail.com> <4E0A41C8.3000904@FreeBSD.org> <BANLkTikwgy%2BKuA5E5zXQKGT-eyV35YAVag@mail.gmail.com> <4E0CE158.6030804@FreeBSD.org> <BANLkTinRY-h%2BkpXtwWJ_L86qVRdoynFSdg@mail.gmail.com> <4E0DB58F.4070906@FreeBSD.org> <CAL409Kw=rUnm9D56KvYiFWiU-bp59KqKnPcUXL38rZsW_Qh8AQ@mail.gmail.com> <4E130154.9080809@FreeBSD.org> <CAL409KyX0jDd9U=7GExvyPR1cDxPwsMHm2b%2B1Tvmijhpg0iWDQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
on 06/07/2011 00:49 Vitaly Magerya said the following:
> Andriy Gapon <avg@freebsd.org> wrote:
>>> I don't have acpi_video loaded (it's not loaded by default). If I
>>> do load it, VDRV indeed becomes 1 (brightness controls that acpi_video
>>> exposes don't work though; this appears to be a known problem with
>>> Samsung laptops).
>>
>> This might warrant a separate investigation and a PR if we don't have one already.
>> Not sure if I could be of help with it, though.
>
> From what I heard this isn't a problem with FreeBSD ACPI code, it's
> a problem with Samsung firmware. AFAIK to get brightness controls
> working on Windows you need to setup Samsung software that uses
> undocument BIOS interface for it's function.
>
> Linux has what appears to be a reverse-engineered driver [1] that
> does the same. Someone (probably me) needs to port it.
Maybe, maybe not... Can you please verify which driver Linux actually uses on
your system?
I see that ACPI does export all the necessary methods for brightness controls,
although there seem to be some strangeness in the code (annotations are mine):
Method (_BCL, 0, NotSerialized)
{
Or (VDRV, 0x01, VDRV)
Return (Package (0x08)
{
0x64, // 100 // level when machine has full power
0x05, // 5 // level when machine is on batteries
// other supported levels:
0x0F, // 15
0x18, // 24
0x1E, // 30
0x2D, // 45
0x3C, // 50
0x50 // 80
})
}
First, please note that the default levels are not among "other supported" levels.
They are not required to be, but frequently they are.
Method (_BCM, 1, NotSerialized)
{
// Local0 = Arg0 % 10;
// Local1 = Arg0 / 10;
Divide (Arg0, 0x0A, Local0, Local1)
If (LEqual (Local0, 0x00))
{
BRTW (Arg0)
}
}
Note here that _BCM would accept only levels that multiple of 10, but levels
listed by _BCL are not all multiples of 10. Bug?
Method (_BQC, 0, NotSerialized)
{
// Local0 = Arg0 % 10;
// Local1 = Arg0 / 10;
Divide (BRTL, 0x0A, Local0, Local1)
If (LEqual (Local0, 0x00))
{
Return (BRTL)
}
Again, _BQC would return a current level value (in BRTL) only if it is a multiple
of 10. There is no return statement for the other case, I assume that zero is
returned in that case.
So I can see how this behavior can easily confuse our acpi_video driver.
I see that Linux acpi video driver has some quirks in it, but not sure if it is
able to handle this kind of issues. I would doubt that.
Maybe you would feel adventurous enough to experiment with hacking your DSDT some
more. For a start I would just try to remove that level % 10 == 0 check.
But wait... those acpi video methods are defined in Device DD04, but you reported
that NDID=2 in GNVS, so only devices DD01 and DD02 should be reported via _DOD.
But then DID2 == DID4, so DD02 and DD04 have the same address and acpi_video uses
DD04 as well. And here I become totally confused as I haven't expected two
devices to report the same address.
But enough for me to talk about this :)
--
Andriy Gapon
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E146BEE.1060404>