Re: KMS backlight ABI proposition

[Dave Airlie <airlied@gmail.com>]

On 17 February 2017 at 22:58, Martin Peres <martin.peres@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.

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel