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.
On Fri, Jan 30, 2015 at 3:16 PM, Adrian Chadd <adr...@freebsd.org> wrote:
> 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
> 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.
> On 27 January 2015 at 22:38, Elizabeth Myers <elizab...@interlinked.me> wrote:
>> 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.
>> Elizabeth Myers
>> email@example.com mailing list
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"