on 06/07/2011 00:49 Vitaly Magerya said the following:
> Andriy Gapon <a...@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" 
 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 
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 
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 
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 
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
freebsd-acpi@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to