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

[Hans de Goede]

Hi,

On 8/25/22 23:40, Yusuf Khan wrote:
> Perhaps the Kconfig modifications could be postponed to stage 2
> since for people running distros that suddenly decide to disable
> /sys/class/backlight/ it may be impractical for them to recompile
> their kernels and such.

In step 1, the Kconfig option is just there to select the default
setting of the kernel commandline parameter. So when a distro
defaults that to disabling /sys/class/backlight (or making it
read-only) then the user can simple override it on the kernel
commandline. No re-compiling of kernels needed.

> Also stage 2 should probably take ~2 decades
> until it comes into being, for reference fbdev SPECIFIC drivers
> were removed from fedora just recently and because of that there
> were some issues with some user's systems. I understand it's much
> easier to change from the /sys/class/backlight/ interface to the one
> you have proposed than to change from fbdev to KMS though.

Yes chances are we will be stuck with the old sysfs API for a long
time to come. Note that since in some cases the backlight driver
is not part of the GPU driver, but rather part of e.g. dell-laptop
we will need the backlight-device abstraction in the kernel going
forward regardless of what happens with /sys/class/backlight.

So the cleanup resulting from removing it completely will not
be that big as the backlight-device abstraction will stay it
will only be the sysfs interface which disappears.

As such just having a kernel cmdline parameter to hide/unhide
it might be good enough.

Regards,

Hans



> 
> On Thu, Aug 25, 2022 at 3:27 AM Hans de Goede  > wrote:
> 
> Hi Yusuf,
> 
> On 8/24/22 04:18, Yusuf Khan wrote:
> > Sorry for the necro-bump, I hadnt seen this go by
> 
> No problem.
> 
> > My main concern with this proposal is the phasing out of 
> /sys/class/backlight/.
> > Currently on the user(user, not userland) level its easier for me to 
> just modify
> > the file and be done with it. xbacklight doesnt tell me when its failed,
> > brightnessctl doesnt make assumptions about what device is what, and
> > other brightness setting applications ive seen are much worse than them.
> > Someone needs to create a userland application thats less inconvenient
> > than `echo`ing into /sys/class/backlight with a name that human beings 
> can
> > actually remember before I stop using the sysfs, perhaps "setbrightness"
> > could be the binary's name? Also I dont think its wise to disable or 
> make it
> > read only though Kconfig as older apps may depend on it, maybe add a
> > kernel param that disables the old interface so bigger distros can 
> pressure
> > app makers into changing the interface? As a big draw for DDC/CI is that
> > many displays support it as a way to change brightness(even if you arent
> > doing anything special that would break the old interface) perhaps it 
> could
> > be an early adopter to that kernel parameter?
> 
> Right, so deprecating the /sys/class/backlight API definitely is the last
> step and probably is years away. As you say hiding / making it read-only
> should probably be a kernel-parameter at first, with maybe a Kconfig
> option to set the default. So the depcration would go like this:
> 
> 1. Add:
> A kernel-parameter to allow hiding or read-only-ing the sysfs interface +
> Kconfig to select the default +
> dev_warn_once() when the old API is used
> 
> 2. (much later) Drop the Kconfig option and default to hiding/read-only
> 
> 3. (even later) Maybe completely remove the sysfs interface?
> 
> Note the hiding vs read-only thing is to be decided. ATM I'm rather more
> focused on getting the new API in place then on deprecating the old one :)
> 
> Anyways I fully agree that we need to do the deprecation carefully and
> slowly. This is likely going to take multiple years and then some ...
> 
> Regards,
> 
> Hans
> 
> 
> 
> >
> > On Thu, Apr 7, 2022 at 10:39 AM Hans de Goede    >> wrote:
> >
> >     As discussed already several times in the past:
> >      https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ 
>  
>  >
> >      
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
>  
> 
>  
>   
> >
> >
> >     The current userspace API for brightness control offered by
> >     

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

[Yusuf Khan]

Perhaps the Kconfig modifications could be postponed to stage 2
since for people running distros that suddenly decide to disable
/sys/class/backlight/ it may be impractical for them to recompile
their kernels and such. Also stage 2 should probably take ~2 decades
until it comes into being, for reference fbdev SPECIFIC drivers
were removed from fedora just recently and because of that there
were some issues with some user's systems. I understand it's much
easier to change from the /sys/class/backlight/ interface to the one
you have proposed than to change from fbdev to KMS though.

On Thu, Aug 25, 2022 at 3:27 AM Hans de Goede  wrote:

> Hi Yusuf,
>
> On 8/24/22 04:18, Yusuf Khan wrote:
> > Sorry for the necro-bump, I hadnt seen this go by
>
> No problem.
>
> > My main concern with this proposal is the phasing out of
> /sys/class/backlight/.
> > Currently on the user(user, not userland) level its easier for me to
> just modify
> > the file and be done with it. xbacklight doesnt tell me when its failed,
> > brightnessctl doesnt make assumptions about what device is what, and
> > other brightness setting applications ive seen are much worse than them.
> > Someone needs to create a userland application thats less inconvenient
> > than `echo`ing into /sys/class/backlight with a name that human beings
> can
> > actually remember before I stop using the sysfs, perhaps "setbrightness"
> > could be the binary's name? Also I dont think its wise to disable or
> make it
> > read only though Kconfig as older apps may depend on it, maybe add a
> > kernel param that disables the old interface so bigger distros can
> pressure
> > app makers into changing the interface? As a big draw for DDC/CI is that
> > many displays support it as a way to change brightness(even if you arent
> > doing anything special that would break the old interface) perhaps it
> could
> > be an early adopter to that kernel parameter?
>
> Right, so deprecating the /sys/class/backlight API definitely is the last
> step and probably is years away. As you say hiding / making it read-only
> should probably be a kernel-parameter at first, with maybe a Kconfig
> option to set the default. So the depcration would go like this:
>
> 1. Add:
> A kernel-parameter to allow hiding or read-only-ing the sysfs interface +
> Kconfig to select the default +
> dev_warn_once() when the old API is used
>
> 2. (much later) Drop the Kconfig option and default to hiding/read-only
>
> 3. (even later) Maybe completely remove the sysfs interface?
>
> Note the hiding vs read-only thing is to be decided. ATM I'm rather more
> focused on getting the new API in place then on deprecating the old one :)
>
> Anyways I fully agree that we need to do the deprecation carefully and
> slowly. This is likely going to take multiple years and then some ...
>
> Regards,
>
> Hans
>
>
>
> >
> > On Thu, Apr 7, 2022 at 10:39 AM Hans de Goede  > wrote:
> >
> > As discussed already several times in the past:
> >  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ <
> https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/>
> >
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> <
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> >
> >
> > The current userspace API for brightness control offered by
> > /sys/class/backlight devices has various issues, the biggest 2 being:
> >
> > 1. There is no way to map the backlight device to a specific
> >display-output / panel (1)
> > 2. Controlling the brightness requires root-rights requiring
> >desktop-environments to use suid-root helpers for this.
> >
> > As already discussed on various conference's hallway tracks
> > and as has been proposed on the dri-devel list once before (2),
> > it seems that there is consensus that the best way to to solve these
> > 2 issues is to add support for controlling a video-output's
> brightness
> > through properties on the drm_connector.
> >
> > This RFC outlines my plan to try and actually implement this,
> > which has 3 phases:
> >
> >
> > Phase 1: Stop registering multiple /sys/class/backlight devs for a
> single display
> >
>  
> =
> >
> > On x86 there can be multiple firmware + direct-hw-access methods
> > for controlling the backlight and in some cases the kernel registers
> > multiple backlight-devices for a single internal laptop LCD panel:
> >
> > a) i915 and nouveau unconditionally register their "native"
> backlight dev
> >even on devices where /sys/class/backlight/acpi_video0 must be
> used
> >to control the backlight, relying on userspace to prefer the
> "firmware"
> >acpi_video0 device over "native" devices.
> > b) amdgpu and nouveau rely on the acpi_video driver initializing
> before
> >them, 

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

[Hans de Goede]

Hi Yusuf,

On 8/24/22 04:18, Yusuf Khan wrote:
> Sorry for the necro-bump, I hadnt seen this go by

No problem.

> My main concern with this proposal is the phasing out of 
> /sys/class/backlight/.
> Currently on the user(user, not userland) level its easier for me to just 
> modify
> the file and be done with it. xbacklight doesnt tell me when its failed,
> brightnessctl doesnt make assumptions about what device is what, and
> other brightness setting applications ive seen are much worse than them.
> Someone needs to create a userland application thats less inconvenient
> than `echo`ing into /sys/class/backlight with a name that human beings can
> actually remember before I stop using the sysfs, perhaps "setbrightness"
> could be the binary's name? Also I dont think its wise to disable or make it
> read only though Kconfig as older apps may depend on it, maybe add a
> kernel param that disables the old interface so bigger distros can pressure
> app makers into changing the interface? As a big draw for DDC/CI is that
> many displays support it as a way to change brightness(even if you arent
> doing anything special that would break the old interface) perhaps it could
> be an early adopter to that kernel parameter?

Right, so deprecating the /sys/class/backlight API definitely is the last
step and probably is years away. As you say hiding / making it read-only
should probably be a kernel-parameter at first, with maybe a Kconfig
option to set the default. So the depcration would go like this:

1. Add:
A kernel-parameter to allow hiding or read-only-ing the sysfs interface +
Kconfig to select the default +
dev_warn_once() when the old API is used

2. (much later) Drop the Kconfig option and default to hiding/read-only

3. (even later) Maybe completely remove the sysfs interface?

Note the hiding vs read-only thing is to be decided. ATM I'm rather more
focused on getting the new API in place then on deprecating the old one :)

Anyways I fully agree that we need to do the deprecation carefully and
slowly. This is likely going to take multiple years and then some ...

Regards,

Hans



> 
> On Thu, Apr 7, 2022 at 10:39 AM Hans de Goede  > wrote:
> 
> As discussed already several times in the past:
>  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ 
> 
>  
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
>  
> 
> 
> The current userspace API for brightness control offered by
> /sys/class/backlight devices has various issues, the biggest 2 being:
> 
> 1. There is no way to map the backlight device to a specific
>    display-output / panel (1)
> 2. Controlling the brightness requires root-rights requiring
>    desktop-environments to use suid-root helpers for this.
> 
> As already discussed on various conference's hallway tracks
> and as has been proposed on the dri-devel list once before (2),
> it seems that there is consensus that the best way to to solve these
> 2 issues is to add support for controlling a video-output's brightness
> through properties on the drm_connector.
> 
> This RFC outlines my plan to try and actually implement this,
> which has 3 phases:
> 
> 
> Phase 1: Stop registering multiple /sys/class/backlight devs for a single 
> display
> 
> =
> 
> On x86 there can be multiple firmware + direct-hw-access methods
> for controlling the backlight and in some cases the kernel registers
> multiple backlight-devices for a single internal laptop LCD panel:
> 
> a) i915 and nouveau unconditionally register their "native" backlight dev
>    even on devices where /sys/class/backlight/acpi_video0 must be used
>    to control the backlight, relying on userspace to prefer the "firmware"
>    acpi_video0 device over "native" devices.
> b) amdgpu and nouveau rely on the acpi_video driver initializing before
>    them, which currently causes /sys/class/backlight/acpi_video0 to 
> usually
>    show up and then they register their own native backlight driver after
>    which the drivers/acpi/video_detect.c code unregisters the acpi_video0
>    device. This means that userspace briefly sees 2 devices and the
>    disappearing of acpi_video0 after a brief time confuses the systemd
>    backlight level save/restore code, see e.g.:
>    https://bbs.archlinux.org/viewtopic.php?id=269920 
> 
> 
> I already have a pretty detailed plan to tackle this, which I will
> post in a separate RFC email. I plan to start working on this right
> away, as it will be good to have this fixed regardless.
> 
> 
> Phase 2: Add drm_connector 

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

[Yusuf Khan]

Sorry for the necro-bump, I hadnt seen this go by

My main concern with this proposal is the phasing out of
/sys/class/backlight/.
Currently on the user(user, not userland) level its easier for me to just
modify
the file and be done with it. xbacklight doesnt tell me when its failed,
brightnessctl doesnt make assumptions about what device is what, and
other brightness setting applications ive seen are much worse than them.
Someone needs to create a userland application thats less inconvenient
than `echo`ing into /sys/class/backlight with a name that human beings can
actually remember before I stop using the sysfs, perhaps "setbrightness"
could be the binary's name? Also I dont think its wise to disable or make it
read only though Kconfig as older apps may depend on it, maybe add a
kernel param that disables the old interface so bigger distros can pressure
app makers into changing the interface? As a big draw for DDC/CI is that
many displays support it as a way to change brightness(even if you arent
doing anything special that would break the old interface) perhaps it could
be an early adopter to that kernel parameter?

On Thu, Apr 7, 2022 at 10:39 AM Hans de Goede  wrote:

> As discussed already several times in the past:
>  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
>
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
>
> The current userspace API for brightness control offered by
> /sys/class/backlight devices has various issues, the biggest 2 being:
>
> 1. There is no way to map the backlight device to a specific
>display-output / panel (1)
> 2. Controlling the brightness requires root-rights requiring
>desktop-environments to use suid-root helpers for this.
>
> As already discussed on various conference's hallway tracks
> and as has been proposed on the dri-devel list once before (2),
> it seems that there is consensus that the best way to to solve these
> 2 issues is to add support for controlling a video-output's brightness
> through properties on the drm_connector.
>
> This RFC outlines my plan to try and actually implement this,
> which has 3 phases:
>
>
> Phase 1: Stop registering multiple /sys/class/backlight devs for a single
> display
>
> =
>
> On x86 there can be multiple firmware + direct-hw-access methods
> for controlling the backlight and in some cases the kernel registers
> multiple backlight-devices for a single internal laptop LCD panel:
>
> a) i915 and nouveau unconditionally register their "native" backlight dev
>even on devices where /sys/class/backlight/acpi_video0 must be used
>to control the backlight, relying on userspace to prefer the "firmware"
>acpi_video0 device over "native" devices.
> b) amdgpu and nouveau rely on the acpi_video driver initializing before
>them, which currently causes /sys/class/backlight/acpi_video0 to usually
>show up and then they register their own native backlight driver after
>which the drivers/acpi/video_detect.c code unregisters the acpi_video0
>device. This means that userspace briefly sees 2 devices and the
>disappearing of acpi_video0 after a brief time confuses the systemd
>backlight level save/restore code, see e.g.:
>https://bbs.archlinux.org/viewtopic.php?id=269920
>
> I already have a pretty detailed plan to tackle this, which I will
> post in a separate RFC email. I plan to start working on this right
> away, as it will be good to have this fixed regardless.
>
>
> Phase 2: Add drm_connector properties mirroring the matching backlight
> device
>
> =
>
> The plan is to add a drm_connector helper function, which optionally takes
> a pointer to the backlight device for the GPU's native backlight device,
> which will then mirror the backlight settings from the backlight device
> in a set of read/write brightness* properties on the connector.
>
> This function can then be called by GPU drivers for the drm_connector for
> the internal panel and it will then take care of everything. When there
> is no native GPU backlight device, or when it should not be used then
> (on x86) the helper will use the acpi_video_get_backlight_type() to
> determine which backlight-device should be used instead and it will find
> + mirror that one.
>
>
> Phase 3: Deprecate /sys/class/backlight uAPI
> 
>
> Once most userspace has moved over to using the new drm_connector
> brightness props, a Kconfig option can be added to stop exporting
> the backlight-devices under /sys/class/backlight. The plan is to
> just disable the sysfs interface and keep the existing backlight-device
> internal kernel abstraction as is, since some abstraction for (non GPU
> native) backlight devices will be necessary regardless.
>
> An alternative to disabling the sysfs class entirely, would be
> to 

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

[Hans de Goede]

Hi,

On 5/18/22 16:23, Jani Nikula wrote:
> On Wed, 18 May 2022, Hans de Goede  wrote:
>> So how about: display_brightness or panel_brightness ?
> 
> This is a prime opportunity to look at all the existing properties, and
> come up with a new combination of capitalization, spacing, hyphens,
> underscores, etc. to accompany the total lack of unification we
> currently have. DisPLay_brIgh7ne55. :p
> 
> I think "display_brightness" is probably fine.

Interesting remark about the use of space/_/- I checked drm_connector.c
and most properties use all lower case with spaces so to try and be consistent,
I'll replace the _ with a space.

I guess it is time for me to create a v2 of this proposal.

Regards,

Hans

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

[Ville Syrjälä]

On Wed, May 18, 2022 at 02:59:58PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 4/14/22 15:10, Jani Nikula wrote:
> > There are some cases where we can actually get a rough PWM/luminance
> > curve from i915 opregion. I think maybe 16 data points. We've never
> > exposed that. My idea was that you'd have a property where you could add
> > data points for the curve, it could get pre-populated by the kernel if
> > the kernel knows how to do it, defaulting to linear, but it could also
> > be set or adjusted by userspace. The point would be that the userspace
> > adjusts brightness linearly, and the kernel would use the curve data
> > points to adjust it non-linearly. The userspace could have completely
> > separated brightness adjustment and curve adjustment, and the brightness
> > adjustment would be dead simple.
> 
> Interesting, I guess this could be a future feature addition on top
> of my work.

