From owner-freebsd-current@FreeBSD.ORG Sun Feb 24 19:55:48 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C166B7CB; Sun, 24 Feb 2013 19:55:48 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7BA115; Sun, 24 Feb 2013 19:55:48 +0000 (UTC) Received: by mail-da0-f52.google.com with SMTP id x33so113119dad.39 for ; Sun, 24 Feb 2013 11:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=kBbTUmkhxW0iNvLGNGsW6/OC2bPt0MD7ohu7nkVh/KQ=; b=ilZQjhaLMv8K/jDC808PNPzGS4lSDksleFj4S7Au6PZCmsYrd2Cc8OBFG3BL4XycO6 GfUTGbGgbAo7wmJJuPeO3vDzTf/UNQwBbjgCoYX6a6+18qlY8lq8soHG9TtlWU4Askgc mfTRD5V6Wz/w6HPRFYFx0RMwmR1+3D+L2v/LcZOliuMdN0XEvUCqRFdyXExqAKave0vt 8Mw3Hj+R+FK28f6/lwcOg3whdCf0nhlffHjOzQM/RIo0bacitDTW8s0BDdbzvmdcljMC KrAJEf4Ewj0Eag/4tzVTeX3RjVqZgGDzQTuefxBLbX6J5bwoRtwq3moSrbkMIBslodSc 0znw== X-Received: by 10.68.227.9 with SMTP id rw9mr14456370pbc.185.1361735741921; Sun, 24 Feb 2013 11:55:41 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id dk1sm10074608pbc.15.2013.02.24.11.55.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Feb 2013 11:55:41 -0800 (PST) Message-ID: <512A6FFF.2060603@gmail.com> Date: Sun, 24 Feb 2013 11:54:39 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130202 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-acpi Subject: Fixing X220 Video The Right Way Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 24 Feb 2013 19:55:48 -0000 I am working on fixing acpi_video for X220. My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. So I've set out to fix acpi_video to work naturally, as it does in linux land. Background: Lenovo laptops boot in a mode where the brightness keys automagically work, under BIOS/EC control. This gets blown away (for us) shortly after Kernel attach. At this point, the acpi method \NBCF will return 0, which means acpi cannot control video brightness. Once we touch the _BCL method on the video output (even inactive ones), \NBCF returns 1 and will allow acpi control. You may remember that acpi_video records some brightness value that changes with keypresses, but does not work on X220. Current status: If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works via sysctl but not keypress (\NBCF = 1) If I leave that alone, but just redirect the brightness set function to \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works That is obviously a hack, but it indicates something is going on here. I think that get_acpi_handle() on the X220 vgapci is returning the wrong ACPI_HANDLE. Perhaps this is why the screen stays off when resume used to work? Obviously it can be fixed by hard coding this path into acpi_video, but I feel like that is definitely the wrong way. A tunable for an acpi_video override might be useful, but it still leaves potentially the wrong path in vgapci's IVARs. Is there a better place to "correct" the ACPI_PATH that gets stored in vgapci's ivar? Is there already a tunable I can use to fix this? Thanks! Matt