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

From: Pekka Paalanen <ppaalanen@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>,
	Martin Roukala <martin.roukala@mupuf.org>,
	Christoph Grenz <christophg+lkml@grenz-bonn.de>,
	wayland <wayland-devel@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Yusuf Khan <yusisamerican@gmail.com>
Subject: Re: [RFC] drm/kms: control display brightness through drm_connector properties
Date: Fri, 29 Apr 2022 12:06:51 +0300	[thread overview]
Message-ID: <20220429120651.5a39ec03@eldfell> (raw)
In-Reply-To: <vdb4oRbKTPYjAGPcmjKfhcDQbMb1VuiJwF99I3UwkwUAsyEvvq5x7yKdP0mx5tEeNc2idU_qBSlbMM4dlv7apLeDvG3PIAkvRMjwVNKZGCk=@emersion.fr>

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

On Fri, 29 Apr 2022 08:59:24 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Friday, April 29th, 2022 at 10:55, Hans de Goede <hdegoede@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!

Yes!

Thanks,
pq

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