Date: Sat, 31 Jan 2015 03:05:09 -0600 From: Elizabeth Myers <elizabeth@interlinked.me> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Questions on adding backlight support for the i915 driver Message-ID: <54CC9AC5.1050802@interlinked.me> In-Reply-To: <CAJ-Vmokw2FqLHMkc%2B0MDsDxChMC68KdkvO43qhFztTZf8F89Mg@mail.gmail.com> References: <54C883E7.4000300@interlinked.me> <CAJ-Vmokw2FqLHMkc%2B0MDsDxChMC68KdkvO43qhFztTZf8F89Mg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54CC9AC5.1050802>