From owner-freebsd-current@FreeBSD.ORG Tue Apr 3 00:40:07 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F61B106566C; Tue, 3 Apr 2012 00:40:07 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0F79D8FC08; Tue, 3 Apr 2012 00:40:06 +0000 (UTC) Received: by dadz14 with SMTP id z14so12847049dad.17 for ; Mon, 02 Apr 2012 17:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oRccqWrQmFzyKTJH7Z8fsVSYAxfirYcKK8oMfBcPs+E=; b=nXSeP22VeVPiKOl3b62GicvaOgD/5L6riIzUQWucUtIHAtfhDadeet9+YEhuQLmYPC T1L+UBwunrjbx55HOdBFKBh3SyTvuXy8D/vLRzSXohURrDOJhpL2DweAcueHad2wLRIW GYCmfg2okdLLU5Orudj06oYOZ9BuTgRsO7dNs2vU1BitrUB0q40+GKmIop9pw3Zy2X/H ARpAxkudebf16+/VixQgjsHkUh3tu5vj0Mo0n604T3oSKyo8DZmSt5Bqx2uf7477COxC Sv/vlbK3mC0AJCRaOxve7umb3LtfRxMN143pzwNdW4TAkp97YTsp/4zKn2QWk2SxtdvT wyIw== Received: by 10.68.136.41 with SMTP id px9mr24242105pbb.147.1333413606459; Mon, 02 Apr 2012 17:40:06 -0700 (PDT) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id q5sm10534856pbp.28.2012.04.02.17.40.03 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 17:40:04 -0700 (PDT) Message-ID: <4F7A46DB.4050701@gmail.com> Date: Mon, 02 Apr 2012 17:39:55 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120324 Thunderbird/10.0.3 MIME-Version: 1.0 To: Kevin Oberman References: <4E836C06.9070405@gmail.com> <4F56A2DA.2070703@gmail.com> <201204011214.38801.erichfreebsdlist@ovitrap.com> <4F789DD7.90604@mehnert.org> In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Hannes Mehnert , Erich Dollansky , freebsd-acpi@freebsd.org, =?windows-1251?Q?=CB=FE=E1=EE=EC=E8=F0_=C3=F0=E8=E3=EE=F0=EE=E2?= , freebsd-current@freebsd.org Subject: Re: x220 notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 00:40:07 -0000 On 04/01/12 22:49, Kevin Oberman wrote: > 2012/4/1 Любомир Григоров: >> Well I can't do the brightness switching. acpi_call port is installed, but: >> >> # kldload acpi_call >> kldload: can't load acpi_call: No such file or directory >> >> # acpi_call -p '\VBRC' -i 14 >> ioctl: Device not configured >> >> At least closing the lid turns off the monitor (not going to sleep), which >> is OK to conserve energy when not using. I would like to be able to change >> brightness, however. And have dimming. >> >> A minor problem, with the KMS Intel patch, when I log out of X (startx or >> xfce4), screen goes black. I don't know if this is acpi related. I typed >> reboot, and nothing happened. Using all.13.7-stable-9.patch with 9.0-STABLE. > # cd /usr/ports/sysutils/acpi_call&& make install clean > # rehash > # kld_load acpi_call > # acpi_call -p '\VBRC' -i 5 Exactly...I'd like to add it does require appropriate kernel sources, something I discovered as I'm currently testing off a 4gb USB...appropriately to current discussions, /usr/obj /usr/ports/distfiles /tmp /var/run are all tmpfs :) (we'll see how that goes too!). Some general followup/status of brightness: The hotkeys are working just fine out of the box, at least as far as they seem to adjust the brightness value seen by acpi_video, however as we know this doesn't actually seem to do much. There are a couple of branches in the ACPI code when brightness is called, one of which checks for integrated or discrete graphics (why I do not know as discrete is not an option). If \VIGD returns 1 (which I think means graphics are integrated) it talks to the \_SB.PCI0.LPC.EC.BRNS method, which doesn't seem to do anything for us. If \VIGD returns 0 (which I think would mean discrete graphics if available) it calls \VBRC The above method simply bypasses the VIGD switch and calls \VBRC directly. There are other ACPI methods which seem to be related, but I have yet to figure out what they mean...VBTC is one, and some _Q(X)(X) methods also seem to talk to the EC about the panel and brightness etc. It seems like we need to find how to make the EC be in charge of brightness instead of whatever VBRC is doing (it's an SMI call). I think brightness might just work fine...another note is the fact that acpi_video sees lcd0 as inactive...not sure why. Regarding acpi_ibm, it appears that it is also talking to the EC, which is why brightness cannot work there. Although for some reason, probably an alignment or address change, the fan speed appears corrupt after setting brightness via acpi_ibm, the fan controls still work fine in both manual and automatic as far as I can tell. It seems like if we can determine why the EC does not care for brightness settings, or isn't in charge of brightness, that we would be a small patch away from fixing acpi_ibm for this model. HOWEVER, it appears resume is now toast on CURRENT, since at least a few months, with or without Konstantin's patches. I'm not sure what's hanging, although setting suspend_beep=1 creates a horrible sound during the failing resume, which may indicate it's something fairly early in the resume, or even concurrent with "beeping". Even bounce does not work, and debugging is complicated by the lack of display. If anyone has anyone ideas for fixing resume on CURRENT, we'd be awful close to having a pretty damn nice laptop for FreeBSD. Matt