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 BaldwinReceived on Mon Feb 09 2015 - 15:33:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC