From owner-freebsd-current@FreeBSD.ORG Mon Feb 9 16:33:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EBC5980; Mon, 9 Feb 2015 16:33:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47576A42; Mon, 9 Feb 2015 16:33:42 +0000 (UTC) Received: from new-host-2.home (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3557FB945; Mon, 9 Feb 2015 11:33:41 -0500 (EST) Message-ID: <54D8E169.6040002@FreeBSD.org> Date: Mon, 09 Feb 2015 11:33:45 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Adrian Chadd , Elizabeth Myers Subject: Re: Questions on adding backlight support for the i915 driver References: <54C883E7.4000300@interlinked.me> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Feb 2015 11:33:41 -0500 (EST) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 09 Feb 2015 16:33:42 -0000 On 1/30/15 6:16 PM, Adrian Chadd wrote: > Hi, > > Which chipset is it? > > Loading acpi_video causes a handful of interconnected pieces to shift > (as IIRC at that point acpi_video also states that it wishes to take > control of video setting, not just leave it all up to ACPI to drive > itself.) > > There's a bunch of discussion / code churn in the linux dri2/i915 code > (/past/ the point in 2012 that our code is currently synced to) about > how to manage backlights. A lot of it seems due to ridiculously large > variations in how backlights are actually managed. > > So, if we're going to do this, I think we should actually have a > generic backlight thing that figures out if the right thing to do is > talk to the underlying device/panel, rather than hang backlight > controls off of each driver. It may not always be off of drm. :( > There's also stuff surrounding locking and state changes, as well as > restoring backlight values after a suspend/resume cycle. That kind of > weird crap. I think we should get a few examples working so we have multiple things to generalize from. Also, so far the focus has only been on laptop LCDs. I've no idea if any external monitors support software backlight control. If they do, then that might put another wrinkle in, as what you really want is something like hw.backlight. to hang control nodes off of (or you want to do it in userland). (Ideally we'd use the same labels for that xrandr uses for outputs. I think the drm2 drivers are also using those labels for some controls now.) For now I would start with Elizabeth's current patch of exposing the raw i915 stuff via a sysctl. We can always remove this later if need be. -- John Baldwin