Here's an outdated branch:
https://github.com/vsyrjala/linux/commits/blcm_backlight

Wrote that some years ago after getting fed up with the useless
non-linear respose of the brightness up/down buttons on my laptop.
Been running it ever since.

-- 
Ville Syrjälä
Intel

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

[Jani Nikula]

On Wed, 18 May 2022, Hans de Goede  wrote:
> So how about: display_brightness or panel_brightness ?

This is a prime opportunity to look at all the existing properties, and
come up with a new combination of capitalization, spacing, hyphens,
underscores, etc. to accompany the total lack of unification we
currently have. DisPLay_brIgh7ne55. :p

I think "display_brightness" is probably fine.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

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

[Hans de Goede]

Hi,

On 4/14/22 15:10, Jani Nikula wrote:
> On Thu, 07 Apr 2022, Hans de Goede  wrote:
>> As discussed already several times in the past:
>>  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
>>  
>> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
>>
>> The current userspace API for brightness control offered by
>> /sys/class/backlight devices has various issues, the biggest 2 being:
>>
>> 1. There is no way to map the backlight device to a specific
>>display-output / panel (1)
>> 2. Controlling the brightness requires root-rights requiring
>>desktop-environments to use suid-root helpers for this.
>>
>> As already discussed on various conference's hallway tracks
>> and as has been proposed on the dri-devel list once before (2),
>> it seems that there is consensus that the best way to to solve these
>> 2 issues is to add support for controlling a video-output's brightness
>> through properties on the drm_connector.
>>
>> This RFC outlines my plan to try and actually implement this,
>> which has 3 phases:
>>
>>
>> Phase 1: Stop registering multiple /sys/class/backlight devs for a single 
>> display
>> =
>>
>> On x86 there can be multiple firmware + direct-hw-access methods
>> for controlling the backlight and in some cases the kernel registers
>> multiple backlight-devices for a single internal laptop LCD panel:
>>
>> a) i915 and nouveau unconditionally register their "native" backlight dev
>>even on devices where /sys/class/backlight/acpi_video0 must be used
>>to control the backlight, relying on userspace to prefer the "firmware"
>>acpi_video0 device over "native" devices.
>> b) amdgpu and nouveau rely on the acpi_video driver initializing before
>>them, which currently causes /sys/class/backlight/acpi_video0 to usually
>>show up and then they register their own native backlight driver after
>>which the drivers/acpi/video_detect.c code unregisters the acpi_video0
>>device. This means that userspace briefly sees 2 devices and the
>>disappearing of acpi_video0 after a brief time confuses the systemd
>>backlight level save/restore code, see e.g.:
>>https://bbs.archlinux.org/viewtopic.php?id=269920
>>
>> I already have a pretty detailed plan to tackle this, which I will
>> post in a separate RFC email. I plan to start working on this right
>> away, as it will be good to have this fixed regardless.
>>
>>
>> Phase 2: Add drm_connector properties mirroring the matching backlight device
>> =
>>
>> The plan is to add a drm_connector helper function, which optionally takes
>> a pointer to the backlight device for the GPU's native backlight device,
>> which will then mirror the backlight settings from the backlight device
>> in a set of read/write brightness* properties on the connector.
>>
>> This function can then be called by GPU drivers for the drm_connector for
>> the internal panel and it will then take care of everything. When there
>> is no native GPU backlight device, or when it should not be used then
>> (on x86) the helper will use the acpi_video_get_backlight_type() to
>> determine which backlight-device should be used instead and it will find
>> + mirror that one.
>>
>>
>> Phase 3: Deprecate /sys/class/backlight uAPI
>> 
>>
>> Once most userspace has moved over to using the new drm_connector
>> brightness props, a Kconfig option can be added to stop exporting
>> the backlight-devices under /sys/class/backlight. The plan is to
>> just disable the sysfs interface and keep the existing backlight-device
>> internal kernel abstraction as is, since some abstraction for (non GPU
>> native) backlight devices will be necessary regardless.
>>
>> An alternative to disabling the sysfs class entirely, would be
>> to allow setting it to read-only through Kconfig.
>>
>>
>> What scale to use for the drm_connector bl_brightness property?
>> ===
>>
>> The tricky part of this plan is phase 2 and then esp. defining what the
>> new brightness properties will look like and how they will work.
>>
>> The biggest challenge here is to decide on a fixed scale for the main
>> brightness property, say 0-65535, using scaling where the actual hw scale
>> is different, or if this should simply be a 1:1 mirror of the current
>> backlight interface, with the actual hw scale / brightness_max value
>> exposed as a drm_connector property.
>>
>> 1:1 advantages / 0-65535 disadvantages
>> - Userspace will likely move over to the connector-props quite slowly and
>>   we can expect various userspace bits, esp. also custom user scripts, to
>>   keep using the old uAPI for a long time. Using the 2 APIs are intermixed
>>   is fine when using a 1:1 brightness scale mapping. But if we end up doing
>>   

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

[Lattannavar, Sameer]

Yes  we would need this.
-Sameer

-Original Message-
From: wayland-devel  On Behalf Of 
Pekka Paalanen
Sent: Friday, April 29, 2022 2:37 PM
To: Hans de Goede 
Cc: Jani Nikula ; Sebastian Wick 
; Martin Roukala ; 
Christoph Grenz ; wayland 
; dri-devel@lists.freedesktop.org; Daniel 
Vetter ; Alex Deucher ; Yusuf Khan 

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

On Fri, 29 Apr 2022 08:59:24 +
Simon Ser  wrote:

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

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

[Pekka Paalanen]

On Fri, 29 Apr 2022 08:59:24 +
Simon Ser  wrote:

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



pgp_UUQ1mvss0.pgp
Description: OpenPGP digital signature

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

[Simon Ser]

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

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

[Hans de Goede]

Hi,

On 4/27/22 16:26, Daniel Vetter wrote:
> On Wed, Apr 27, 2022 at 05:23:22PM +0300, Jani Nikula wrote:
>> On Wed, 27 Apr 2022, Daniel Vetter  wrote:
>>> On Thu, Apr 14, 2022 at 01:24:30PM +0300, Jani Nikula wrote:
 On Mon, 11 Apr 2022, Alex Deucher  wrote:
> On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 4/8/22 17:11, Alex Deucher wrote:
>>> On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  
>>> wrote:

 Hi,

 On 4/8/22 16:08, Alex Deucher wrote:
> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
>>
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  
>>> wrote:

 Hi Simon,

 On 4/7/22 18:51, Simon Ser wrote:
> Very nice plan! Big +1 for the overall approach.

 Thanks.

> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
>  wrote:
>
>> The drm_connector brightness properties
>> ===
>>
>> bl_brightness: rw 0-int32_max property controlling the 
>> brightness setting
>> of the connected display. The actual maximum of this will be 
>> less then
>> int32_max and is given in bl_brightness_max.
>
> Do we need to split this up into two props for sw/hw state? The 
> privacy screen
> stuff needed this, but you're pretty familiar with that. :)

 Luckily that won't be necessary, since the privacy-screen is a 
 security
 feature the firmware/embedded-controller may refuse our requests
 (may temporarily lock-out changes) and/or may make changes without
 us requesting them itself. Neither is really the case with the
 brightness setting of displays.

>> bl_brightness_max: ro 0-int32_max property giving the actual 
>> maximum
>> of the display's brightness setting. This will report 0 when 
>> brightness
>> control is not available (yet).
>
> I don't think we actually need that one. Integer KMS props all 
> have a
> range which can be fetched via drmModeGetProperty. The max can be
> exposed via this range. Example with the existing alpha prop:
>
> "alpha": range [0, UINT16_MAX] = 65535

 Right, I already knew that, which is why I explicitly added a range
 to the props already. The problem is that the range must be set
 before registering the connector and when the backlight driver
 only shows up (much) later during boot then we don't know the
 range when registering the connector. I guess we could "patch-up"
 the range later. But AFAIK that would be a bit of abuse of the
 property API as the range is intended to never change, not
 even after hotplug uevents. At least atm there is no infra
 in the kernel to change the range later.

 Which is why I added an explicit bl_brightness_max property
 of which the value gives the actual effective maximum of the
 brightness.
>>
>> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
>> brightness control later on then we just perpetuate the nonsense we 
>> have
>> right now, forever.
>>
>> Imo we should support two kinds of drivers:
>>
>> - drivers which are non-crap, and make sure their backlight driver is
>>   loaded before they register the drm_device (or at least the
>>   drm_connector). For those we want the drm_connector->backlight 
>> pointer
>>   to bit static over the lifetime of the connector, and then we can 
>> also
>>   set up the brightness range correctly.
>>
>> - funny drivers which implement the glorious fallback dance which
>>   libbacklight implements currently in userspace. Imo for these 
>> drivers we
>>   should have a libbacklight_heuristics_backlight, which normalizes 
>> or
>>   whatever, and is also ways there. And then internally handles the
>>   fallback mess to the "right" backlight driver.
>>
>> We might have some gaps on acpi systems to make sure the drm driver 
>> can
>> wait for the backlight driver to show up, but that's about it.
>>
>> Hotplugging random pieces later on is really not how drivers work 
>> nowadays
>> with deferred probe and component framework and all that.

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

[Daniel Vetter]

On Wed, Apr 27, 2022 at 05:23:22PM +0300, Jani Nikula wrote:
> On Wed, 27 Apr 2022, Daniel Vetter  wrote:
> > On Thu, Apr 14, 2022 at 01:24:30PM +0300, Jani Nikula wrote:
> >> On Mon, 11 Apr 2022, Alex Deucher  wrote:
> >> > On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede  
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> On 4/8/22 17:11, Alex Deucher wrote:
> >> >> > On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> On 4/8/22 16:08, Alex Deucher wrote:
> >> >> >>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  
> >> >> >>> wrote:
> >> >> 
> >> >>  On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> >> >> > On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede 
> >> >> >  wrote:
> >> >> >>
> >> >> >> Hi Simon,
> >> >> >>
> >> >> >> On 4/7/22 18:51, Simon Ser wrote:
> >> >> >>> Very nice plan! Big +1 for the overall approach.
> >> >> >>
> >> >> >> Thanks.
> >> >> >>
> >> >> >>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> >> >> >>>  wrote:
> >> >> >>>
> >> >>  The drm_connector brightness properties
> >> >>  ===
> >> >> 
> >> >>  bl_brightness: rw 0-int32_max property controlling the 
> >> >>  brightness setting
> >> >>  of the connected display. The actual maximum of this will be 
> >> >>  less then
> >> >>  int32_max and is given in bl_brightness_max.
> >> >> >>>
> >> >> >>> Do we need to split this up into two props for sw/hw state? The 
> >> >> >>> privacy screen
> >> >> >>> stuff needed this, but you're pretty familiar with that. :)
> >> >> >>
> >> >> >> Luckily that won't be necessary, since the privacy-screen is a 
> >> >> >> security
> >> >> >> feature the firmware/embedded-controller may refuse our requests
> >> >> >> (may temporarily lock-out changes) and/or may make changes 
> >> >> >> without
> >> >> >> us requesting them itself. Neither is really the case with the
> >> >> >> brightness setting of displays.
> >> >> >>
> >> >>  bl_brightness_max: ro 0-int32_max property giving the actual 
> >> >>  maximum
> >> >>  of the display's brightness setting. This will report 0 when 
> >> >>  brightness
> >> >>  control is not available (yet).
> >> >> >>>
> >> >> >>> I don't think we actually need that one. Integer KMS props all 
> >> >> >>> have a
> >> >> >>> range which can be fetched via drmModeGetProperty. The max can 
> >> >> >>> be
> >> >> >>> exposed via this range. Example with the existing alpha prop:
> >> >> >>>
> >> >> >>> "alpha": range [0, UINT16_MAX] = 65535
> >> >> >>
> >> >> >> Right, I already knew that, which is why I explicitly added a 
> >> >> >> range
> >> >> >> to the props already. The problem is that the range must be set
> >> >> >> before registering the connector and when the backlight driver
> >> >> >> only shows up (much) later during boot then we don't know the
> >> >> >> range when registering the connector. I guess we could "patch-up"
> >> >> >> the range later. But AFAIK that would be a bit of abuse of the
> >> >> >> property API as the range is intended to never change, not
> >> >> >> even after hotplug uevents. At least atm there is no infra
> >> >> >> in the kernel to change the range later.
> >> >> >>
> >> >> >> Which is why I added an explicit bl_brightness_max property
> >> >> >> of which the value gives the actual effective maximum of the
> >> >> >> brightness.
> >> >> 
> >> >>  Uh ... I'm not a huge fan tbh. The thing is, if we allow 
> >> >>  hotplugging
> >> >>  brightness control later on then we just perpetuate the nonsense 
> >> >>  we have
> >> >>  right now, forever.
> >> >> 
> >> >>  Imo we should support two kinds of drivers:
> >> >> 
> >> >>  - drivers which are non-crap, and make sure their backlight driver 
> >> >>  is
> >> >>    loaded before they register the drm_device (or at least the
> >> >>    drm_connector). For those we want the drm_connector->backlight 
> >> >>  pointer
> >> >>    to bit static over the lifetime of the connector, and then we 
> >> >>  can also
> >> >>    set up the brightness range correctly.
> >> >> 
> >> >>  - funny drivers which implement the glorious fallback dance which
> >> >>    libbacklight implements currently in userspace. Imo for these 
> >> >>  drivers we
> >> >>    should have a libbacklight_heuristics_backlight, which 
> >> >>  normalizes or
> >> >>    whatever, and is also ways there. And then internally handles the
> >> >>    fallback mess to the "right" backlight driver.
> >> >> 
> >> >>  We might have some gaps on acpi systems to make sure the drm 
> >> >>  driver can
> >> >>  wait 

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

[Jani Nikula]

On Wed, 27 Apr 2022, Daniel Vetter  wrote:
> On Thu, Apr 14, 2022 at 01:24:30PM +0300, Jani Nikula wrote:
>> On Mon, 11 Apr 2022, Alex Deucher  wrote:
>> > On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede  wrote:
>> >>
>> >> Hi,
>> >>
>> >> On 4/8/22 17:11, Alex Deucher wrote:
>> >> > On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> On 4/8/22 16:08, Alex Deucher wrote:
>> >> >>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
>> >> 
>> >>  On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>> >> > On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  
>> >> > wrote:
>> >> >>
>> >> >> Hi Simon,
>> >> >>
>> >> >> On 4/7/22 18:51, Simon Ser wrote:
>> >> >>> Very nice plan! Big +1 for the overall approach.
>> >> >>
>> >> >> Thanks.
>> >> >>
>> >> >>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
>> >> >>>  wrote:
>> >> >>>
>> >>  The drm_connector brightness properties
>> >>  ===
>> >> 
>> >>  bl_brightness: rw 0-int32_max property controlling the 
>> >>  brightness setting
>> >>  of the connected display. The actual maximum of this will be 
>> >>  less then
>> >>  int32_max and is given in bl_brightness_max.
>> >> >>>
>> >> >>> Do we need to split this up into two props for sw/hw state? The 
>> >> >>> privacy screen
>> >> >>> stuff needed this, but you're pretty familiar with that. :)
>> >> >>
>> >> >> Luckily that won't be necessary, since the privacy-screen is a 
>> >> >> security
>> >> >> feature the firmware/embedded-controller may refuse our requests
>> >> >> (may temporarily lock-out changes) and/or may make changes without
>> >> >> us requesting them itself. Neither is really the case with the
>> >> >> brightness setting of displays.
>> >> >>
>> >>  bl_brightness_max: ro 0-int32_max property giving the actual 
>> >>  maximum
>> >>  of the display's brightness setting. This will report 0 when 
>> >>  brightness
>> >>  control is not available (yet).
>> >> >>>
>> >> >>> I don't think we actually need that one. Integer KMS props all 
>> >> >>> have a
>> >> >>> range which can be fetched via drmModeGetProperty. The max can be
>> >> >>> exposed via this range. Example with the existing alpha prop:
>> >> >>>
>> >> >>> "alpha": range [0, UINT16_MAX] = 65535
>> >> >>
>> >> >> Right, I already knew that, which is why I explicitly added a range
>> >> >> to the props already. The problem is that the range must be set
>> >> >> before registering the connector and when the backlight driver
>> >> >> only shows up (much) later during boot then we don't know the
>> >> >> range when registering the connector. I guess we could "patch-up"
>> >> >> the range later. But AFAIK that would be a bit of abuse of the
>> >> >> property API as the range is intended to never change, not
>> >> >> even after hotplug uevents. At least atm there is no infra
>> >> >> in the kernel to change the range later.
>> >> >>
>> >> >> Which is why I added an explicit bl_brightness_max property
>> >> >> of which the value gives the actual effective maximum of the
>> >> >> brightness.
>> >> 
>> >>  Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
>> >>  brightness control later on then we just perpetuate the nonsense we 
>> >>  have
>> >>  right now, forever.
>> >> 
>> >>  Imo we should support two kinds of drivers:
>> >> 
>> >>  - drivers which are non-crap, and make sure their backlight driver is
>> >>    loaded before they register the drm_device (or at least the
>> >>    drm_connector). For those we want the drm_connector->backlight 
>> >>  pointer
>> >>    to bit static over the lifetime of the connector, and then we can 
>> >>  also
>> >>    set up the brightness range correctly.
>> >> 
>> >>  - funny drivers which implement the glorious fallback dance which
>> >>    libbacklight implements currently in userspace. Imo for these 
>> >>  drivers we
>> >>    should have a libbacklight_heuristics_backlight, which normalizes 
>> >>  or
>> >>    whatever, and is also ways there. And then internally handles the
>> >>    fallback mess to the "right" backlight driver.
>> >> 
>> >>  We might have some gaps on acpi systems to make sure the drm driver 
>> >>  can
>> >>  wait for the backlight driver to show up, but that's about it.
>> >> 
>> >>  Hotplugging random pieces later on is really not how drivers work 
>> >>  nowadays
>> >>  with deferred probe and component framework and all that.
>> >> 
>> >> >> I did consider using the range for this and updating it
>> >> >> on the fly I think nothing is 

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

[Daniel Vetter]

On Thu, Apr 14, 2022 at 01:24:30PM +0300, Jani Nikula wrote:
> On Mon, 11 Apr 2022, Alex Deucher  wrote:
> > On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede  wrote:
> >>
> >> Hi,
> >>
> >> On 4/8/22 17:11, Alex Deucher wrote:
> >> > On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> On 4/8/22 16:08, Alex Deucher wrote:
> >> >>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
> >> 
> >>  On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> >> > On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  
> >> > wrote:
> >> >>
> >> >> Hi Simon,
> >> >>
> >> >> On 4/7/22 18:51, Simon Ser wrote:
> >> >>> Very nice plan! Big +1 for the overall approach.
> >> >>
> >> >> Thanks.
> >> >>
> >> >>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> >> >>>  wrote:
> >> >>>
> >>  The drm_connector brightness properties
> >>  ===
> >> 
> >>  bl_brightness: rw 0-int32_max property controlling the brightness 
> >>  setting
> >>  of the connected display. The actual maximum of this will be less 
> >>  then
> >>  int32_max and is given in bl_brightness_max.
> >> >>>
> >> >>> Do we need to split this up into two props for sw/hw state? The 
> >> >>> privacy screen
> >> >>> stuff needed this, but you're pretty familiar with that. :)
> >> >>
> >> >> Luckily that won't be necessary, since the privacy-screen is a 
> >> >> security
> >> >> feature the firmware/embedded-controller may refuse our requests
> >> >> (may temporarily lock-out changes) and/or may make changes without
> >> >> us requesting them itself. Neither is really the case with the
> >> >> brightness setting of displays.
> >> >>
> >>  bl_brightness_max: ro 0-int32_max property giving the actual 
> >>  maximum
> >>  of the display's brightness setting. This will report 0 when 
> >>  brightness
> >>  control is not available (yet).
> >> >>>
> >> >>> I don't think we actually need that one. Integer KMS props all 
> >> >>> have a
> >> >>> range which can be fetched via drmModeGetProperty. The max can be
> >> >>> exposed via this range. Example with the existing alpha prop:
> >> >>>
> >> >>> "alpha": range [0, UINT16_MAX] = 65535
> >> >>
> >> >> Right, I already knew that, which is why I explicitly added a range
> >> >> to the props already. The problem is that the range must be set
> >> >> before registering the connector and when the backlight driver
> >> >> only shows up (much) later during boot then we don't know the
> >> >> range when registering the connector. I guess we could "patch-up"
> >> >> the range later. But AFAIK that would be a bit of abuse of the
> >> >> property API as the range is intended to never change, not
> >> >> even after hotplug uevents. At least atm there is no infra
> >> >> in the kernel to change the range later.
> >> >>
> >> >> Which is why I added an explicit bl_brightness_max property
> >> >> of which the value gives the actual effective maximum of the
> >> >> brightness.
> >> 
> >>  Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
> >>  brightness control later on then we just perpetuate the nonsense we 
> >>  have
> >>  right now, forever.
> >> 
> >>  Imo we should support two kinds of drivers:
> >> 
> >>  - drivers which are non-crap, and make sure their backlight driver is
> >>    loaded before they register the drm_device (or at least the
> >>    drm_connector). For those we want the drm_connector->backlight 
> >>  pointer
> >>    to bit static over the lifetime of the connector, and then we can 
> >>  also
> >>    set up the brightness range correctly.
> >> 
> >>  - funny drivers which implement the glorious fallback dance which
> >>    libbacklight implements currently in userspace. Imo for these 
> >>  drivers we
> >>    should have a libbacklight_heuristics_backlight, which normalizes or
> >>    whatever, and is also ways there. And then internally handles the
> >>    fallback mess to the "right" backlight driver.
> >> 
> >>  We might have some gaps on acpi systems to make sure the drm driver 
> >>  can
> >>  wait for the backlight driver to show up, but that's about it.
> >> 
> >>  Hotplugging random pieces later on is really not how drivers work 
> >>  nowadays
> >>  with deferred probe and component framework and all that.
> >> 
> >> >> I did consider using the range for this and updating it
> >> >> on the fly I think nothing is really preventing us from
> >> >> doing so, but it very much feels like abusing the generic
> >> >> properties API.
> >> >>
> >>  

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

[Jani Nikula]

On Thu, 07 Apr 2022, Hans de Goede  wrote:
> As discussed already several times in the past:
>  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
>  
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
>
> The current userspace API for brightness control offered by
> /sys/class/backlight devices has various issues, the biggest 2 being:
>
> 1. There is no way to map the backlight device to a specific
>display-output / panel (1)
> 2. Controlling the brightness requires root-rights requiring
>desktop-environments to use suid-root helpers for this.
>
> As already discussed on various conference's hallway tracks
> and as has been proposed on the dri-devel list once before (2),
> it seems that there is consensus that the best way to to solve these
> 2 issues is to add support for controlling a video-output's brightness
> through properties on the drm_connector.
>
> This RFC outlines my plan to try and actually implement this,
> which has 3 phases:
>
>
> Phase 1: Stop registering multiple /sys/class/backlight devs for a single 
> display
> =
>
> On x86 there can be multiple firmware + direct-hw-access methods
> for controlling the backlight and in some cases the kernel registers
> multiple backlight-devices for a single internal laptop LCD panel:
>
> a) i915 and nouveau unconditionally register their "native" backlight dev
>even on devices where /sys/class/backlight/acpi_video0 must be used
>to control the backlight, relying on userspace to prefer the "firmware"
>acpi_video0 device over "native" devices.
> b) amdgpu and nouveau rely on the acpi_video driver initializing before
>them, which currently causes /sys/class/backlight/acpi_video0 to usually
>show up and then they register their own native backlight driver after
>which the drivers/acpi/video_detect.c code unregisters the acpi_video0
>device. This means that userspace briefly sees 2 devices and the
>disappearing of acpi_video0 after a brief time confuses the systemd
>backlight level save/restore code, see e.g.:
>https://bbs.archlinux.org/viewtopic.php?id=269920
>
> I already have a pretty detailed plan to tackle this, which I will
> post in a separate RFC email. I plan to start working on this right
> away, as it will be good to have this fixed regardless.
>
>
> Phase 2: Add drm_connector properties mirroring the matching backlight device
> =
>
> The plan is to add a drm_connector helper function, which optionally takes
> a pointer to the backlight device for the GPU's native backlight device,
> which will then mirror the backlight settings from the backlight device
> in a set of read/write brightness* properties on the connector.
>
> This function can then be called by GPU drivers for the drm_connector for
> the internal panel and it will then take care of everything. When there
> is no native GPU backlight device, or when it should not be used then
> (on x86) the helper will use the acpi_video_get_backlight_type() to
> determine which backlight-device should be used instead and it will find
> + mirror that one.
>
>
> Phase 3: Deprecate /sys/class/backlight uAPI
> 
>
> Once most userspace has moved over to using the new drm_connector
> brightness props, a Kconfig option can be added to stop exporting
> the backlight-devices under /sys/class/backlight. The plan is to
> just disable the sysfs interface and keep the existing backlight-device
> internal kernel abstraction as is, since some abstraction for (non GPU
> native) backlight devices will be necessary regardless.
>
> An alternative to disabling the sysfs class entirely, would be
> to allow setting it to read-only through Kconfig.
>
>
> What scale to use for the drm_connector bl_brightness property?
> ===
>
> The tricky part of this plan is phase 2 and then esp. defining what the
> new brightness properties will look like and how they will work.
>
> The biggest challenge here is to decide on a fixed scale for the main
> brightness property, say 0-65535, using scaling where the actual hw scale
> is different, or if this should simply be a 1:1 mirror of the current
> backlight interface, with the actual hw scale / brightness_max value
> exposed as a drm_connector property.
>
> 1:1 advantages / 0-65535 disadvantages
> - Userspace will likely move over to the connector-props quite slowly and
>   we can expect various userspace bits, esp. also custom user scripts, to
>   keep using the old uAPI for a long time. Using the 2 APIs are intermixed
>   is fine when using a 1:1 brightness scale mapping. But if we end up doing
>   a scaling round-trip all the time then eventually the brightness is going
>   do drift. This can even happen if the user never changes the 

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

[Jani Nikula]

On Mon, 11 Apr 2022, Alex Deucher  wrote:
> On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 4/8/22 17:11, Alex Deucher wrote:
>> > On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:
>> >>
>> >> Hi,
>> >>
>> >> On 4/8/22 16:08, Alex Deucher wrote:
>> >>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
>> 
>>  On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>> > On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  
>> > wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> On 4/7/22 18:51, Simon Ser wrote:
>> >>> Very nice plan! Big +1 for the overall approach.
>> >>
>> >> Thanks.
>> >>
>> >>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
>> >>>  wrote:
>> >>>
>>  The drm_connector brightness properties
>>  ===
>> 
>>  bl_brightness: rw 0-int32_max property controlling the brightness 
>>  setting
>>  of the connected display. The actual maximum of this will be less 
>>  then
>>  int32_max and is given in bl_brightness_max.
>> >>>
>> >>> Do we need to split this up into two props for sw/hw state? The 
>> >>> privacy screen
>> >>> stuff needed this, but you're pretty familiar with that. :)
>> >>
>> >> Luckily that won't be necessary, since the privacy-screen is a 
>> >> security
>> >> feature the firmware/embedded-controller may refuse our requests
>> >> (may temporarily lock-out changes) and/or may make changes without
>> >> us requesting them itself. Neither is really the case with the
>> >> brightness setting of displays.
>> >>
>>  bl_brightness_max: ro 0-int32_max property giving the actual maximum
>>  of the display's brightness setting. This will report 0 when 
>>  brightness
>>  control is not available (yet).
>> >>>
>> >>> I don't think we actually need that one. Integer KMS props all have a
>> >>> range which can be fetched via drmModeGetProperty. The max can be
>> >>> exposed via this range. Example with the existing alpha prop:
>> >>>
>> >>> "alpha": range [0, UINT16_MAX] = 65535
>> >>
>> >> Right, I already knew that, which is why I explicitly added a range
>> >> to the props already. The problem is that the range must be set
>> >> before registering the connector and when the backlight driver
>> >> only shows up (much) later during boot then we don't know the
>> >> range when registering the connector. I guess we could "patch-up"
>> >> the range later. But AFAIK that would be a bit of abuse of the
>> >> property API as the range is intended to never change, not
>> >> even after hotplug uevents. At least atm there is no infra
>> >> in the kernel to change the range later.
>> >>
>> >> Which is why I added an explicit bl_brightness_max property
>> >> of which the value gives the actual effective maximum of the
>> >> brightness.
>> 
>>  Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
>>  brightness control later on then we just perpetuate the nonsense we have
>>  right now, forever.
>> 
>>  Imo we should support two kinds of drivers:
>> 
>>  - drivers which are non-crap, and make sure their backlight driver is
>>    loaded before they register the drm_device (or at least the
>>    drm_connector). For those we want the drm_connector->backlight pointer
>>    to bit static over the lifetime of the connector, and then we can also
>>    set up the brightness range correctly.
>> 
>>  - funny drivers which implement the glorious fallback dance which
>>    libbacklight implements currently in userspace. Imo for these drivers 
>>  we
>>    should have a libbacklight_heuristics_backlight, which normalizes or
>>    whatever, and is also ways there. And then internally handles the
>>    fallback mess to the "right" backlight driver.
>> 
>>  We might have some gaps on acpi systems to make sure the drm driver can
>>  wait for the backlight driver to show up, but that's about it.
>> 
>>  Hotplugging random pieces later on is really not how drivers work 
>>  nowadays
>>  with deferred probe and component framework and all that.
>> 
>> >> I did consider using the range for this and updating it
>> >> on the fly I think nothing is really preventing us from
>> >> doing so, but it very much feels like abusing the generic
>> >> properties API.
>> >>
>>  bl_brightness_0_is_min_brightness: ro, boolean
>>  When this is set to true then it is safe to set brightness to 0
>>  without worrying that this completely turns the backlight off 
>>  causing
>>  the screen to become unreadable. When this is false setting 
>>  brightness
>>  to 0 may turn the backlight off, but this 

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

[Hans de Goede]

Hi,

On 4/13/22 10:32, Daniel Vetter wrote:
> On Fri, Apr 08, 2022 at 12:26:24PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/8/22 12:16, Simon Ser wrote:
>>> Would it be an option to only support the KMS prop for Good devices,
>>> and continue using the suboptimal existing sysfs API for Bad devices?
>>>
>>> (I'm just throwing ideas around to see what sticks, feel free to ignore.)
>>
>> Currently suid-root or pkexec helpers are used to deal with the
>> /sys/class/backlight requires root rights issue. I really want to
>> be able to disable these helpers at build time in e.g. GNOME once
>> the new properties are supported in GNOME.  So that distros with
>> a new enough kernel can reduce their attack surface this way.
> 
> Yeah but otoh perpetuating a bad interface forever isn't a great idea
> either. I think the pragmatic plan here is
> - Implement this properly on good devices, i.e. anything new.
> - Do some runtime disabling in the pkexec helpers if they detect a modern
>   system (we should be able to put a proper symlink into the drm sysfs
>   connector directories, to make this easy to detect). It's not as great
>   as doing this at compile time, but it's a step.
> - Figure out a solution for the old crap. We can't really change anything
>   with the load ordering for existing systems, so if the hacked-up compat
>   libbacklight-backlight isn't an option then I guess we need some quirk
>   list/extracted code which makes i915/nouveau/radeon driver load fail
>   until the right backlight shows up. And that needs to be behind a
>   Kconfig to avoid breaking existing systems.
> 
> Inflicting hotplug complications on all userspace (including uevent
> handling for this hotpluggable backlight and everything) just because
> fixing the old crap systems is work is imo really not a good idea. Much
> better if we get to the correct future step-by-step.

This assumes that we only use the new brightness properties for laptop
internal LCD panels.

But what about controlling the brightness of external monitors through
DDC/CI? If we do that we need hotplug support for this regardless since
external monitors can be hotplugged.

As I mentioned in other parts of the thread one of the reasons why
I've started looking into this again is because of people being
interested in this (1).

And even just taking internal LCD panels into account, there are
hybrid GPU laptops where the backlight is directly controlled by
the GPU (native type backlight driver) connected to the panel(2),
if we runtime switch the GPU attached to the panel there, then we
will get an actual hotplug of the LCD connector and I'm not sure if
we can always detect the maximum value of the brightness on the GPU
which is not connected to the panel at boot. So in this case we
need userspace to support re-reading the brightness max at
a hotplug event regardless.

So in all in all I feel that supporting hotplug events is
unavoidable here.

Regards,

Hans


1) Including attempting to do this through the old /sys/class/backlight
interface which IMHO would be quite bad to do:
https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/

2) E.g. gnome-settings-daemon has special code to detect which native
backlight interface to use if there are 2 native backlight devices on
a single laptop, see:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/power/gsd-backlight.c#L95

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

[Simon Ser]

On Wednesday, April 13th, 2022 at 10:32, Daniel Vetter  wrote:

> Inflicting hotplug complications on all userspace (including uevent
> handling for this hotpluggable backlight and everything) just because
> fixing the old crap systems is work is imo really not a good idea. Much
> better if we get to the correct future step-by-step.

Yup, I fully agree. As a user-space dev I'm perfectly fine with an API
only available on some systems as a first step.

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

[Daniel Vetter]

