Yes we would need this. -Sameer -----Original Message----- From: wayland-devel <wayland-devel-boun...@lists.freedesktop.org> On Behalf Of Pekka Paalanen Sent: Friday, April 29, 2022 2:37 PM To: Hans de Goede <hdego...@redhat.com> Cc: Jani Nikula <jani.nik...@linux.intel.com>; Sebastian Wick <sebastian.w...@redhat.com>; Martin Roukala <martin.rouk...@mupuf.org>; Christoph Grenz <christophg+l...@grenz-bonn.de>; wayland <wayland-de...@lists.freedesktop.org>; dri-devel@lists.freedesktop.org; Daniel Vetter <dan...@ffwll.ch>; Alex Deucher <alexdeuc...@gmail.com>; Yusuf Khan <yusisameri...@gmail.com> Subject: Re: [RFC] drm/kms: control display brightness through drm_connector properties
On Fri, 29 Apr 2022 08:59:24 +0000 Simon Ser <cont...@emersion.fr> wrote: > On Friday, April 29th, 2022 at 10:55, Hans de Goede <hdego...@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