Re: KMS backlight ABI proposition

["Jasper St. Pierre" <jstpierre@mecheye.net>]

[-- Attachment #1.1: Type: text/plain, Size: 5493 bytes --]

I don't work on this anymore, but, even disregarding the mess that is ACPI
backlight:

I think when people start interfacing with the Backlight API, they wonder
why it's not normalized. And then you start implementing it, and you
realize that some writes don't do anything. And that when you read back,
it's not what you just read. In any real implementation, I would want to
know the step number that causes a level of brightness. And once I have
that, I'm effectively doing 100/step to get a real hardware max level
anyway, so I'm effectively working around the normalized behavior.

These have all caused strange bugs for me in the past. Caching what's read
and what's written sounds like a solution until you realize that userspace
has plenty of DBus services and wrapper libraries to abstract out
implementation details and it's hard to figure out where you should put
that cache, and having it twice can also cause strange bugs.

Normalizing to 100 would make simple cases subtly wrong and make complex
cases impossible.

Instead of normalizing to 100, I think we should expose a max level, and
specify that's max brightness. Every single step in the range should have a
visible difference in output lumens. 0 is minimum brightness -- this means
the backlight is still on. Backlight being off should be -1 or we should
recommend people use DPMS.

This allows userspace to know everything it should and still provide for a
10-step "Brightness Up" button.

On Mon, Feb 20, 2017 at 2:40 PM, Alex Deucher <alexdeucher@gmail.com> wrote:

> On Mon, Feb 20, 2017 at 2:27 PM, Dave Airlie <airlied@gmail.com> wrote:
> > 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.
>
> 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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
  Jasper

[-- Attachment #1.2: Type: text/html, Size: 7813 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel