On Mon, Feb 20, 2017 at 2:27 PM, Dave Airlie <airlied@xxxxxxxxx> wrote: > On 17 February 2017 at 22:58, Martin Peres <martin.peres@xxxxxxxxxxxxxxx> wrote: >> Hey everyone, >> >> We have been working towards exposing the backlight as a KMS property >> instead of relying on the backlight drivers. We have CC:ed the people we >> have found to be the more likely to be interested in the discussion but >> please add everyone you think would have some experience with this issue. >> >> == Introduction == >> >> We are trying to bring the same level of support for the backlight on both >> the xf86-video-intel and -modesetting DDX. >> >> Looking into the situation of the backlight, we identified these problems >> which are almost show-stoppers for -modesetting and wayland compositors: >> >> - There is no mapping between the backlight driver and DRM-connectors. This >> means that, in case there are multiple backlight drivers, the userspace has >> to have knowledge of the machine to know which driver should be used. See >> the priority list for the intel driver [0]. >> >> - The luminance curve of the backlight drivers is not specified, which can >> lead to a bad user experience: Little changes in the highest levels but >> drastic changes in the low levels. >> >> - Writing to the backlight driver still requires root rights. Given that >> the xserver and wayland compositors are now running root-less, this means we >> would need a complex dance involving a setuid helper [1]. >> >> Hans de Goede has already given a presentation about these issues at >> XDC2014. The slides are a good read[2]. >> >> [0] >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n259 >> >> [1] >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/backlight.c#n348 >> >> [2] >> https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/backlight.pdf >> >> == Proposal == >> >> Since David Hermann already worked on this and proposed what I consider >> being greats foundations for building towards a solution addressing the >> issues above, I will just ask you to read his original words: >> >> https://lists.freedesktop.org/archives/dri-devel/2014-September/067984.html > > You might want to read the rest of that thread, the response posted by Matthew > > This is really messy and we made a decision to put the policy to pick > which backlight > driver into userspace because it's not something the kernel can figure > out properly. > > Things might have changed now a bit with Win10 not using ACPI backlight controls > if memory serves, but it's still an unholy mess. > > I think MBPs can expose 3 backlights (ACPI, gmux and driver) and only > the gmux one > does anything. Even on non-Macs, hybrid laptops can be problematic. In some, the backlight control was muxed, in some it was not. Fortunately, muxed laptops are a thing of the past, at least for non-Macs. Alex > > How do you tackle that end of the problem, how does the i915/drm core > know when the > driver for the one backlight it needs has appeared, and is working, by > deferring this to > userspace we let the system load all the drivers and the policy of > picking the correct one > is left there. > > I'm not saying this is pretty,and we have libbacklight to "solve" the > problems for generic > userspace, but any solution is going to a be a lot uglier than you think. > > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
