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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes  we would need this.
-Sameer

-----Original Message-----
From: wayland-devel <wayland-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Pekka Paalanen
Sent: Friday, April 29, 2022 2:37 PM
To: Hans de Goede <hdegoede@xxxxxxxxxx>
Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>; Sebastian Wick <sebastian.wick@xxxxxxxxxx>; Martin Roukala <martin.roukala@xxxxxxxxx>; Christoph Grenz <christophg+lkml@xxxxxxxxxxxxx>; wayland <wayland-devel@xxxxxxxxxxxxxxxxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx; Daniel Vetter <daniel@xxxxxxxx>; Alex Deucher <alexdeucher@xxxxxxxxx>; Yusuf Khan <yusisamerican@xxxxxxxxx>
Subject: Re: [RFC] drm/kms: control display brightness through drm_connector properties

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

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





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux