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

Hans de Goede hdegoede at redhat.com
Mon Oct 3 11:02:36 UTC 2022


Hi,

On 10/3/22 12:32, Pekka Paalanen wrote:
> On Mon, 3 Oct 2022 11:44:56 +0200
> Hans de Goede <hdegoede at 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.

Userspace comes in many forms, which is why my preference for "software curve"
support would be for it to be applied by the kernel by default (if present
in the VBT) but then with a "software curve enable" flag to allow advanced
userspace to disable it and then apply a curve of userspace's own choosing
itself.

This allows a simple implementation for desktop-environments which are
unlikely to implement all this themselves, giving everyone the benefit of
the nicer behavior of the VBT provided curve while allowing advanced
desktop environments (likely mainly KDE + GNOME/mutter) to do something
more advanced.

Either way, this is all future extensions. First lets get the basic
brightness control with just brightness + brightness-max attributes
in place.

Regards,

Hans



More information about the dri-devel mailing list