Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jan 2015 15:25:44 -0800
From:      Justin Hibbits <jrh29@alumni.cwru.edu>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-current <freebsd-current@freebsd.org>, Elizabeth Myers <elizabeth@interlinked.me>
Subject:   Re: Questions on adding backlight support for the i915 driver
Message-ID:  <CAHSQbTCrU-8kYpNoL_UiNd1PHtSG8sPnt8jRfGvEOZEWa_G4FA@mail.gmail.com>
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
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@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@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"
> _______________________________________________
> 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?CAHSQbTCrU-8kYpNoL_UiNd1PHtSG8sPnt8jRfGvEOZEWa_G4FA>