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

[Pekka Paalanen]

On Fri, 30 Sep 2022 18:17:39 +0200
Sebastian Wick <sebastian.wick at redhat.com> wrote:

> On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Fri, 30 Sep 2022 17:44:17 +0300
> > 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.  

...

> > I'm saying that what looks realistic to me is somewhere *between*
> > status quo and what Sebastian is asking for. Whatever you mean by "linear
> > remapping" is probably a realistic goal, because you know you have some
> > hardware/firmware delivering that information already.
> >
> > OTOH, designing UAPI for information that exists only in our dreams
> > is... well.  
> 
> I also didn't say that we should design an UAPI for what doesn't
> exist, just that we should design the UAPI we actually need in a way
> that when we get more information we can properly expose that. So if
> the UAPI exposes anything other than the luminance (e.g. "each step is
> a perceptual step in brightness", "linear brightness", ..) we have to
> put some human perception model into the kernel which is ridiculous
> and it makes it impossible to expose luminance to user space if the
> kernel has that information.

You don't need a human perception model in the kernel. You also cannot
have one, because I would expect most or all backlight and their
metadata to not define luminance at all. But that is just a guess.

I suppose the firmware may expose some tables that may allow mapping
raw hardware values into something more pleasant to use. Like something
where each step is more or less a visible change. That does not have to
imply anything about linearity in any space, they may just be "good
values" for e.g. keyboard-based changing of backlight levels with no
mathematical or physical basis.

Ville, what kind of tables do you know about? What do they actually
tell?

Let's say we have these first properties defined as "reasonable steps
for manual backlight control": one integer for the value, another
integer for the max. If we later see that we can actually get more
precise or high-level information, we can add new optional properties,
e.g. a blob with table that maps the integers into some better defined
quantity.

Then we know what the values mean, but the steps may be quite
coarse, much coarser than what the raw control value allows. That's the
next problem: if we want as fine control as hardware is capable, how do
you expose that?

Should the answer be, that the exposed integer is actually a raw value
for hardware, merely offsetted so that zero maps to minimum but visible
backlight level, and then add another property from the start with a
table for the "good values" for keyboard control?

And the "good values" would be literally just that, no implication of
linearity of anything.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20221003/ff26f020/attachment.sig>