From owner-freebsd-current@FreeBSD.ORG Sat Jan 31 09:05:12 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 78FB3304 for ; Sat, 31 Jan 2015 09:05:12 +0000 (UTC) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.99.209.192]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "mail.wilcox-tech.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 318CF168 for ; Sat, 31 Jan 2015 09:05:11 +0000 (UTC) Received: (qmail 4017 invoked from network); 31 Jan 2015 09:06:30 -0000 Received: from ip68-13-243-137.ok.ok.cox.net (HELO ?192.168.1.253?) (emyers@wilcox-tech.com@68.13.243.137) by mail.foxkit.us with ESMTPA; 31 Jan 2015 09:06:30 -0000 Message-ID: <54CC9AC5.1050802@interlinked.me> Date: Sat, 31 Jan 2015 03:05:09 -0600 From: Elizabeth Myers User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Questions on adding backlight support for the i915 driver References: <54C883E7.4000300@interlinked.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Sat, 31 Jan 2015 09:05:12 -0000 On 01/30/15 17:16, Adrian Chadd wrote: > Hi, > > Which chipset is it? Oh, I missed this, sorry. I have an Ivy Bridge chipset. > 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.) My laptop doesn't have any ACPI calls for backlight stuff. Dell laptops seem to do it with SMI's. It's pretty lame (and exotic) stuff. > 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. A generic backlight module is probably ideal. Not everything uses ACPI to drive the backlight (my laptop doesn't). The way it could work is that drivers just provide the needed functions for changing the backlight and tell the driver "hey here's my functions for backlight change and query." That way anything can take advantage of it, including acpi_video, providing a nice and unified interface. > But I'd start with which chipset it is, which version of FreeBSD it > is, and whether the ACPI stuff would work for you with a code update. > But for a more general future thing, I'd rather we had a sysctl tree > of actual display devices, each one mapping to the underlying "thing" > it's controlling, so it's a generic API for both getting and setting > values for the various displays that are hooked into things. A code update won't do any good due to aforementioned issues. If anyone else has a Dell laptop and would be interested in helping to test, I will try to write a driver for them. In the meantime, I think there should be some other discussion elsewhere or in another thread about a generic backlight framework. -- Cheers, Elizabeth