On 1/30/15 6:16 PM, Adrian Chadd 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.

I think we should get a few examples working so we have multiple things
to generalize from.  Also, so far the focus has only been on laptop
LCDs.  I've no idea if any external monitors support software backlight
control.  If they do, then that might put another wrinkle in, as what
you really want is something like hw.backlight.<monitor> to hang control
nodes off of (or you want to do it in userland).  (Ideally we'd use the
same labels for <monitor> that xrandr uses for outputs.  I think the
drm2 drivers are also using those labels for some controls now.)  For
now I would start with Elizabeth's current patch of exposing the raw
i915 stuff via a sysctl.  We can always remove this later if need be.

John Baldwin
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to