[RFC v2] drm/kms: control display brightness through drm_connector properties

[Simon Ser]

On Friday, September 30th, 2022 at 16:44, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:

> On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote:
> 
> > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen ppaalanen at gmail.com wrote:
> > 
> > > On Thu, 29 Sep 2022 20:06:50 +0200
> > > Sebastian Wick sebastian.wick at redhat.com wrote:
> > > 
> > > > If it is supposed to be a non-linear luminance curve, which one is it?
> > > > It would be much clearer if user space can control linear luminance
> > > > and use whatever definition of perceived brightness it wants. The
> > > > obvious downside of it is that it requires bits to encode changes that
> > > > users can't perceive. What about backlights which only have a few
> > > > predefined luminance levels? How would user space differentiate
> > > > between the continuous and discrete backlight? What about
> > > > self-emitting displays? They usually increase the dynamic range when
> > > > they increase in brightness because the black level doesn't rise. They
> > > > also probably employ some tonemapping to adjust for that. What about
> > > > the range of the backlight? What about the absolute luminance of the
> > > > backlight? I want to know about that all in user space.
> > > > 
> > > > I understand that most of the time the kernel doesn't have answers to
> > > > those questions right now but the API should account for all of that.
> > > 
> > > Hi,
> > > 
> > > if the API accounts for all that, and the kernel doesn't know, then how
> > > can the API not lie? If the API sometimes lies, how could we ever trust
> > > it at all?
> > 
> > Make it possible for the API to say "I don't know". I'd much rather
> > have an API tell me explicitly what it does and doesn't know instead
> > of having to guess what data I can actually rely on.
> > 
> > For example if the kernel knows the luminance is linear on one display
> > and doesn't know anything about the other display and it exposes them
> > both in the same way I can not possibly write any code which relies on
> > exact control over the luminance for either display.
> > 
> > > Personally I have the feeling that if we can even get to the level of
> > > "each step in the value is a more or less perceivable change", that
> > > would be good enough. Think of UI, e.g. hotkeys to change brightness.
> > > You'd expect almost every press to change it a bit.
> > 
> > The nice thing is that you can have that even if you have no further
> > information about the brightness control and it might be good enough
> > for some use cases but it isn't for others.
> > 
> > > If an end user wants defined and controlled luminance, I'd suggest they
> > > need to profile (physically measure) the response of the display at
> > > hand. This is no different from color profiling displays, but you need
> > > a measurement device that produces absolute measurements if absolute
> > > control is what they want.
> > 
> > If that's the kind of user experience you're after, good for you. I
> > certainly want things to work out of the box which makes this just a
> > big no-go.
> 
> 
> I think if we have the information to make the default behaviour
> better then we should do that. Ie. if the firmaware gives us a
> table to remap the values for a more linear response we should
> make use of that by default.
> 
> We can of course provide a way for the user to plug in their own
> actually measured data later. But IMO that doesn't even have to
> happen in the initial implementation. Just need to avoid painting
> ourselves totally in the corner in a way that would prevent later
> additions like that.

Yes. Please don't try to solve all of the problems at once. There have
been many tries to add brightness to KMS, and having *something* would
be a lot better than having nothing. If we try to have the perfect
complete API from the start then we'll never get anything done.