From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 6 14:06:42 2011 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 610F51065673 for ; Wed, 6 Jul 2011 14:06:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A72478FC0C for ; Wed, 6 Jul 2011 14:06:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00622; Wed, 06 Jul 2011 17:06:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E146BEE.1060404@FreeBSD.org> Date: Wed, 06 Jul 2011 17:06:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 14:06:42 -0000 on 06/07/2011 00:49 Vitaly Magerya said the following: > Andriy Gapon 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