KMS backlight ABI proposition

[Alex Deucher]

On Mon, Feb 20, 2017 at 2:27 PM, Dave Airlie <airlied at gmail.com> wrote:
> On 17 February 2017 at 22:58, Martin Peres <martin.peres at linux.intel.com> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel