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. 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