On Fri, Apr 08, 2022 at 12:26:24PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 4/8/22 12:16, Simon Ser wrote:
> > Would it be an option to only support the KMS prop for Good devices,
> > and continue using the suboptimal existing sysfs API for Bad devices?
> > 
> > (I'm just throwing ideas around to see what sticks, feel free to ignore.)
> 
> Currently suid-root or pkexec helpers are used to deal with the
> /sys/class/backlight requires root rights issue. I really want to
> be able to disable these helpers at build time in e.g. GNOME once
> the new properties are supported in GNOME.  So that distros with
> a new enough kernel can reduce their attack surface this way.

Yeah but otoh perpetuating a bad interface forever isn't a great idea
either. I think the pragmatic plan here is
- Implement this properly on good devices, i.e. anything new.
- Do some runtime disabling in the pkexec helpers if they detect a modern
  system (we should be able to put a proper symlink into the drm sysfs
  connector directories, to make this easy to detect). It's not as great
  as doing this at compile time, but it's a step.
- Figure out a solution for the old crap. We can't really change anything
  with the load ordering for existing systems, so if the hacked-up compat
  libbacklight-backlight isn't an option then I guess we need some quirk
  list/extracted code which makes i915/nouveau/radeon driver load fail
  until the right backlight shows up. And that needs to be behind a
  Kconfig to avoid breaking existing systems.

Inflicting hotplug complications on all userspace (including uevent
handling for this hotpluggable backlight and everything) just because
fixing the old crap systems is work is imo really not a good idea. Much
better if we get to the correct future step-by-step.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[Mikhail Gusarov]

On 11 Apr 2022, at 13:50, Hans de Goede wrote:

> The problem is we already lack the manpower for a quirk database,
> and even if we ever get the manpower then it would still be good
> to avoid the work necessary to add models to the database where
> the kernel already knows how things work, see below.

I wonder how Windows developers solve this problem, and do they at all?

Best,
Mikhail.

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

[Alex Deucher]

On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede  wrote:
>
> Hi,
>
> On 4/8/22 17:11, Alex Deucher wrote:
> > On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:
> >>
> >> Hi,
> >>
> >> On 4/8/22 16:08, Alex Deucher wrote:
> >>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
> 
>  On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> > On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  
> > wrote:
> >>
> >> Hi Simon,
> >>
> >> On 4/7/22 18:51, Simon Ser wrote:
> >>> Very nice plan! Big +1 for the overall approach.
> >>
> >> Thanks.
> >>
> >>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> >>>  wrote:
> >>>
>  The drm_connector brightness properties
>  ===
> 
>  bl_brightness: rw 0-int32_max property controlling the brightness 
>  setting
>  of the connected display. The actual maximum of this will be less 
>  then
>  int32_max and is given in bl_brightness_max.
> >>>
> >>> Do we need to split this up into two props for sw/hw state? The 
> >>> privacy screen
> >>> stuff needed this, but you're pretty familiar with that. :)
> >>
> >> Luckily that won't be necessary, since the privacy-screen is a security
> >> feature the firmware/embedded-controller may refuse our requests
> >> (may temporarily lock-out changes) and/or may make changes without
> >> us requesting them itself. Neither is really the case with the
> >> brightness setting of displays.
> >>
>  bl_brightness_max: ro 0-int32_max property giving the actual maximum
>  of the display's brightness setting. This will report 0 when 
>  brightness
>  control is not available (yet).
> >>>
> >>> I don't think we actually need that one. Integer KMS props all have a
> >>> range which can be fetched via drmModeGetProperty. The max can be
> >>> exposed via this range. Example with the existing alpha prop:
> >>>
> >>> "alpha": range [0, UINT16_MAX] = 65535
> >>
> >> Right, I already knew that, which is why I explicitly added a range
> >> to the props already. The problem is that the range must be set
> >> before registering the connector and when the backlight driver
> >> only shows up (much) later during boot then we don't know the
> >> range when registering the connector. I guess we could "patch-up"
> >> the range later. But AFAIK that would be a bit of abuse of the
> >> property API as the range is intended to never change, not
> >> even after hotplug uevents. At least atm there is no infra
> >> in the kernel to change the range later.
> >>
> >> Which is why I added an explicit bl_brightness_max property
> >> of which the value gives the actual effective maximum of the
> >> brightness.
> 
>  Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
>  brightness control later on then we just perpetuate the nonsense we have
>  right now, forever.
> 
>  Imo we should support two kinds of drivers:
> 
>  - drivers which are non-crap, and make sure their backlight driver is
>    loaded before they register the drm_device (or at least the
>    drm_connector). For those we want the drm_connector->backlight pointer
>    to bit static over the lifetime of the connector, and then we can also
>    set up the brightness range correctly.
> 
>  - funny drivers which implement the glorious fallback dance which
>    libbacklight implements currently in userspace. Imo for these drivers 
>  we
>    should have a libbacklight_heuristics_backlight, which normalizes or
>    whatever, and is also ways there. And then internally handles the
>    fallback mess to the "right" backlight driver.
> 
>  We might have some gaps on acpi systems to make sure the drm driver can
>  wait for the backlight driver to show up, but that's about it.
> 
>  Hotplugging random pieces later on is really not how drivers work 
>  nowadays
>  with deferred probe and component framework and all that.
> 
> >> I did consider using the range for this and updating it
> >> on the fly I think nothing is really preventing us from
> >> doing so, but it very much feels like abusing the generic
> >> properties API.
> >>
>  bl_brightness_0_is_min_brightness: ro, boolean
>  When this is set to true then it is safe to set brightness to 0
>  without worrying that this completely turns the backlight off causing
>  the screen to become unreadable. When this is false setting 
>  brightness
>  to 0 may turn the backlight off, but this is not guaranteed.
>  This will e.g. be true when directly driving a PWM and the video-BIOS
>  has provided a minimum (non 0) duty-cycle below which the driver 

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

[Hans de Goede]

Hi Pekka,

On 4/11/22 13:34, Pekka Paalanen wrote:
> On Mon, 11 Apr 2022 12:18:30 +0200
> Hans de Goede  wrote:
> 
>> Hi,
>>
>> On 4/8/22 17:11, Alex Deucher wrote:
>>> On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:  

> 
> ...
> 
>>> So set it to a level we can guarantee can call it 0.  If we have the
>>> flag we are just punting on the problem in my opinion.  
>>
>> Right this an impossible problem to solve so the intent is indeed
>> to punt this to userspace, which IMHO is the best thing we can do
>> here.  The idea behind the "bl_brightness_0_is_min_brightness:
>> ro, boolean" property is to provide a hint to userspace to help
>> userspace deal with this (and if userspace ends up using e.g.
>> systemd's hwdb for this to avoid unnecessary entries in hwdb).
>>
>>>  The kernel
>>> driver would seem to have a better idea what is a valid minimum than
>>> some arbitrary userspace application.  
>>
>> If the kernel driver knows the valid minimum then it can make 0
>> actually be that valid minimum as you suggest and it can set the
>> hint flag to let userspace know this. OTOH there are many cases
>> where the kernel's guess is just as bad as userspace's guess and
>> there are too many laptops where this is the case to quirk
>> ourselves out of this situation.
>>
>>> Plus then if we need a
>>> workaround for what is the minimum valid brightness, we can fix it one
>>> place rather than letting every application try and fix it.  
>>
>> I wish we could solve this in the kernel, but at least on
>> laptops with Intel integrated gfx many vendors don't bother
>> to put a non 0 value in the minimum duty-cycle field of the
>> VBT, so there really is no good way to solve this.
>>
>> If the userspace folks ever want to do a database for this,
>> I would expect them to do something with hwdb + udev which
>> can then be shared between the different desktop-environments.
> 
> Hi Hans,
> 
> assuming that it is impossible to reach a reasonable user experience by
> having a quirk database in the kernel in order to offer a consistent
> definition of bl_brightness=0, then should you not be recommending a
> userspace hwdb solution with full steam, rather than adding a hint in
> the kernel that might be just enough to have no-one ever bother
> investing in a proper solution?

The problem is we already lack the manpower for a quirk database,
and even if we ever get the manpower then it would still be good
to avoid the work necessary to add models to the database where
the kernel already knows how things work, see below.

As for no-one ever bothering coming up with a full-steam hwdb
solution for the cases where the kernel has no idea what
bl_brightness=0 means, yes that is likely, but that already
is the status quo, the hint will at least allow using the
full brightness range on devices where the kernel knows
(with certainty) that this is correct.

> Re-reading your "bl_brightness_0_is_min_brightness" definition, it
> seems to be specified as exposing a certain condition in the system.
> When it is true, you imply that userspace can safely use value 0 as min
> brightness, but that is assuming the hint is correct. How likely
> is the hint incorrect?

It should never be incorrect, there are cases when the kernel knows
reliably that bl_brightness=0 means minimum brightness
(and NOT backlight off).

> If the hint can be incorrect, does this hint
> actually give anything to userspace, or would userspace still choose to
> be safer than sorry and ignore the hint by assuming the worst?

If the hint is incorrect then that would be a kernel bug and that
should be fixed in the kernel. The whole idea behind the hind is
that userspace can absolutely trust it to be correct when set to true
(false basically means that the kernel does not know of 0=off or not).

> Is this situation much different to the quirk database libinput needs
> to work beautifully out of the box?

libinput's quirk database is relatively pretty small and a lot
of effort is done to fix things in generic ways where possible,
to avoid growing it.

As a general rule quirks should only be used to handle exceptions
to general rules, the problem here is that bl_brightness=0 being
backlight off is not a true exception it happens quite often.

Which is also why I believe that a hwdb for this is not necessarily
a great idea, because maintaining it will be a lot of work.

> Should desktop environments offer a couple more "advanced
> configuration" knobs for the lowest safe brightness value and the
> value-to-perceived brightness mapping to calibrate the familiar
> brightness slider? E.g. something like "click this button as soon as
> you see it on the display" for finding the lowest usable brightness,
> with defaults coming from a database.

Maybe, but that would defeat all the attempts done to make Linux
on the desktop just work.

> If the situation is as grim as you say, I would propose to drop
> "bl_brightness_0_is_min_brightness" (and
> "bl_brightness_control_method"), 

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

[Pekka Paalanen]

On Mon, 11 Apr 2022 12:18:30 +0200
Hans de Goede  wrote:

> Hi,
> 
> On 4/8/22 17:11, Alex Deucher wrote:
> > On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:  
> >>

...

> > So set it to a level we can guarantee can call it 0.  If we have the
> > flag we are just punting on the problem in my opinion.  
> 
> Right this an impossible problem to solve so the intent is indeed
> to punt this to userspace, which IMHO is the best thing we can do
> here.  The idea behind the "bl_brightness_0_is_min_brightness:
> ro, boolean" property is to provide a hint to userspace to help
> userspace deal with this (and if userspace ends up using e.g.
> systemd's hwdb for this to avoid unnecessary entries in hwdb).
> 
> >  The kernel
> > driver would seem to have a better idea what is a valid minimum than
> > some arbitrary userspace application.  
> 
> If the kernel driver knows the valid minimum then it can make 0
> actually be that valid minimum as you suggest and it can set the
> hint flag to let userspace know this. OTOH there are many cases
> where the kernel's guess is just as bad as userspace's guess and
> there are too many laptops where this is the case to quirk
> ourselves out of this situation.
> 
> > Plus then if we need a
> > workaround for what is the minimum valid brightness, we can fix it one
> > place rather than letting every application try and fix it.  
> 
> I wish we could solve this in the kernel, but at least on
> laptops with Intel integrated gfx many vendors don't bother
> to put a non 0 value in the minimum duty-cycle field of the
> VBT, so there really is no good way to solve this.
> 
> If the userspace folks ever want to do a database for this,
> I would expect them to do something with hwdb + udev which
> can then be shared between the different desktop-environments.

Hi Hans,

assuming that it is impossible to reach a reasonable user experience by
having a quirk database in the kernel in order to offer a consistent
definition of bl_brightness=0, then should you not be recommending a
userspace hwdb solution with full steam, rather than adding a hint in
the kernel that might be just enough to have no-one ever bother
investing in a proper solution?

Re-reading your "bl_brightness_0_is_min_brightness" definition, it
seems to be specified as exposing a certain condition in the system.
When it is true, you imply that userspace can safely use value 0 as min
brightness, but that is assuming the hint is correct. How likely
is the hint incorrect? If the hint can be incorrect, does this hint
actually give anything to userspace, or would userspace still choose to
be safer than sorry and ignore the hint by assuming the worst?

Is this situation much different to the quirk database libinput needs
to work beautifully out of the box?

Should desktop environments offer a couple more "advanced
configuration" knobs for the lowest safe brightness value and the
value-to-perceived brightness mapping to calibrate the familiar
brightness slider? E.g. something like "click this button as soon as
you see it on the display" for finding the lowest usable brightness,
with defaults coming from a database.

If the situation is as grim as you say, I would propose to drop
"bl_brightness_0_is_min_brightness" (and
"bl_brightness_control_method"), and document the dangers of using too
low brightness values. Maybe also start looking for a project that
would be appropriate for hosting such a database, just to point people
to cooperate in a single place rather than each DE coming up with their
own.


Thanks,
pq


pgpgHSPha6aFY.pgp
Description: OpenPGP digital signature

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

[Carsten Haitzler]

On Mon, 11 Apr 2022 12:27:37 +0200 Hans de Goede  said:

> Hi,
> 
> On 4/7/22 20:58, Carsten Haitzler wrote:
> > On Thu, 7 Apr 2022 17:38:59 +0200 Hans de Goede  said:
> > 
> > Below you covered our usual /sys/class/backlight device friends... what
> > about DDC monitor controls? These function similarly but just remotely
> > control a screen via I2C and also suffer from the same problems of "need
> > root" and "have to do some fun in mapping them to a given screen".
> 
> Right, supporting this definitely is part of the plan, this is why my original
> email had the following footnote:

Yay!

> 1) The need to be able to map the backlight device to a specific display
> has become clear once more with the recent proposal to add DDCDI support:
> https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/

Oh gee - I missed that. my bad!

> :)
>  
> > Otherwise I welcome this de-uglification of the backlight device and
> > putting it together with the drm device that controls that monitor.
> 
> Thx.

Having to deal with the backlight device madness is a big pain (have already
done it - DDC included) and properly exposing these things attached to the
proper KMS device is absolutely the right thing. Admittedly this punts the job
of matching a backlight device to the right video output in KMS to the kernel
so at least it gets solved in one place rather than it being re-invented again
and again per wm/desktop/compositor.

> > Just to make life more fun ... DDC does much more than backlight controls.
> > It can control essentially anything that is in the OSD for your monitor
> > (contrast, brightness, backlight, sharpness, color temperatures, input to
> > display (DP vs HDMI vs DVI etc.), an for extra fun points can even tel you
> > the current rotation state of your monitor. All of these do make sense to
> > live as drm connector properties too. Perhaps not a first iteration but
> > something to consider in this design.
> 
> One thing which I do want to take into account is to make sure that userspace
> can still do DDC/CI for all the other features. I know there is demand for
> adding brightness control over DDC/CI. I'm not aware of any concrete use-cases
> for the other DDC/CI settings. Also DDC/CI can include some pretty crazy
> stuff like setting up picture in picture using 2 different inputs of the
> monitor, which is very vendor specific. So all in all I think that we should
> just punt most of the DDC/CI stuff to userspace.

Having spent some time with DDC you're right - it can have some interesting
properties, but a wide number seem to be highly common between monitors and
make total sense to regularly use if available. Backlight/brightness is just
the immediate focus here.

> With that said I agree that it would be good to think about possibly other
> some of the other settings in case some use-case does show up for those.
> 
> The biggest problem with doing this is coming up with some prefix to
> namespace things. I've gone with bl_brightness to avoid a conflict
> with the existing TV specific properties which have plain "brightness"
> put if we want to e.g. also add DDC/CI contrast as a property later
> then it might be good to come up with another more generic prefix
> which can be shared between laptop-panel-brightness, DDC/CI-brightness
> and DDC/CI-contrast ... ?
> 
> So any suggestions for a better prefix?

Well here is my take. Have DDC properties separate from a build-in backlight
device. Userspace code will have to essentially do something like:

if (built_in_backlight_exists(output)) // built in backlight device
  set_backlight_brightness(output, val);
else if (ddc_prop_exists(output, 0x10)) // 0x10 is ddc brightness/backlight
  set_ddc_int_val(output, 0x10, val);
else // fallback for ye olde setuid tooling
  { ...
  }

DDC properties are quite simple in essence so just exposing the set so you can
read/write them (and check if they exist at all) would do the right thing - tie
DDC to the output visa KMS, (you still could use I2C directly if you like and
go behind KMS's back) but it'd then punt the policy decision of which
properties are common/sane to userspace without adding a possibly "endless" set
of "let's now adopt/abstract this DDC property" discussions. Wayland
compositors can adopts the properties they see as most useful for their uses.
Xorg could expose them via XRR output properties. So my take at least is to give
DDC it's own property namespace/set that allows an arbitrary set of numbered
properties and leave it pretty raw.

> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> > 
> >> As discussed already several times in the past:
> >>  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
> >>  
> >> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> >>
> >> The current userspace API for brightness control offered by
> >> /sys/class/backlight devices has various issues, the biggest 2 being:
> >>
> >> 1. There is no way to map the backlight 

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

[Hans de Goede]

Hi Simon,

On 4/8/22 10:22, Simon Ser wrote:
> Hi Hans,
> 
> Thanks for your details replies!
> 
> On Thursday, April 7th, 2022 at 19:43, Hans de Goede  
> wrote:
> 
>>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
>>> wrote:
>>>
 The drm_connector brightness properties
 ===

 bl_brightness: rw 0-int32_max property controlling the brightness setting
 of the connected display. The actual maximum of this will be less then
 int32_max and is given in bl_brightness_max.
>>>
>>> Do we need to split this up into two props for sw/hw state? The privacy 
>>> screen
>>> stuff needed this, but you're pretty familiar with that. :)
>>
>> Luckily that won't be necessary, since the privacy-screen is a security
>> feature the firmware/embedded-controller may refuse our requests
>> (may temporarily lock-out changes) and/or may make changes without
>> us requesting them itself. Neither is really the case with the
>> brightness setting of displays.
> 
> Cool, makes sense to me!
> 
 bl_brightness_max: ro 0-int32_max property giving the actual maximum
 of the display's brightness setting. This will report 0 when brightness
 control is not available (yet).
>>>
>>> I don't think we actually need that one. Integer KMS props all have a
>>> range which can be fetched via drmModeGetProperty. The max can be
>>> exposed via this range. Example with the existing alpha prop:
>>>
>>> "alpha": range [0, UINT16_MAX] = 65535
>>
>> Right, I already knew that, which is why I explicitly added a range
>> to the props already. The problem is that the range must be set
>> before registering the connector and when the backlight driver
>> only shows up (much) later during boot then we don't know the
>> range when registering the connector. I guess we could "patch-up"
>> the range later. But AFAIK that would be a bit of abuse of the
>> property API as the range is intended to never change, not
>> even after hotplug uevents. At least atm there is no infra
>> in the kernel to change the range later.
>>
>> Which is why I added an explicit bl_brightness_max property
>> of which the value gives the actual effective maximum of the
>> brightness.
>>
>> I did consider using the range for this and updating it
>> on the fly I think nothing is really preventing us from
>> doing so, but it very much feels like abusing the generic
>> properties API.
> 
> Since this is new uAPI there's no concern about backwards compat here. So it's
> pretty much a matter of how we want the uAPI to look like. I was suggesting
> using a range because it's self-describing, but maybe it's an abuse.
> 
> Daniel Vetter, what do you think? If a property's range is going to be updated
> on the fly, should we go for it, or should we use a separate prop to describe
> the max value?

Daniel, as explained in my replies to you, I do believe that dynamically
updating the range is unavoidable. Especially once we also add support
for setting a monitor's brightness over DDC/CI.

Since external monitors (with/without DDC/CI support) can come and go and
since properties cannot be added/removed after connector registration, we
need a way to let userspace know if brightness control is actually available
or not and what the range is. We can use a max value of 0 for not available
and other values for the actual range, which I believe is a sane API.

But the question from Simon then still remains, do we update the range
of the property on the fly, followed by a connector hotplug uevent; or
do we use a separate brightness_max property for this?

Note that as Rasterman indicated that with DDC/CI support we could also
offer other properties (for which I see no reason atm) and if we do
say also add a contrast property over DDC/CI then if we go the
separate brightness_max route that would mean adding 2 props for
each setting which we want to support.

Regards,

Hans

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

[Hans de Goede]

Hi,

On 4/7/22 20:58, Carsten Haitzler wrote:
> On Thu, 7 Apr 2022 17:38:59 +0200 Hans de Goede  said:
> 
> Below you covered our usual /sys/class/backlight device friends... what about
> DDC monitor controls? These function similarly but just remotely control a
> screen via I2C and also suffer from the same problems of "need root" and "have
> to do some fun in mapping them to a given screen".

Right, supporting this definitely is part of the plan, this is why my original
email had the following footnote:

1) The need to be able to map the backlight device to a specific display
has become clear once more with the recent proposal to add DDCDI support:
https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/

:)
 
> Otherwise I welcome this de-uglification of the backlight device and putting 
> it
> together with the drm device that controls that monitor.

Thx.

> Just to make life more fun ... DDC does much more than backlight controls. It
> can control essentially anything that is in the OSD for your monitor 
> (contrast,
> brightness, backlight, sharpness, color temperatures, input to display (DP vs
> HDMI vs DVI etc.), an for extra fun points can even tel you the current
> rotation state of your monitor. All of these do make sense to live as drm
> connector properties too. Perhaps not a first iteration but something to
> consider in this design.

One thing which I do want to take into account is to make sure that userspace
can still do DDC/CI for all the other features. I know there is demand for
adding brightness control over DDC/CI. I'm not aware of any concrete use-cases
for the other DDC/CI settings. Also DDC/CI can include some pretty crazy
stuff like setting up picture in picture using 2 different inputs of the
monitor, which is very vendor specific. So all in all I think that we should
just punt most of the DDC/CI stuff to userspace.

With that said I agree that it would be good to think about possibly other
some of the other settings in case some use-case does show up for those.

The biggest problem with doing this is coming up with some prefix to
namespace things. I've gone with bl_brightness to avoid a conflict
with the existing TV specific properties which have plain "brightness"
put if we want to e.g. also add DDC/CI contrast as a property later
then it might be good to come up with another more generic prefix
which can be shared between laptop-panel-brightness, DDC/CI-brightness
and DDC/CI-contrast ... ?

So any suggestions for a better prefix?

Regards,

Hans





> 
>> As discussed already several times in the past:
>>  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
>>  
>> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
>>
>> The current userspace API for brightness control offered by
>> /sys/class/backlight devices has various issues, the biggest 2 being:
>>
>> 1. There is no way to map the backlight device to a specific
>>display-output / panel (1)
>> 2. Controlling the brightness requires root-rights requiring
>>desktop-environments to use suid-root helpers for this.
>>
>> As already discussed on various conference's hallway tracks
>> and as has been proposed on the dri-devel list once before (2),
>> it seems that there is consensus that the best way to to solve these
>> 2 issues is to add support for controlling a video-output's brightness
>> through properties on the drm_connector.
>>
>> This RFC outlines my plan to try and actually implement this,
>> which has 3 phases:
>>
>>
>> Phase 1: Stop registering multiple /sys/class/backlight devs for a single
>> display
>> =
>>
>> On x86 there can be multiple firmware + direct-hw-access methods
>> for controlling the backlight and in some cases the kernel registers
>> multiple backlight-devices for a single internal laptop LCD panel:
>>
>> a) i915 and nouveau unconditionally register their "native" backlight dev
>>even on devices where /sys/class/backlight/acpi_video0 must be used
>>to control the backlight, relying on userspace to prefer the "firmware"
>>acpi_video0 device over "native" devices.
>> b) amdgpu and nouveau rely on the acpi_video driver initializing before
>>them, which currently causes /sys/class/backlight/acpi_video0 to usually
>>show up and then they register their own native backlight driver after
>>which the drivers/acpi/video_detect.c code unregisters the acpi_video0
>>device. This means that userspace briefly sees 2 devices and the
>>disappearing of acpi_video0 after a brief time confuses the systemd
>>backlight level save/restore code, see e.g.:
>>https://bbs.archlinux.org/viewtopic.php?id=269920
>>
>> I already have a pretty detailed plan to tackle this, which I will
>> post in a separate RFC email. I plan to start working on this right
>> away, as it will be good to have this fixed regardless.
>>
>>
>> Phase 2: Add 

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

[Hans de Goede]

Hi,

On 4/8/22 17:11, Alex Deucher wrote:
> On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 4/8/22 16:08, Alex Deucher wrote:
>>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:

 On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
>>
>> Hi Simon,
>>
>> On 4/7/22 18:51, Simon Ser wrote:
>>> Very nice plan! Big +1 for the overall approach.
>>
>> Thanks.
>>
>>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
>>>  wrote:
>>>
 The drm_connector brightness properties
 ===

 bl_brightness: rw 0-int32_max property controlling the brightness 
 setting
 of the connected display. The actual maximum of this will be less then
 int32_max and is given in bl_brightness_max.
>>>
>>> Do we need to split this up into two props for sw/hw state? The privacy 
>>> screen
>>> stuff needed this, but you're pretty familiar with that. :)
>>
>> Luckily that won't be necessary, since the privacy-screen is a security
>> feature the firmware/embedded-controller may refuse our requests
>> (may temporarily lock-out changes) and/or may make changes without
>> us requesting them itself. Neither is really the case with the
>> brightness setting of displays.
>>
 bl_brightness_max: ro 0-int32_max property giving the actual maximum
 of the display's brightness setting. This will report 0 when brightness
 control is not available (yet).
>>>
>>> I don't think we actually need that one. Integer KMS props all have a
>>> range which can be fetched via drmModeGetProperty. The max can be
>>> exposed via this range. Example with the existing alpha prop:
>>>
>>> "alpha": range [0, UINT16_MAX] = 65535
>>
>> Right, I already knew that, which is why I explicitly added a range
>> to the props already. The problem is that the range must be set
>> before registering the connector and when the backlight driver
>> only shows up (much) later during boot then we don't know the
>> range when registering the connector. I guess we could "patch-up"
>> the range later. But AFAIK that would be a bit of abuse of the
>> property API as the range is intended to never change, not
>> even after hotplug uevents. At least atm there is no infra
>> in the kernel to change the range later.
>>
>> Which is why I added an explicit bl_brightness_max property
>> of which the value gives the actual effective maximum of the
>> brightness.

 Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
 brightness control later on then we just perpetuate the nonsense we have
 right now, forever.

 Imo we should support two kinds of drivers:

 - drivers which are non-crap, and make sure their backlight driver is
   loaded before they register the drm_device (or at least the
   drm_connector). For those we want the drm_connector->backlight pointer
   to bit static over the lifetime of the connector, and then we can also
   set up the brightness range correctly.

 - funny drivers which implement the glorious fallback dance which
   libbacklight implements currently in userspace. Imo for these drivers we
   should have a libbacklight_heuristics_backlight, which normalizes or
   whatever, and is also ways there. And then internally handles the
   fallback mess to the "right" backlight driver.

 We might have some gaps on acpi systems to make sure the drm driver can
 wait for the backlight driver to show up, but that's about it.

 Hotplugging random pieces later on is really not how drivers work nowadays
 with deferred probe and component framework and all that.

>> I did consider using the range for this and updating it
>> on the fly I think nothing is really preventing us from
>> doing so, but it very much feels like abusing the generic
>> properties API.
>>
 bl_brightness_0_is_min_brightness: ro, boolean
 When this is set to true then it is safe to set brightness to 0
 without worrying that this completely turns the backlight off causing
 the screen to become unreadable. When this is false setting brightness
 to 0 may turn the backlight off, but this is not guaranteed.
 This will e.g. be true when directly driving a PWM and the video-BIOS
 has provided a minimum (non 0) duty-cycle below which the driver will
 never go.
>>>
>>> Hm. It's quite unfortunate that it's impossible to have strong 
>>> guarantees
>>> here.
>>>
>>> Is there any way we can avoid this prop?
>>
>> Not really, the problem is that we really don't know if 0 is off
>> or min-brightness. In the given 

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

[Alex Deucher]

On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede  wrote:
>
> Hi,
>
> On 4/8/22 16:08, Alex Deucher wrote:
> > On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
> >>
> >> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> >>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
> 
>  Hi Simon,
> 
>  On 4/7/22 18:51, Simon Ser wrote:
> > Very nice plan! Big +1 for the overall approach.
> 
>  Thanks.
> 
> > On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> >  wrote:
> >
> >> The drm_connector brightness properties
> >> ===
> >>
> >> bl_brightness: rw 0-int32_max property controlling the brightness 
> >> setting
> >> of the connected display. The actual maximum of this will be less then
> >> int32_max and is given in bl_brightness_max.
> >
> > Do we need to split this up into two props for sw/hw state? The privacy 
> > screen
> > stuff needed this, but you're pretty familiar with that. :)
> 
>  Luckily that won't be necessary, since the privacy-screen is a security
>  feature the firmware/embedded-controller may refuse our requests
>  (may temporarily lock-out changes) and/or may make changes without
>  us requesting them itself. Neither is really the case with the
>  brightness setting of displays.
> 
> >> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> >> of the display's brightness setting. This will report 0 when brightness
> >> control is not available (yet).
> >
> > I don't think we actually need that one. Integer KMS props all have a
> > range which can be fetched via drmModeGetProperty. The max can be
> > exposed via this range. Example with the existing alpha prop:
> >
> > "alpha": range [0, UINT16_MAX] = 65535
> 
>  Right, I already knew that, which is why I explicitly added a range
>  to the props already. The problem is that the range must be set
>  before registering the connector and when the backlight driver
>  only shows up (much) later during boot then we don't know the
>  range when registering the connector. I guess we could "patch-up"
>  the range later. But AFAIK that would be a bit of abuse of the
>  property API as the range is intended to never change, not
>  even after hotplug uevents. At least atm there is no infra
>  in the kernel to change the range later.
> 
>  Which is why I added an explicit bl_brightness_max property
>  of which the value gives the actual effective maximum of the
>  brightness.
> >>
> >> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
> >> brightness control later on then we just perpetuate the nonsense we have
> >> right now, forever.
> >>
> >> Imo we should support two kinds of drivers:
> >>
> >> - drivers which are non-crap, and make sure their backlight driver is
> >>   loaded before they register the drm_device (or at least the
> >>   drm_connector). For those we want the drm_connector->backlight pointer
> >>   to bit static over the lifetime of the connector, and then we can also
> >>   set up the brightness range correctly.
> >>
> >> - funny drivers which implement the glorious fallback dance which
> >>   libbacklight implements currently in userspace. Imo for these drivers we
> >>   should have a libbacklight_heuristics_backlight, which normalizes or
> >>   whatever, and is also ways there. And then internally handles the
> >>   fallback mess to the "right" backlight driver.
> >>
> >> We might have some gaps on acpi systems to make sure the drm driver can
> >> wait for the backlight driver to show up, but that's about it.
> >>
> >> Hotplugging random pieces later on is really not how drivers work nowadays
> >> with deferred probe and component framework and all that.
> >>
>  I did consider using the range for this and updating it
>  on the fly I think nothing is really preventing us from
>  doing so, but it very much feels like abusing the generic
>  properties API.
> 
> >> bl_brightness_0_is_min_brightness: ro, boolean
> >> When this is set to true then it is safe to set brightness to 0
> >> without worrying that this completely turns the backlight off causing
> >> the screen to become unreadable. When this is false setting brightness
> >> to 0 may turn the backlight off, but this is not guaranteed.
> >> This will e.g. be true when directly driving a PWM and the video-BIOS
> >> has provided a minimum (non 0) duty-cycle below which the driver will
> >> never go.
> >
> > Hm. It's quite unfortunate that it's impossible to have strong 
> > guarantees
> > here.
> >
> > Is there any way we can avoid this prop?
> 
>  Not really, the problem is that we really don't know if 0 is off
>  or min-brightness. In the given example where we actually never go
>  down to a 

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

[Hans de Goede]

Hi Simon,

On 4/8/22 10:22, Simon Ser wrote:
> Hi Hans,
> 
> Thanks for your details replies!
> 
> On Thursday, April 7th, 2022 at 19:43, Hans de Goede  
> wrote:
> 
>>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
>>> wrote:
>>>
 The drm_connector brightness properties
 ===

 bl_brightness: rw 0-int32_max property controlling the brightness setting
 of the connected display. The actual maximum of this will be less then
 int32_max and is given in bl_brightness_max.
>>>
>>> Do we need to split this up into two props for sw/hw state? The privacy 
>>> screen
>>> stuff needed this, but you're pretty familiar with that. :)
>>
>> Luckily that won't be necessary, since the privacy-screen is a security
>> feature the firmware/embedded-controller may refuse our requests
>> (may temporarily lock-out changes) and/or may make changes without
>> us requesting them itself. Neither is really the case with the
>> brightness setting of displays.
> 
> Cool, makes sense to me!
> 
 bl_brightness_max: ro 0-int32_max property giving the actual maximum
 of the display's brightness setting. This will report 0 when brightness
 control is not available (yet).
