Would it make sense to have a generic 'backlight' driver framework that we plug into? I wrote a backlight driver (well, 2, but both show up as dev.backlight in sysctl) for powerpc, but if we want to have even more individual backlight drivers, I think it makes sense to make them all look the same, with similar configuration properties. - Justin On Fri, Jan 30, 2015 at 3:16 PM, Adrian Chadd <adrian_at_freebsd.org> 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. > > 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_at_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_at_freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Fri Jan 30 2015 - 22:25:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC