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

[Simon Ser]

On Friday, April 29th, 2022 at 10:55, Hans de Goede <hdegoede at redhat.com> wrote:

> I believe that we can fix the new interface, the plan is for there
> to be some helper code to proxy the new connector properties to what
> is still a good old backlight-device internally in the kernel,.
>
> This proxy-ing code could take a minimum value below which it should
> not go when things are set through the properties and then if e.g.
> the /sys/class/backlight interface offers range of 0-65535 and the
> kms driver asks the proxying helper for a minimum of 500, show this
> as 0-65035 on the property, simply adding 500 before sending the
> value to the backlight-device on writes (and subtracting 500 on reads,
> clamping to 0 as lowest value reported on reads).
>
> This way apps using the new API can never go below 500 (in this
> example) and for old API users nothing changes.
>
> Given that Jani seems to be in favor of enforcing some minimal value
> inside the i915 code going forward and also what Alex said that the
> amdgpu code already enforces its own minimum if the video BIOS tables
> don't provide one, it seems that there is consensus that we want 0
> to mean minimum brightness at which the screen is still somewhat
> readable and that we want to enforce this at the kernel level.
>
> Which also means the weird hint property which I came up with won't
> be necessary as we now have a clean definition of what brightness
> 0 is supposed to mean (in the new API) and any cases where this is not
> the case are kernel bugs and should be fixed in the kernel.

Looks like a good approach to me from user-space PoV!