>>>
>>> I don't think we actually need that one. Integer KMS props all have a
>>> range which can be fetched via drmModeGetProperty. The max can be
>>> exposed via this range. Example with the existing alpha prop:
>>>
>>> "alpha": range [0, UINT16_MAX] = 65535
>>
>> Right, I already knew that, which is why I explicitly added a range
>> to the props already. The problem is that the range must be set
>> before registering the connector and when the backlight driver
>> only shows up (much) later during boot then we don't know the
>> range when registering the connector. I guess we could "patch-up"
>> the range later. But AFAIK that would be a bit of abuse of the
>> property API as the range is intended to never change, not
>> even after hotplug uevents. At least atm there is no infra
>> in the kernel to change the range later.
>>
>> Which is why I added an explicit bl_brightness_max property
>> of which the value gives the actual effective maximum of the
>> brightness.
>>
>> I did consider using the range for this and updating it
>> on the fly I think nothing is really preventing us from
>> doing so, but it very much feels like abusing the generic
>> properties API.
> 
> Since this is new uAPI there's no concern about backwards compat here. So it's
> pretty much a matter of how we want the uAPI to look like. I was suggesting
> using a range because it's self-describing, but maybe it's an abuse.
> 
> Daniel Vetter, what do you think? If a property's range is going to be updated
> on the fly, should we go for it, or should we use a separate prop to describe
> the max value?
> 
 bl_brightness_0_is_min_brightness: ro, boolean
 When this is set to true then it is safe to set brightness to 0
 without worrying that this completely turns the backlight off causing
 the screen to become unreadable. When this is false setting brightness
 to 0 may turn the backlight off, but this is not guaranteed.
 This will e.g. be true when directly driving a PWM and the video-BIOS
 has provided a minimum (non 0) duty-cycle below which the driver will
 never go.
>>>
>>> Hm. It's quite unfortunate that it's impossible to have strong guarantees
>>> here.
>>>
>>> Is there any way we can avoid this prop?
>>
>> Not really, the problem is that we really don't know if 0 is off
>> or min-brightness. In the given example where we actually never go
>> down to a duty-cycle of 0% because the video BIOS tables tell us
>> not to, we can be certain that setting the brightness prop to 0
>> will not turn of the backlight, since we then set the duty-cycle
>> to the VBT provided minimum. Note the intend here is to only set
>> the boolean to true if the VBT provided minimum is _not_ 0, 0
>> just means the vendor did not bother to provide a minimum.
>>
>> Currently e.g. GNOME never goes lower then something like 5%
>> of brightness_max to avoid accidentally turning the screen off.
>>
>> Turning the screen off is quite bad to do on e.g. tablets where
>> the GUI is the only way to undo the brightness change and now
>> the user can no longer see the GUI.
>>
>> The idea behind this boolean is to give e.g. GNOME a way to
>> know that it is safe to go down to 0% and for it to use
>> the entire range.
>>
>>> For instance if we can guarantee that the min level won't turn the screen
>>> completely off we could make the range start from 1 instead of 0.
>>> Or allow -1 to mean "minimum value, maybe completely off".
>>
>> Right, the problem is we really don't know and when the range is
>> e.g. 0-65535 then something like 1 will almost always still just
>> turn the screen completely off. There will be a value of say like
>> 150 or some such which is then the actual minimum value to still
>> get the backlight to light up 

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

[Hans de Goede]

Hi,

On 4/8/22 16:08, Alex Deucher wrote:
> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
>>
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:

 Hi Simon,

 On 4/7/22 18:51, Simon Ser wrote:
> Very nice plan! Big +1 for the overall approach.

 Thanks.

> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
>  wrote:
>
>> The drm_connector brightness properties
>> ===
>>
>> bl_brightness: rw 0-int32_max property controlling the brightness setting
>> of the connected display. The actual maximum of this will be less then
>> int32_max and is given in bl_brightness_max.
>
> Do we need to split this up into two props for sw/hw state? The privacy 
> screen
> stuff needed this, but you're pretty familiar with that. :)

 Luckily that won't be necessary, since the privacy-screen is a security
 feature the firmware/embedded-controller may refuse our requests
 (may temporarily lock-out changes) and/or may make changes without
 us requesting them itself. Neither is really the case with the
 brightness setting of displays.

>> bl_brightness_max: ro 0-int32_max property giving the actual maximum
>> of the display's brightness setting. This will report 0 when brightness
>> control is not available (yet).
>
> I don't think we actually need that one. Integer KMS props all have a
> range which can be fetched via drmModeGetProperty. The max can be
> exposed via this range. Example with the existing alpha prop:
>
> "alpha": range [0, UINT16_MAX] = 65535

 Right, I already knew that, which is why I explicitly added a range
 to the props already. The problem is that the range must be set
 before registering the connector and when the backlight driver
 only shows up (much) later during boot then we don't know the
 range when registering the connector. I guess we could "patch-up"
 the range later. But AFAIK that would be a bit of abuse of the
 property API as the range is intended to never change, not
 even after hotplug uevents. At least atm there is no infra
 in the kernel to change the range later.

 Which is why I added an explicit bl_brightness_max property
 of which the value gives the actual effective maximum of the
 brightness.
>>
>> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
>> brightness control later on then we just perpetuate the nonsense we have
>> right now, forever.
>>
>> Imo we should support two kinds of drivers:
>>
>> - drivers which are non-crap, and make sure their backlight driver is
>>   loaded before they register the drm_device (or at least the
>>   drm_connector). For those we want the drm_connector->backlight pointer
>>   to bit static over the lifetime of the connector, and then we can also
>>   set up the brightness range correctly.
>>
>> - funny drivers which implement the glorious fallback dance which
>>   libbacklight implements currently in userspace. Imo for these drivers we
>>   should have a libbacklight_heuristics_backlight, which normalizes or
>>   whatever, and is also ways there. And then internally handles the
>>   fallback mess to the "right" backlight driver.
>>
>> We might have some gaps on acpi systems to make sure the drm driver can
>> wait for the backlight driver to show up, but that's about it.
>>
>> Hotplugging random pieces later on is really not how drivers work nowadays
>> with deferred probe and component framework and all that.
>>
 I did consider using the range for this and updating it
 on the fly I think nothing is really preventing us from
 doing so, but it very much feels like abusing the generic
 properties API.

>> bl_brightness_0_is_min_brightness: ro, boolean
>> When this is set to true then it is safe to set brightness to 0
>> without worrying that this completely turns the backlight off causing
>> the screen to become unreadable. When this is false setting brightness
>> to 0 may turn the backlight off, but this is not guaranteed.
>> This will e.g. be true when directly driving a PWM and the video-BIOS
>> has provided a minimum (non 0) duty-cycle below which the driver will
>> never go.
>
> Hm. It's quite unfortunate that it's impossible to have strong guarantees
> here.
>
> Is there any way we can avoid this prop?

 Not really, the problem is that we really don't know if 0 is off
 or min-brightness. In the given example where we actually never go
 down to a duty-cycle of 0% because the video BIOS tables tell us
 not to, we can be certain that setting the brightness prop to 0
 will not turn of the backlight, since we then set the duty-cycle
 to the VBT provided minimum. Note the intend here is to only set
 the boolean to 

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

[Alex Deucher]

On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter  wrote:
>
> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> > On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
> > >
> > > Hi Simon,
> > >
> > > On 4/7/22 18:51, Simon Ser wrote:
> > > > Very nice plan! Big +1 for the overall approach.
> > >
> > > Thanks.
> > >
> > > > On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> > > >  wrote:
> > > >
> > > >> The drm_connector brightness properties
> > > >> ===
> > > >>
> > > >> bl_brightness: rw 0-int32_max property controlling the brightness 
> > > >> setting
> > > >> of the connected display. The actual maximum of this will be less then
> > > >> int32_max and is given in bl_brightness_max.
> > > >
> > > > Do we need to split this up into two props for sw/hw state? The privacy 
> > > > screen
> > > > stuff needed this, but you're pretty familiar with that. :)
> > >
> > > Luckily that won't be necessary, since the privacy-screen is a security
> > > feature the firmware/embedded-controller may refuse our requests
> > > (may temporarily lock-out changes) and/or may make changes without
> > > us requesting them itself. Neither is really the case with the
> > > brightness setting of displays.
> > >
> > > >> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> > > >> of the display's brightness setting. This will report 0 when brightness
> > > >> control is not available (yet).
> > > >
> > > > I don't think we actually need that one. Integer KMS props all have a
> > > > range which can be fetched via drmModeGetProperty. The max can be
> > > > exposed via this range. Example with the existing alpha prop:
> > > >
> > > > "alpha": range [0, UINT16_MAX] = 65535
> > >
> > > Right, I already knew that, which is why I explicitly added a range
> > > to the props already. The problem is that the range must be set
> > > before registering the connector and when the backlight driver
> > > only shows up (much) later during boot then we don't know the
> > > range when registering the connector. I guess we could "patch-up"
> > > the range later. But AFAIK that would be a bit of abuse of the
> > > property API as the range is intended to never change, not
> > > even after hotplug uevents. At least atm there is no infra
> > > in the kernel to change the range later.
> > >
> > > Which is why I added an explicit bl_brightness_max property
> > > of which the value gives the actual effective maximum of the
> > > brightness.
>
> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
> brightness control later on then we just perpetuate the nonsense we have
> right now, forever.
>
> Imo we should support two kinds of drivers:
>
> - drivers which are non-crap, and make sure their backlight driver is
>   loaded before they register the drm_device (or at least the
>   drm_connector). For those we want the drm_connector->backlight pointer
>   to bit static over the lifetime of the connector, and then we can also
>   set up the brightness range correctly.
>
> - funny drivers which implement the glorious fallback dance which
>   libbacklight implements currently in userspace. Imo for these drivers we
>   should have a libbacklight_heuristics_backlight, which normalizes or
>   whatever, and is also ways there. And then internally handles the
>   fallback mess to the "right" backlight driver.
>
> We might have some gaps on acpi systems to make sure the drm driver can
> wait for the backlight driver to show up, but that's about it.
>
> Hotplugging random pieces later on is really not how drivers work nowadays
> with deferred probe and component framework and all that.
>
> > > I did consider using the range for this and updating it
> > > on the fly I think nothing is really preventing us from
> > > doing so, but it very much feels like abusing the generic
> > > properties API.
> > >
> > > >> bl_brightness_0_is_min_brightness: ro, boolean
> > > >> When this is set to true then it is safe to set brightness to 0
> > > >> without worrying that this completely turns the backlight off causing
> > > >> the screen to become unreadable. When this is false setting brightness
> > > >> to 0 may turn the backlight off, but this is not guaranteed.
> > > >> This will e.g. be true when directly driving a PWM and the video-BIOS
> > > >> has provided a minimum (non 0) duty-cycle below which the driver will
> > > >> never go.
> > > >
> > > > Hm. It's quite unfortunate that it's impossible to have strong 
> > > > guarantees
> > > > here.
> > > >
> > > > Is there any way we can avoid this prop?
> > >
> > > Not really, the problem is that we really don't know if 0 is off
> > > or min-brightness. In the given example where we actually never go
> > > down to a duty-cycle of 0% because the video BIOS tables tell us
> > > not to, we can be certain that setting the brightness prop to 0
> > > will not turn of the backlight, since we then set the duty-cycle
> > > to the VBT provided 

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

[Hans de Goede]

Hi,

On 4/8/22 12:16, Simon Ser wrote:
> Would it be an option to only support the KMS prop for Good devices,
> and continue using the suboptimal existing sysfs API for Bad devices?
> 
> (I'm just throwing ideas around to see what sticks, feel free to ignore.)

Currently suid-root or pkexec helpers are used to deal with the
/sys/class/backlight requires root rights issue. I really want to
be able to disable these helpers at build time in e.g. GNOME once
the new properties are supported in GNOME.  So that distros with
a new enough kernel can reduce their attack surface this way.

Regards,

Hans

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

[Hans de Goede]

Hi,

On 4/8/22 11:58, Hans de Goede wrote:
> Hi Daniel,
> 
> On 4/8/22 10:07, Daniel Vetter wrote:
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:

 Hi Simon,

 On 4/7/22 18:51, Simon Ser wrote:
> Very nice plan! Big +1 for the overall approach.

 Thanks.

> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
>  wrote:
>
>> The drm_connector brightness properties
>> ===
>>
>> bl_brightness: rw 0-int32_max property controlling the brightness setting
>> of the connected display. The actual maximum of this will be less then
>> int32_max and is given in bl_brightness_max.
>
> Do we need to split this up into two props for sw/hw state? The privacy 
> screen
> stuff needed this, but you're pretty familiar with that. :)

 Luckily that won't be necessary, since the privacy-screen is a security
 feature the firmware/embedded-controller may refuse our requests
 (may temporarily lock-out changes) and/or may make changes without
 us requesting them itself. Neither is really the case with the
 brightness setting of displays.

>> bl_brightness_max: ro 0-int32_max property giving the actual maximum
>> of the display's brightness setting. This will report 0 when brightness
>> control is not available (yet).
>
> I don't think we actually need that one. Integer KMS props all have a
> range which can be fetched via drmModeGetProperty. The max can be
> exposed via this range. Example with the existing alpha prop:
>
> "alpha": range [0, UINT16_MAX] = 65535

 Right, I already knew that, which is why I explicitly added a range
 to the props already. The problem is that the range must be set
 before registering the connector and when the backlight driver
 only shows up (much) later during boot then we don't know the
 range when registering the connector. I guess we could "patch-up"
 the range later. But AFAIK that would be a bit of abuse of the
 property API as the range is intended to never change, not
 even after hotplug uevents. At least atm there is no infra
 in the kernel to change the range later.

 Which is why I added an explicit bl_brightness_max property
 of which the value gives the actual effective maximum of the
 brightness.
>>
>> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
>> brightness control later on then we just perpetuate the nonsense we have
>> right now, forever.
>>
>> Imo we should support two kinds of drivers:
>>
>> - drivers which are non-crap, and make sure their backlight driver is
>>   loaded before they register the drm_device (or at least the
>>   drm_connector). For those we want the drm_connector->backlight pointer
>>   to bit static over the lifetime of the connector, and then we can also
>>   set up the brightness range correctly.
> 
> The only problem is that outside of device-tree platforms where
> we can have a backlight link in a devicetree display-connector node,
> there are no non crap devices and thus no non crap drivers.
> 
>> - funny drivers which implement the glorious fallback dance which
>>   libbacklight implements currently in userspace. Imo for these drivers we
>>   should have a libbacklight_heuristics_backlight, which normalizes or
>>   whatever, and is also ways there. And then internally handles the
>>   fallback mess to the "right" backlight driver.
> 
> So this will be pretty much all of them including i915 and nouveau.
> 
> My first thoughts where the same as yours and we can mostly guarantee
> that the drm_connector->backlight pointer is static over lifetime of
> the connector. But the problem is with the backlight device-s provided
> by things like the dell-laptop, thinkpad_acpi, etc. drivers which are
> still necessary / used for backlight control on core2duo era laptops
> which are still being active used by people.
> 
> Basically atm the kernel code to determine which backlight-device
> to use (which assumes a single internal LCD panel) goes like this (1):
> 
> 1. Check cmdline-override, DMI quirks (and return their value if set)
> 2. If ACPI video extensions are not supported then expect a backlight
>device of the dell-laptop, thinkpad_acpi, etc. type, and use that.
> 3. If the ACPI tables have been written for Windows8 or later and
>the GPU driver offers a GPU native backlight device use that.
> 4. Use the ACPI video extensions backlight device
> 
>> We might have some gaps on acpi systems to make sure the drm driver can
>> wait for the backlight driver to show up, but that's about it.
> 
> The problem here is 2. or IOW devices which don't support the
> ACPI video extensions, these typically (always?) also don't offer
> a GPU native backlight device, instead relying on
> the embedded-controller for backlight control using 

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

[Simon Ser]

Would it be an option to only support the KMS prop for Good devices,
and continue using the suboptimal existing sysfs API for Bad devices?

(I'm just throwing ideas around to see what sticks, feel free to ignore.)

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

[Hans de Goede]

Hi,

On 4/8/22 11:58, Hans de Goede wrote:
> Hi Daniel,
> 
> On 4/8/22 10:07, Daniel Vetter wrote:
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:

 Hi Simon,

 On 4/7/22 18:51, Simon Ser wrote:
> Very nice plan! Big +1 for the overall approach.

 Thanks.

> On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
>  wrote:
>
>> The drm_connector brightness properties
>> ===
>>
>> bl_brightness: rw 0-int32_max property controlling the brightness setting
>> of the connected display. The actual maximum of this will be less then
>> int32_max and is given in bl_brightness_max.
>
> Do we need to split this up into two props for sw/hw state? The privacy 
> screen
> stuff needed this, but you're pretty familiar with that. :)

 Luckily that won't be necessary, since the privacy-screen is a security
 feature the firmware/embedded-controller may refuse our requests
 (may temporarily lock-out changes) and/or may make changes without
 us requesting them itself. Neither is really the case with the
 brightness setting of displays.

>> bl_brightness_max: ro 0-int32_max property giving the actual maximum
>> of the display's brightness setting. This will report 0 when brightness
>> control is not available (yet).
>
> I don't think we actually need that one. Integer KMS props all have a
> range which can be fetched via drmModeGetProperty. The max can be
> exposed via this range. Example with the existing alpha prop:
>
> "alpha": range [0, UINT16_MAX] = 65535

 Right, I already knew that, which is why I explicitly added a range
 to the props already. The problem is that the range must be set
 before registering the connector and when the backlight driver
 only shows up (much) later during boot then we don't know the
 range when registering the connector. I guess we could "patch-up"
 the range later. But AFAIK that would be a bit of abuse of the
 property API as the range is intended to never change, not
 even after hotplug uevents. At least atm there is no infra
 in the kernel to change the range later.

 Which is why I added an explicit bl_brightness_max property
 of which the value gives the actual effective maximum of the
 brightness.
>>
>> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
>> brightness control later on then we just perpetuate the nonsense we have
>> right now, forever.
>>
>> Imo we should support two kinds of drivers:
>>
>> - drivers which are non-crap, and make sure their backlight driver is
>>   loaded before they register the drm_device (or at least the
>>   drm_connector). For those we want the drm_connector->backlight pointer
>>   to bit static over the lifetime of the connector, and then we can also
>>   set up the brightness range correctly.
> 
> The only problem is that outside of device-tree platforms where
> we can have a backlight link in a devicetree display-connector node,
> there are no non crap devices and thus no non crap drivers.
> 
>> - funny drivers which implement the glorious fallback dance which
>>   libbacklight implements currently in userspace. Imo for these drivers we
>>   should have a libbacklight_heuristics_backlight, which normalizes or
>>   whatever, and is also ways there. And then internally handles the
>>   fallback mess to the "right" backlight driver.
> 
> So this will be pretty much all of them including i915 and nouveau.
> 
> My first thoughts where the same as yours and we can mostly guarantee
> that the drm_connector->backlight pointer is static over lifetime of
> the connector. But the problem is with the backlight device-s provided
> by things like the dell-laptop, thinkpad_acpi, etc. drivers which are
> still necessary / used for backlight control on core2duo era laptops
> which are still being active used by people.
> 
> Basically atm the kernel code to determine which backlight-device
> to use (which assumes a single internal LCD panel) goes like this (1):
> 
> 1. Check cmdline-override, DMI quirks (and return their value if set)
> 2. If ACPI video extensions are not supported then expect a backlight
>device of the dell-laptop, thinkpad_acpi, etc. type, and use that.
> 3. If the ACPI tables have been written for Windows8 or later and
>the GPU driver offers a GPU native backlight device use that.
> 4. Use the ACPI video extensions backlight device
> 
>> We might have some gaps on acpi systems to make sure the drm driver can
>> wait for the backlight driver to show up, but that's about it.
> 
> The problem here is 2. or IOW devices which don't support the
> ACPI video extensions, these typically (always?) also don't offer
> a GPU native backlight device, instead relying on
> the embedded-controller for backlight control using 

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

[Hans de Goede]

Hi Daniel,

On 4/8/22 10:07, Daniel Vetter wrote:
> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
>>>
>>> Hi Simon,
>>>
>>> On 4/7/22 18:51, Simon Ser wrote:
 Very nice plan! Big +1 for the overall approach.
>>>
>>> Thanks.
>>>
 On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
 wrote:

> The drm_connector brightness properties
> ===
>
> bl_brightness: rw 0-int32_max property controlling the brightness setting
> of the connected display. The actual maximum of this will be less then
> int32_max and is given in bl_brightness_max.

 Do we need to split this up into two props for sw/hw state? The privacy 
 screen
 stuff needed this, but you're pretty familiar with that. :)
>>>
>>> Luckily that won't be necessary, since the privacy-screen is a security
>>> feature the firmware/embedded-controller may refuse our requests
>>> (may temporarily lock-out changes) and/or may make changes without
>>> us requesting them itself. Neither is really the case with the
>>> brightness setting of displays.
>>>
> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> of the display's brightness setting. This will report 0 when brightness
> control is not available (yet).

 I don't think we actually need that one. Integer KMS props all have a
 range which can be fetched via drmModeGetProperty. The max can be
 exposed via this range. Example with the existing alpha prop:

 "alpha": range [0, UINT16_MAX] = 65535
>>>
>>> Right, I already knew that, which is why I explicitly added a range
>>> to the props already. The problem is that the range must be set
>>> before registering the connector and when the backlight driver
>>> only shows up (much) later during boot then we don't know the
>>> range when registering the connector. I guess we could "patch-up"
>>> the range later. But AFAIK that would be a bit of abuse of the
>>> property API as the range is intended to never change, not
>>> even after hotplug uevents. At least atm there is no infra
>>> in the kernel to change the range later.
>>>
>>> Which is why I added an explicit bl_brightness_max property
>>> of which the value gives the actual effective maximum of the
>>> brightness.
> 
> Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
> brightness control later on then we just perpetuate the nonsense we have
> right now, forever.
> 
> Imo we should support two kinds of drivers:
> 
> - drivers which are non-crap, and make sure their backlight driver is
>   loaded before they register the drm_device (or at least the
>   drm_connector). For those we want the drm_connector->backlight pointer
>   to bit static over the lifetime of the connector, and then we can also
>   set up the brightness range correctly.

The only problem is that outside of device-tree platforms where
we can have a backlight link in a devicetree display-connector node,
there are no non crap devices and thus no non crap drivers.

> - funny drivers which implement the glorious fallback dance which
>   libbacklight implements currently in userspace. Imo for these drivers we
>   should have a libbacklight_heuristics_backlight, which normalizes or
>   whatever, and is also ways there. And then internally handles the
>   fallback mess to the "right" backlight driver.

So this will be pretty much all of them including i915 and nouveau.

My first thoughts where the same as yours and we can mostly guarantee
that the drm_connector->backlight pointer is static over lifetime of
the connector. But the problem is with the backlight device-s provided
by things like the dell-laptop, thinkpad_acpi, etc. drivers which are
still necessary / used for backlight control on core2duo era laptops
which are still being active used by people.

Basically atm the kernel code to determine which backlight-device
to use (which assumes a single internal LCD panel) goes like this (1):

1. Check cmdline-override, DMI quirks (and return their value if set)
2. If ACPI video extensions are not supported then expect a backlight
   device of the dell-laptop, thinkpad_acpi, etc. type, and use that.
3. If the ACPI tables have been written for Windows8 or later and
   the GPU driver offers a GPU native backlight device use that.
4. Use the ACPI video extensions backlight device

> We might have some gaps on acpi systems to make sure the drm driver can
> wait for the backlight driver to show up, but that's about it.

The problem here is 2. or IOW devices which don't support the
ACPI video extensions, these typically (always?) also don't offer
a GPU native backlight device, instead relying on
the embedded-controller for backlight control using some vendor
specific firmware API to talk to the EC.

For the other cases there are indeed some gaps which I plan to close
so that we can make sure that the backlight device 

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

[Simon Ser]

Hi Hans,

Thanks for your details replies!

On Thursday, April 7th, 2022 at 19:43, Hans de Goede  
wrote:

> > On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
> > wrote:
> >
> >> The drm_connector brightness properties
> >> ===
> >>
> >> bl_brightness: rw 0-int32_max property controlling the brightness setting
> >> of the connected display. The actual maximum of this will be less then
> >> int32_max and is given in bl_brightness_max.
> >
> > Do we need to split this up into two props for sw/hw state? The privacy 
> > screen
> > stuff needed this, but you're pretty familiar with that. :)
>
> Luckily that won't be necessary, since the privacy-screen is a security
> feature the firmware/embedded-controller may refuse our requests
> (may temporarily lock-out changes) and/or may make changes without
> us requesting them itself. Neither is really the case with the
> brightness setting of displays.

Cool, makes sense to me!

> >> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> >> of the display's brightness setting. This will report 0 when brightness
> >> control is not available (yet).
> >
> > I don't think we actually need that one. Integer KMS props all have a
> > range which can be fetched via drmModeGetProperty. The max can be
> > exposed via this range. Example with the existing alpha prop:
> >
> > "alpha": range [0, UINT16_MAX] = 65535
>
> Right, I already knew that, which is why I explicitly added a range
> to the props already. The problem is that the range must be set
> before registering the connector and when the backlight driver
> only shows up (much) later during boot then we don't know the
> range when registering the connector. I guess we could "patch-up"
> the range later. But AFAIK that would be a bit of abuse of the
> property API as the range is intended to never change, not
> even after hotplug uevents. At least atm there is no infra
> in the kernel to change the range later.
>
> Which is why I added an explicit bl_brightness_max property
> of which the value gives the actual effective maximum of the
> brightness.
>
> I did consider using the range for this and updating it
> on the fly I think nothing is really preventing us from
> doing so, but it very much feels like abusing the generic
> properties API.

Since this is new uAPI there's no concern about backwards compat here. So it's
pretty much a matter of how we want the uAPI to look like. I was suggesting
using a range because it's self-describing, but maybe it's an abuse.

Daniel Vetter, what do you think? If a property's range is going to be updated
on the fly, should we go for it, or should we use a separate prop to describe
the max value?

> >> bl_brightness_0_is_min_brightness: ro, boolean
> >> When this is set to true then it is safe to set brightness to 0
> >> without worrying that this completely turns the backlight off causing
> >> the screen to become unreadable. When this is false setting brightness
> >> to 0 may turn the backlight off, but this is not guaranteed.
> >> This will e.g. be true when directly driving a PWM and the video-BIOS
> >> has provided a minimum (non 0) duty-cycle below which the driver will
> >> never go.
> >
> > Hm. It's quite unfortunate that it's impossible to have strong guarantees
> > here.
> >
> > Is there any way we can avoid this prop?
>
> Not really, the problem is that we really don't know if 0 is off
> or min-brightness. In the given example where we actually never go
> down to a duty-cycle of 0% because the video BIOS tables tell us
> not to, we can be certain that setting the brightness prop to 0
> will not turn of the backlight, since we then set the duty-cycle
> to the VBT provided minimum. Note the intend here is to only set
> the boolean to true if the VBT provided minimum is _not_ 0, 0
> just means the vendor did not bother to provide a minimum.
>
> Currently e.g. GNOME never goes lower then something like 5%
> of brightness_max to avoid accidentally turning the screen off.
>
> Turning the screen off is quite bad to do on e.g. tablets where
> the GUI is the only way to undo the brightness change and now
> the user can no longer see the GUI.
>
> The idea behind this boolean is to give e.g. GNOME a way to
> know that it is safe to go down to 0% and for it to use
> the entire range.
>
> > For instance if we can guarantee that the min level won't turn the screen
> > completely off we could make the range start from 1 instead of 0.
> > Or allow -1 to mean "minimum value, maybe completely off".
>
> Right, the problem is we really don't know and when the range is
> e.g. 0-65535 then something like 1 will almost always still just
> turn the screen completely off. There will be a value of say like
> 150 or some such which is then the actual minimum value to still
> get the backlight to light up at all. The problem is we have
> no clue what the actual minimum is. And if the PWM output does
> not directly drive the LEDs but is 

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

[Daniel Vetter]

On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
> >
> > Hi Simon,
> >
> > On 4/7/22 18:51, Simon Ser wrote:
> > > Very nice plan! Big +1 for the overall approach.
> >
> > Thanks.
> >
> > > On Thursday, April 7th, 2022 at 17:38, Hans de Goede 
> > >  wrote:
> > >
> > >> The drm_connector brightness properties
> > >> ===
> > >>
> > >> bl_brightness: rw 0-int32_max property controlling the brightness setting
> > >> of the connected display. The actual maximum of this will be less then
> > >> int32_max and is given in bl_brightness_max.
> > >
> > > Do we need to split this up into two props for sw/hw state? The privacy 
> > > screen
> > > stuff needed this, but you're pretty familiar with that. :)
> >
> > Luckily that won't be necessary, since the privacy-screen is a security
> > feature the firmware/embedded-controller may refuse our requests
> > (may temporarily lock-out changes) and/or may make changes without
> > us requesting them itself. Neither is really the case with the
> > brightness setting of displays.
> >
> > >> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> > >> of the display's brightness setting. This will report 0 when brightness
> > >> control is not available (yet).
> > >
> > > I don't think we actually need that one. Integer KMS props all have a
> > > range which can be fetched via drmModeGetProperty. The max can be
> > > exposed via this range. Example with the existing alpha prop:
> > >
> > > "alpha": range [0, UINT16_MAX] = 65535
> >
> > Right, I already knew that, which is why I explicitly added a range
> > to the props already. The problem is that the range must be set
> > before registering the connector and when the backlight driver
> > only shows up (much) later during boot then we don't know the
> > range when registering the connector. I guess we could "patch-up"
> > the range later. But AFAIK that would be a bit of abuse of the
> > property API as the range is intended to never change, not
> > even after hotplug uevents. At least atm there is no infra
> > in the kernel to change the range later.
> >
> > Which is why I added an explicit bl_brightness_max property
> > of which the value gives the actual effective maximum of the
> > brightness.

Uh ... I'm not a huge fan tbh. The thing is, if we allow hotplugging
brightness control later on then we just perpetuate the nonsense we have
right now, forever.

Imo we should support two kinds of drivers:

- drivers which are non-crap, and make sure their backlight driver is
  loaded before they register the drm_device (or at least the
  drm_connector). For those we want the drm_connector->backlight pointer
  to bit static over the lifetime of the connector, and then we can also
  set up the brightness range correctly.

- funny drivers which implement the glorious fallback dance which
  libbacklight implements currently in userspace. Imo for these drivers we
  should have a libbacklight_heuristics_backlight, which normalizes or
  whatever, and is also ways there. And then internally handles the
  fallback mess to the "right" backlight driver.

We might have some gaps on acpi systems to make sure the drm driver can
wait for the backlight driver to show up, but that's about it.

Hotplugging random pieces later on is really not how drivers work nowadays
with deferred probe and component framework and all that.

> > I did consider using the range for this and updating it
> > on the fly I think nothing is really preventing us from
> > doing so, but it very much feels like abusing the generic
> > properties API.
> >
> > >> bl_brightness_0_is_min_brightness: ro, boolean
> > >> When this is set to true then it is safe to set brightness to 0
> > >> without worrying that this completely turns the backlight off causing
> > >> the screen to become unreadable. When this is false setting brightness
> > >> to 0 may turn the backlight off, but this is not guaranteed.
> > >> This will e.g. be true when directly driving a PWM and the video-BIOS
> > >> has provided a minimum (non 0) duty-cycle below which the driver will
> > >> never go.
> > >
> > > Hm. It's quite unfortunate that it's impossible to have strong guarantees
> > > here.
> > >
> > > Is there any way we can avoid this prop?
> >
> > Not really, the problem is that we really don't know if 0 is off
> > or min-brightness. In the given example where we actually never go
> > down to a duty-cycle of 0% because the video BIOS tables tell us
> > not to, we can be certain that setting the brightness prop to 0
> > will not turn of the backlight, since we then set the duty-cycle
> > to the VBT provided minimum. Note the intend here is to only set
> > the boolean to true if the VBT provided minimum is _not_ 0, 0
> > just means the vendor did not bother to provide a minimum.
> >
> > Currently e.g. GNOME never goes lower then something like 5%
> > of brightness_max to avoid 

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

[Alex Deucher]

On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede  wrote:
>
> Hi Simon,
>
> On 4/7/22 18:51, Simon Ser wrote:
> > Very nice plan! Big +1 for the overall approach.
>
> Thanks.
>
> > On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
> > wrote:
> >
> >> The drm_connector brightness properties
> >> ===
> >>
> >> bl_brightness: rw 0-int32_max property controlling the brightness setting
> >> of the connected display. The actual maximum of this will be less then
> >> int32_max and is given in bl_brightness_max.
> >
> > Do we need to split this up into two props for sw/hw state? The privacy 
> > screen
> > stuff needed this, but you're pretty familiar with that. :)
>
> Luckily that won't be necessary, since the privacy-screen is a security
> feature the firmware/embedded-controller may refuse our requests
> (may temporarily lock-out changes) and/or may make changes without
> us requesting them itself. Neither is really the case with the
> brightness setting of displays.
>
> >> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> >> of the display's brightness setting. This will report 0 when brightness
> >> control is not available (yet).
> >
> > I don't think we actually need that one. Integer KMS props all have a
> > range which can be fetched via drmModeGetProperty. The max can be
> > exposed via this range. Example with the existing alpha prop:
> >
> > "alpha": range [0, UINT16_MAX] = 65535
>
> Right, I already knew that, which is why I explicitly added a range
> to the props already. The problem is that the range must be set
> before registering the connector and when the backlight driver
> only shows up (much) later during boot then we don't know the
> range when registering the connector. I guess we could "patch-up"
> the range later. But AFAIK that would be a bit of abuse of the
> property API as the range is intended to never change, not
> even after hotplug uevents. At least atm there is no infra
> in the kernel to change the range later.
>
> Which is why I added an explicit bl_brightness_max property
> of which the value gives the actual effective maximum of the
> brightness.
>
> I did consider using the range for this and updating it
> on the fly I think nothing is really preventing us from
> doing so, but it very much feels like abusing the generic
> properties API.
>
> >> bl_brightness_0_is_min_brightness: ro, boolean
> >> When this is set to true then it is safe to set brightness to 0
> >> without worrying that this completely turns the backlight off causing
> >> the screen to become unreadable. When this is false setting brightness
> >> to 0 may turn the backlight off, but this is not guaranteed.
> >> This will e.g. be true when directly driving a PWM and the video-BIOS
> >> has provided a minimum (non 0) duty-cycle below which the driver will
> >> never go.
> >
> > Hm. It's quite unfortunate that it's impossible to have strong guarantees
> > here.
> >
> > Is there any way we can avoid this prop?
>
> Not really, the problem is that we really don't know if 0 is off
> or min-brightness. In the given example where we actually never go
> down to a duty-cycle of 0% because the video BIOS tables tell us
> not to, we can be certain that setting the brightness prop to 0
> will not turn of the backlight, since we then set the duty-cycle
> to the VBT provided minimum. Note the intend here is to only set
> the boolean to true if the VBT provided minimum is _not_ 0, 0
> just means the vendor did not bother to provide a minimum.
>
> Currently e.g. GNOME never goes lower then something like 5%
> of brightness_max to avoid accidentally turning the screen off.
>
> Turning the screen off is quite bad to do on e.g. tablets where
> the GUI is the only way to undo the brightness change and now
> the user can no longer see the GUI.
>
> The idea behind this boolean is to give e.g. GNOME a way to
> know that it is safe to go down to 0% and for it to use
> the entire range.

Why not just make it policy that 0 is defined as minimum brightness,
not off, and have all drivers conform to that?

Alex

>
> > For instance if we can guarantee that the min level won't turn the screen
> > completely off we could make the range start from 1 instead of 0.
> > Or allow -1 to mean "minimum value, maybe completely off".
>
> Right, the problem is we really don't know and when the range is
> e.g. 0-65535 then something like 1 will almost always still just
> turn the screen completely off. There will be a value of say like
> 150 or some such which is then the actual minimum value to still
> get the backlight to light up at all. The problem is we have
> no clue what the actual minimum is. And if the PWM output does
> not directly drive the LEDs but is used as an input for some
> LED backlight driver chip, that chip itself may have a lookup
> table (which may also take care of doing perceived brightness
> mapping) and may guarantee a minimum backlight even when given
> a 0% duty cycle 

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

[Carsten Haitzler]

On Thu, 7 Apr 2022 17:38:59 +0200 Hans de Goede  said:

Below you covered our usual /sys/class/backlight device friends... what about
DDC monitor controls? These function similarly but just remotely control a
screen via I2C and also suffer from the same problems of "need root" and "have
to do some fun in mapping them to a given screen".

Otherwise I welcome this de-uglification of the backlight device and putting it
together with the drm device that controls that monitor.

Just to make life more fun ... DDC does much more than backlight controls. It
can control essentially anything that is in the OSD for your monitor (contrast,
brightness, backlight, sharpness, color temperatures, input to display (DP vs
HDMI vs DVI etc.), an for extra fun points can even tel you the current
rotation state of your monitor. All of these do make sense to live as drm
connector properties too. Perhaps not a first iteration but something to
consider in this design.

> As discussed already several times in the past:
>  https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
>  
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> 
> The current userspace API for brightness control offered by
> /sys/class/backlight devices has various issues, the biggest 2 being:
> 
> 1. There is no way to map the backlight device to a specific
>display-output / panel (1)
> 2. Controlling the brightness requires root-rights requiring
>desktop-environments to use suid-root helpers for this.
> 
> As already discussed on various conference's hallway tracks
> and as has been proposed on the dri-devel list once before (2),
> it seems that there is consensus that the best way to to solve these
> 2 issues is to add support for controlling a video-output's brightness
> through properties on the drm_connector.
> 
> This RFC outlines my plan to try and actually implement this,
> which has 3 phases:
> 
> 
> Phase 1: Stop registering multiple /sys/class/backlight devs for a single
> display
> =
> 
> On x86 there can be multiple firmware + direct-hw-access methods
> for controlling the backlight and in some cases the kernel registers
> multiple backlight-devices for a single internal laptop LCD panel:
> 
> a) i915 and nouveau unconditionally register their "native" backlight dev
>even on devices where /sys/class/backlight/acpi_video0 must be used
>to control the backlight, relying on userspace to prefer the "firmware"
>acpi_video0 device over "native" devices.
> b) amdgpu and nouveau rely on the acpi_video driver initializing before
>them, which currently causes /sys/class/backlight/acpi_video0 to usually
>show up and then they register their own native backlight driver after
>which the drivers/acpi/video_detect.c code unregisters the acpi_video0
>device. This means that userspace briefly sees 2 devices and the
>disappearing of acpi_video0 after a brief time confuses the systemd
>backlight level save/restore code, see e.g.:
>https://bbs.archlinux.org/viewtopic.php?id=269920
> 
> I already have a pretty detailed plan to tackle this, which I will
> post in a separate RFC email. I plan to start working on this right
> away, as it will be good to have this fixed regardless.
> 
> 
> Phase 2: Add drm_connector properties mirroring the matching backlight device
> =
> 
> The plan is to add a drm_connector helper function, which optionally takes
> a pointer to the backlight device for the GPU's native backlight device,
> which will then mirror the backlight settings from the backlight device
> in a set of read/write brightness* properties on the connector.
> 
> This function can then be called by GPU drivers for the drm_connector for
> the internal panel and it will then take care of everything. When there
> is no native GPU backlight device, or when it should not be used then
> (on x86) the helper will use the acpi_video_get_backlight_type() to
> determine which backlight-device should be used instead and it will find
> + mirror that one.
> 
> 
> Phase 3: Deprecate /sys/class/backlight uAPI
> 
> 
> Once most userspace has moved over to using the new drm_connector
> brightness props, a Kconfig option can be added to stop exporting
> the backlight-devices under /sys/class/backlight. The plan is to
> just disable the sysfs interface and keep the existing backlight-device
> internal kernel abstraction as is, since some abstraction for (non GPU
> native) backlight devices will be necessary regardless.
> 
> An alternative to disabling the sysfs class entirely, would be
> to allow setting it to read-only through Kconfig.
> 
> 
> What scale to use for the drm_connector bl_brightness property?
> ===
> 
> The tricky part of this plan is 

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

[Hans de Goede]

Hi Simon,

On 4/7/22 18:51, Simon Ser wrote:
> Very nice plan! Big +1 for the overall approach.

Thanks.

> On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
> wrote:
> 
>> The drm_connector brightness properties
>> ===
>>
>> bl_brightness: rw 0-int32_max property controlling the brightness setting
>> of the connected display. The actual maximum of this will be less then
>> int32_max and is given in bl_brightness_max.
> 
> Do we need to split this up into two props for sw/hw state? The privacy screen
> stuff needed this, but you're pretty familiar with that. :)

Luckily that won't be necessary, since the privacy-screen is a security
feature the firmware/embedded-controller may refuse our requests
(may temporarily lock-out changes) and/or may make changes without
us requesting them itself. Neither is really the case with the
brightness setting of displays.

>> bl_brightness_max: ro 0-int32_max property giving the actual maximum
>> of the display's brightness setting. This will report 0 when brightness
>> control is not available (yet).
> 
> I don't think we actually need that one. Integer KMS props all have a
> range which can be fetched via drmModeGetProperty. The max can be
> exposed via this range. Example with the existing alpha prop:
> 
> "alpha": range [0, UINT16_MAX] = 65535

Right, I already knew that, which is why I explicitly added a range
to the props already. The problem is that the range must be set
before registering the connector and when the backlight driver
only shows up (much) later during boot then we don't know the
range when registering the connector. I guess we could "patch-up"
the range later. But AFAIK that would be a bit of abuse of the
property API as the range is intended to never change, not
even after hotplug uevents. At least atm there is no infra
in the kernel to change the range later.

Which is why I added an explicit bl_brightness_max property
of which the value gives the actual effective maximum of the
brightness.

I did consider using the range for this and updating it
on the fly I think nothing is really preventing us from
doing so, but it very much feels like abusing the generic
properties API.

>> bl_brightness_0_is_min_brightness: ro, boolean
>> When this is set to true then it is safe to set brightness to 0
>> without worrying that this completely turns the backlight off causing
>> the screen to become unreadable. When this is false setting brightness
>> to 0 may turn the backlight off, but this is not guaranteed.
>> This will e.g. be true when directly driving a PWM and the video-BIOS
>> has provided a minimum (non 0) duty-cycle below which the driver will
>> never go.
> 
> Hm. It's quite unfortunate that it's impossible to have strong guarantees
> here.
> 
> Is there any way we can avoid this prop?

Not really, the problem is that we really don't know if 0 is off
or min-brightness. In the given example where we actually never go
down to a duty-cycle of 0% because the video BIOS tables tell us
not to, we can be certain that setting the brightness prop to 0
will not turn of the backlight, since we then set the duty-cycle
to the VBT provided minimum. Note the intend here is to only set
the boolean to true if the VBT provided minimum is _not_ 0, 0
just means the vendor did not bother to provide a minimum.

Currently e.g. GNOME never goes lower then something like 5%
of brightness_max to avoid accidentally turning the screen off.

Turning the screen off is quite bad to do on e.g. tablets where
the GUI is the only way to undo the brightness change and now
the user can no longer see the GUI.

The idea behind this boolean is to give e.g. GNOME a way to
know that it is safe to go down to 0% and for it to use
the entire range.

> For instance if we can guarantee that the min level won't turn the screen
> completely off we could make the range start from 1 instead of 0.
> Or allow -1 to mean "minimum value, maybe completely off".

Right, the problem is we really don't know and when the range is
e.g. 0-65535 then something like 1 will almost always still just
turn the screen completely off. There will be a value of say like
150 or some such which is then the actual minimum value to still
get the backlight to light up at all. The problem is we have
no clue what the actual minimum is. And if the PWM output does
not directly drive the LEDs but is used as an input for some
LED backlight driver chip, that chip itself may have a lookup
table (which may also take care of doing perceived brightness
mapping) and may guarantee a minimum backlight even when given
a 0% duty cycle PWM signal...

This prop is sort of orthogonal to the generic change to
drm_connector props, so we could also do this later as a follow up
change. At a minimum when I code this up this should be in its
own commit(s) I believe.

But I do think having this will be useful for the above
GNOME example.

>> bl_brightness_control_method: ro, enum, possible values:
>> none: 

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

[Simon Ser]

Very nice plan! Big +1 for the overall approach.

On Thursday, April 7th, 2022 at 17:38, Hans de Goede  
wrote:

> The drm_connector brightness properties
> ===
>
> bl_brightness: rw 0-int32_max property controlling the brightness setting
> of the connected display. The actual maximum of this will be less then
> int32_max and is given in bl_brightness_max.

Do we need to split this up into two props for sw/hw state? The privacy screen
stuff needed this, but you're pretty familiar with that. :)

> bl_brightness_max: ro 0-int32_max property giving the actual maximum
> of the display's brightness setting. This will report 0 when brightness
> control is not available (yet).

I don't think we actually need that one. Integer KMS props all have a
range which can be fetched via drmModeGetProperty. The max can be
exposed via this range. Example with the existing alpha prop:

"alpha": range [0, UINT16_MAX] = 65535

> bl_brightness_0_is_min_brightness: ro, boolean
> When this is set to true then it is safe to set brightness to 0
> without worrying that this completely turns the backlight off causing
> the screen to become unreadable. When this is false setting brightness
> to 0 may turn the backlight off, but this is not guaranteed.
> This will e.g. be true when directly driving a PWM and the video-BIOS
> has provided a minimum (non 0) duty-cycle below which the driver will
> never go.

Hm. It's quite unfortunate that it's impossible to have strong guarantees
here.

Is there any way we can avoid this prop?

For instance if we can guarantee that the min level won't turn the screen
completely off we could make the range start from 1 instead of 0.
Or allow -1 to mean "minimum value, maybe completely off".

> bl_brightness_control_method: ro, enum, possible values:
> none: The GPU driver expects brightness control to be provided by another
> driver and that driver has not loaded yet.
> unknown: The underlying control mechanism is unknown.
> pwm: The brightness property directly controls the duty-cycle of a PWM
> output.
> firmware: The brightness is controlled through firmware calls.
> DDC/CI: The brightness is controlled through the DDC/CI protocol.
> gmux: The brightness is controlled by the GMUX.
> Note this enum may be extended in the future, so other values may
> be read, these should be treated as "unknown".
>
> When brightness control becomes available after being reported
> as not available before (bl_brightness_control_method=="none")
> a uevent with CONNECTOR= and
>
> PROPERTY= will be generated
>
> at this point all the properties must be re-read.
>
> When/once brightness control is available then all the read-only
> properties are fixed and will never change.
>
> Besides the "none" value for no driver having loaded yet,
> the different bl_brightness_control_method values are intended for
> (userspace) heuristics for such things as the brightness setting
> linearly controlling electrical power or setting perceived brightness.

Can you elaborate? I don't know enough about brightness control to
understand all of the implications here.

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

[Hans de Goede]

As discussed already several times in the past:
 https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
 
https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/

The current userspace API for brightness control offered by
/sys/class/backlight devices has various issues, the biggest 2 being:

1. There is no way to map the backlight device to a specific
   display-output / panel (1)
2. Controlling the brightness requires root-rights requiring
   desktop-environments to use suid-root helpers for this.

As already discussed on various conference's hallway tracks
and as has been proposed on the dri-devel list once before (2),
it seems that there is consensus that the best way to to solve these
2 issues is to add support for controlling a video-output's brightness
through properties on the drm_connector.

This RFC outlines my plan to try and actually implement this,
which has 3 phases:


Phase 1: Stop registering multiple /sys/class/backlight devs for a single 
display
=

On x86 there can be multiple firmware + direct-hw-access methods
for controlling the backlight and in some cases the kernel registers
multiple backlight-devices for a single internal laptop LCD panel:

a) i915 and nouveau unconditionally register their "native" backlight dev
   even on devices where /sys/class/backlight/acpi_video0 must be used
   to control the backlight, relying on userspace to prefer the "firmware"
   acpi_video0 device over "native" devices.
