On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote:

On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson
[off-list ref] wrote:

quoted

On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote:

quoted

And the big upside is that in the end (i.e. when all kernel drivers and
userspace applications are adapted to provide/consume the "correct"
curve) the result is simpler.

My view is that this convergence will eventually be achieved but it will
happen through the obsolescence of the backlight sysfs interface. The
sysfs interface has other flaws, in particular no integration with the
DRM connector API.

Thus I would expect an alternative interface to emerge, most likely as
part of the DRM connector API. I'd expect such a new API to a
perceptual scale and to have a fixed max brightness with enough
steps to support animated backlight effects (IIRC 0..100 has been
proposed in the past)

In the mean time getting the existing collection of backlight drivers
marked up as linear/logarithmic/etc will ease the introduction of that
API because, within the kernel, we might have gathered enough knowledge
to have some hope of correctly mapping each backlight onto a
standardized scale.

In case people wonder why the drm connector based backlight interface
hasn't happened ages ago, some more context:

- userspace (well libbacklight) selects the right backlight, using
some priority search. Plus blacklists in drivers to make sure they're
not overriding the real backlight driver (e.g. acpi has higher
priority in libbacklight, but on modern system it's not the backlight
driver you want. If we move that into the kernel it's going to be
somewhat a mess, since defacto you never know when loading is complete
and you actually have the right backlight driver.

This isn't a problem on DT platforms, but really just for x86/acpi
platforms. But if we don't fix them, then userspace adoption of these
new interfaces will likely be too low to matter.

- second issue is that right now the kms client is supposed to handle
backlight around modeset, like fbdev does through the fb notifier.
Except for drivers which do handle the backlight across modesets, but
maybe not the right backlight. If we move the backlight interface to
drm connectors then the right thing would be for the drm driver to
handle backlight enable/disable across modesets. But to make that
work, userspace needs to stop touching it (otherwise userspace first
disables, then the kernel and then on restore the two fight and
usually black screen wins), and that's a bit a tricky uapi problem of
not breaking existing userspace.

- finally there's some userspace which assumes the lowest backlight
setting is actually off, and uses that to do fast modesets. This
doesn't work on most ACPI backlights, so I think that problem isn't
widespread.

Anyway from watching from afar, I think this clarification on what the
backlight scale means internally should at least help us somewhat in
the long term. But the long term solution itself needs someone with
way too much time I fear, so lets not hold up anything on that.

Thanks for sharing your views on this.


Daniel.