On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote:
On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson daniel.thompson@linaro.org wrote:
On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote:
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.