b) amdgpu and nouveau rely on the acpi_video driver initializing before
   them, which currently causes /sys/class/backlight/acpi_video0 to usually
   show up and then they register their own native backlight driver after
   which the drivers/acpi/video_detect.c code unregisters the acpi_video0
   device. This means that userspace briefly sees 2 devices and the
   disappearing of acpi_video0 after a brief time confuses the systemd
   backlight level save/restore code, see e.g.:
   https://bbs.archlinux.org/viewtopic.php?id=269920

I already have a pretty detailed plan to tackle this, which I will
post in a separate RFC email. I plan to start working on this right
away, as it will be good to have this fixed regardless.


Phase 2: Add drm_connector properties mirroring the matching backlight device
=

The plan is to add a drm_connector helper function, which optionally takes
a pointer to the backlight device for the GPU's native backlight device,
which will then mirror the backlight settings from the backlight device
in a set of read/write brightness* properties on the connector.

This function can then be called by GPU drivers for the drm_connector for
the internal panel and it will then take care of everything. When there
is no native GPU backlight device, or when it should not be used then
(on x86) the helper will use the acpi_video_get_backlight_type() to
determine which backlight-device should be used instead and it will find
+ mirror that one.


Phase 3: Deprecate /sys/class/backlight uAPI


Once most userspace has moved over to using the new drm_connector
brightness props, a Kconfig option can be added to stop exporting
the backlight-devices under /sys/class/backlight. The plan is to
just disable the sysfs interface and keep the existing backlight-device
internal kernel abstraction as is, since some abstraction for (non GPU
native) backlight devices will be necessary regardless.

An alternative to disabling the sysfs class entirely, would be
to allow setting it to read-only through Kconfig.


What scale to use for the drm_connector bl_brightness property?
===

The tricky part of this plan is phase 2 and then esp. defining what the
new brightness properties will look like and how they will work.

The biggest challenge here is to decide on a fixed scale for the main
brightness property, say 0-65535, using scaling where the actual hw scale
is different, or if this should simply be a 1:1 mirror of the current
backlight interface, with the actual hw scale / brightness_max value
exposed as a drm_connector property.

1:1 advantages / 0-65535 disadvantages
- Userspace will likely move over to the connector-props quite slowly and
  we can expect various userspace bits, esp. also custom user scripts, to
  keep using the old uAPI for a long time. Using the 2 APIs are intermixed
  is fine when using a 1:1 brightness scale mapping. But if we end up doing
  a scaling round-trip all the time then eventually the brightness is going
  do drift. This can even happen if the user never changes the brightness
  when userspace saves it over suspend/resume or reboots.
- Almost all laptops have brightness up/down hotkeys. E.g GNOME decides
  on a step size for the hotkeys by doing min(brightness_max/20, 1).
  Some of