Date: Fri, 30 Jan 2015 15:16:31 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Elizabeth Myers <elizabeth@interlinked.me> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Questions on adding backlight support for the i915 driver Message-ID: <CAJ-Vmokw2FqLHMkc%2B0MDsDxChMC68KdkvO43qhFztTZf8F89Mg@mail.gmail.com> In-Reply-To: <54C883E7.4000300@interlinked.me> References: <54C883E7.4000300@interlinked.me>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. -adrian On 27 January 2015 at 22:38, Elizabeth Myers <elizabeth@interlinked.me> 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. > > Cheers, > Elizabeth Myers > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokw2FqLHMkc%2B0MDsDxChMC68KdkvO43qhFztTZf8F89Mg>