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

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Mon, 3 Oct 2022 11:44:56 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> One example mentioned here is that laptops with Intel integrated
> graphics may have some "perceived brightness" mapping table
> in their Video BIOS Tables (VBT) it would be interesting to use
> this and to export the curve coming from that to userspace as
> extra information (including allow userspace to write it).
> Since in this case (unlike many other cases) at least this
> curve is done in the kernel I guess we can then also add a boolean
> property to disable the curve (making it linear) in case that
> is helpful for HDR scenarios.

Hi Hans,

what if you would export that curve to userspace and not apply it in
the kernel, aside from the min-luminance=0 offset?

I'm not sure if that was your intention, I didn't see it clearly said.
Of course this can be only about curves that are supposed to be applied
by the OS and not applied in firmware or hardware. Call it "software
curve"?

Let userspace apply that curve if it happens to exist. Then, if we get
some other definition replacing that curve on some hardware, the kernel
could just expose the other thing as a new thing, and the old curve API
would not be interfering. Userspace that does not understand the new
thing (and the old curve property is not populated) would still be able
to control the brightness, just not in as pleasant way.

It would also make using a custom curve a completely userspace thing with
no need for the kernel to support overwriting it.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]