From owner-freebsd-current@FreeBSD.ORG Fri Jan 30 15:17:53 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 584101F7 for ; Fri, 30 Jan 2015 15:17:53 +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 3063394C for ; Fri, 30 Jan 2015 15:17:53 +0000 (UTC) Received: from new-host-3.home (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A25CB913; Fri, 30 Jan 2015 10:17:52 -0500 (EST) Message-ID: <54CBA0A4.30708@FreeBSD.org> Date: Fri, 30 Jan 2015 10:17:56 -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: Elizabeth Myers , freebsd-current@freebsd.org Subject: Re: Questions on adding backlight support for the i915 driver References: <54C883E7.4000300@interlinked.me> In-Reply-To: <54C883E7.4000300@interlinked.me> 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); Fri, 30 Jan 2015 10:17:52 -0500 (EST) 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: Fri, 30 Jan 2015 15:17:53 -0000 On 1/28/15 1:38 AM, Elizabeth Myers wrote: > Hello, > > I want to add backlight support to the i915 driver in FreeBSD. It seems > that two magic addresses are read and wrote from to change the backlight > itself. It supports rather fine-level granularity all the way down to > zero. Right now I use a hacked-up userland program that reads > from/writes to these addresses, which is far from an ideal solution. > > I am interested in this because the acpi_video(4) driver does not > support my backlight on my Dell Inspiron 15 3521 (not terribly > suprising, on Linux I needed a special Dell-specific driver, and I'm not > sure even that really used ACPI, I never really checked). > > My questions are really twofold: > > 1) How can this be exposed appropriately? I would prefer this be exposed > generally so upower could grok it. As far as I can tell upower uses > hw.acpi.video.lcd0 to control backlight. I am not sure that upower is > doing the "right" thing here, though. > 2) Where would the code go for this? The dri2 driver seems the most > "logical" place, but maybe it belongs in X and exposed via a program? Or > something else entirely that I'm not thinking of? > > I have experience developing PCI drivers and doing other PCI related > doodads, and some kernel development experience, as well as general C > experience, but I'm not by any means an expert on the matter. Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) -- John Baldwin