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

[Ville Syrjälä]

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.

I just hate the current limbo where we're somehow too afraid to
change the current behaviour to do the remapping by default.
I see no upsides in the current behaviour of just blindly
exposing the raw hardware register values more or less. They
mean absolutely nothing to any user.

-- 
Ville Syrjälä
Intel