Skip site navigation (1)Skip section navigation (2)
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>