Re: [PATCH 02/10] drm: Add backlight helper
Den 04.05.2020 14.06, skrev Daniel Vetter: > On Wed, Apr 29, 2020 at 02:48:22PM +0200, Noralf Trønnes wrote: >> This adds a function that creates a backlight device for a connector. >> It does not deal with the KMS backlight ABI proposition[1] to add a >> connector property. It only takes the current best practise to standardise >> the creation of a backlight device for DRM drivers while we wait for the >> property. >> >> The brightness value is set using a connector state variable and an atomic >> commit. >> >> I have looked through some of the backlight users and this is what I've >> found: >> >> GNOME [2] >> - >> >> Brightness range: 0-100 >> Scale: Assumes perceptual >> >> Avoids setting the sysfs brightness value to zero if max_brightness >= 99. >> Can connect connector and backlight using the sysfs device. >> >> KDE [3] >> --- >> >> Brightness range: 0-100 >> Scale: Assumes perceptual >> >> Weston [4] >> -- >> >> Brightness range: 0-255 >> Scale: Assumes perceptual >> >> Chromium OS [5] >> --- >> >> Brightness range: 0-100 >> Scale: Depends on the sysfs file 'scale' which is a recent addition (2019) >> >> xserver [6] >> --- >> >> Brightness range: 0-x (driver specific) (1 is minimum, 0 is OFF) >> Scale: Assumes perceptual >> >> The builtin modesetting driver[7] does not support Backlight, Intel[8] does. >> >> [1] >> https://lore.kernel.org/dri-devel/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ >> [2] >> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/power/gsd-backlight.c >> [3] >> https://github.com/KDE/powerdevil/blob/master/daemon/backends/upower/backlighthelper.cpp >> [4] >> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/drm.c >> [5] >> https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/master/power_manager/powerd/system/internal_backlight.cc >> [6] https://github.com/freedesktop/xorg-randrproto/blob/master/randrproto.txt >> [7] >> https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c >> [8] >> https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/blob/master/src/backlight.c >> >> Cc: Hans de Goede >> Cc: Jani Nikula >> Cc: Martin Peres >> Cc: Daniel Thompson >> Signed-off-by: Noralf Trønnes >> --- >> Documentation/gpu/drm-kms-helpers.rst | 6 + >> drivers/gpu/drm/Kconfig| 7 ++ >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/drm_backlight_helper.c | 154 + >> include/drm/drm_backlight_helper.h | 9 ++ >> include/drm/drm_connector.h| 10 ++ >> 6 files changed, 187 insertions(+) >> create mode 100644 drivers/gpu/drm/drm_backlight_helper.c >> create mode 100644 include/drm/drm_backlight_helper.h >> >> diff --git a/Documentation/gpu/drm-kms-helpers.rst >> b/Documentation/gpu/drm-kms-helpers.rst >> index 9668a7fe2408..29a2f4b49fd2 100644 >> --- a/Documentation/gpu/drm-kms-helpers.rst >> +++ b/Documentation/gpu/drm-kms-helpers.rst >> @@ -411,3 +411,9 @@ SHMEM GEM Helper Reference >> >> .. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c >> :export: >> + >> +Backlight Helper Reference >> +== >> + >> +.. kernel-doc:: drivers/gpu/drm/drm_backlight_helper.c >> + :export: >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index d0aa6cff2e02..f6e13e18c9ca 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -224,6 +224,13 @@ config DRM_GEM_SHMEM_HELPER >> help >>Choose this if you need the GEM shmem helper functions >> >> +config DRM_BACKLIGHT_HELPER >> +bool >> +depends on DRM >> +select BACKLIGHT_CLASS_DEVICE >> +help >> + Choose this if you need the backlight device helper functions >> + >> config DRM_VM >> bool >> depends on DRM && MMU >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index 6493088a0fdd..0d17662dde0a 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -52,6 +52,7 @@ drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += >> drm_fb_helper.o >> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o >> drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o >> drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o >> +drm_kms_helper-$(CONFIG_DRM_BACKLIGHT_HELPER) += drm_backlight_helper.o >> >> obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o >> obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/ >> diff --git a/drivers/gpu/drm/drm_backlight_helper.c >> b/drivers/gpu/drm/drm_backlight_helper.c >> new file mode 100644 >> index ..06e6a75d1d0a >> --- /dev/null >> +++ b/drivers/gpu/drm/drm_backlight_helper.c >> @@ -0,0 +1,154 @@ >> +// SPDX-License-Identifier: GPL-2.0 OR MIT >> +/* >> + * Copyright 2020 Noralf Trønnes >> + */ >> + >> +#include >> + >> +#include >> +#include >> +#include >> +#include
Re: [PATCH 02/10] drm: Add backlight helper
On Wed, Apr 29, 2020 at 02:48:22PM +0200, Noralf Trønnes wrote:
> This adds a function that creates a backlight device for a connector.
> It does not deal with the KMS backlight ABI proposition[1] to add a
> connector property. It only takes the current best practise to standardise
> the creation of a backlight device for DRM drivers while we wait for the
> property.
>
> The brightness value is set using a connector state variable and an atomic
> commit.
>
> I have looked through some of the backlight users and this is what I've found:
>
> GNOME [2]
> -
>
> Brightness range: 0-100
> Scale: Assumes perceptual
>
> Avoids setting the sysfs brightness value to zero if max_brightness >= 99.
> Can connect connector and backlight using the sysfs device.
>
> KDE [3]
> ---
>
> Brightness range: 0-100
> Scale: Assumes perceptual
>
> Weston [4]
> --
>
> Brightness range: 0-255
> Scale: Assumes perceptual
>
> Chromium OS [5]
> ---
>
> Brightness range: 0-100
> Scale: Depends on the sysfs file 'scale' which is a recent addition (2019)
>
> xserver [6]
> ---
>
> Brightness range: 0-x (driver specific) (1 is minimum, 0 is OFF)
> Scale: Assumes perceptual
>
> The builtin modesetting driver[7] does not support Backlight, Intel[8] does.
>
> [1]
> https://lore.kernel.org/dri-devel/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> [2]
> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/power/gsd-backlight.c
> [3]
> https://github.com/KDE/powerdevil/blob/master/daemon/backends/upower/backlighthelper.cpp
> [4]
> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/drm.c
> [5]
> https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/master/power_manager/powerd/system/internal_backlight.cc
> [6] https://github.com/freedesktop/xorg-randrproto/blob/master/randrproto.txt
> [7]
> https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c
> [8]
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/blob/master/src/backlight.c
>
> Cc: Hans de Goede
> Cc: Jani Nikula
> Cc: Martin Peres
> Cc: Daniel Thompson
> Signed-off-by: Noralf Trønnes
> ---
> Documentation/gpu/drm-kms-helpers.rst | 6 +
> drivers/gpu/drm/Kconfig| 7 ++
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_backlight_helper.c | 154 +
> include/drm/drm_backlight_helper.h | 9 ++
> include/drm/drm_connector.h| 10 ++
> 6 files changed, 187 insertions(+)
> create mode 100644 drivers/gpu/drm/drm_backlight_helper.c
> create mode 100644 include/drm/drm_backlight_helper.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 9668a7fe2408..29a2f4b49fd2 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -411,3 +411,9 @@ SHMEM GEM Helper Reference
>
> .. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
> :export:
> +
> +Backlight Helper Reference
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_backlight_helper.c
> + :export:
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index d0aa6cff2e02..f6e13e18c9ca 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -224,6 +224,13 @@ config DRM_GEM_SHMEM_HELPER
> help
> Choose this if you need the GEM shmem helper functions
>
> +config DRM_BACKLIGHT_HELPER
> + bool
> + depends on DRM
> + select BACKLIGHT_CLASS_DEVICE
> + help
> + Choose this if you need the backlight device helper functions
> +
> config DRM_VM
> bool
> depends on DRM && MMU
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 6493088a0fdd..0d17662dde0a 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -52,6 +52,7 @@ drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) +=
> drm_fb_helper.o
> drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
> +drm_kms_helper-$(CONFIG_DRM_BACKLIGHT_HELPER) += drm_backlight_helper.o
>
> obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
> diff --git a/drivers/gpu/drm/drm_backlight_helper.c
> b/drivers/gpu/drm/drm_backlight_helper.c
> new file mode 100644
> index ..06e6a75d1d0a
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_backlight_helper.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright 2020 Noralf Trønnes
> + */
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static int drm_backlight_update_status(struct backlight_device *bd)
> +{
> + struct drm_connector *connector = bl_get_data(bd);
> + struct
Re: [PATCH 02/10] drm: Add backlight helper
Hi, On 4/29/20 8:40 PM, Noralf Trønnes wrote: Den 29.04.2020 16.13, skrev Hans de Goede: Hi Noralf, On 4/29/20 2:48 PM, Noralf Trønnes wrote: This adds a function that creates a backlight device for a connector. It does not deal with the KMS backlight ABI proposition[1] to add a connector property. It only takes the current best practise to standardise the creation of a backlight device for DRM drivers while we wait for the property. The brightness value is set using a connector state variable and an atomic commit. I have looked through some of the backlight users and this is what I've found: GNOME [2] - Brightness range: 0-100 Scale: Assumes perceptual I'm afraid that this is an incaccurate view of how GNOME handles the brightness. gnome-settings-daemon (g-s-d) exports a DBUS property which has a range of 0 - 100%. But it also offers step-up and step-down DBUS methods which are used for handling brightness hotkey presses. This is important because g-s-d internally also keeps a step_size variable which depends on the brightness_max value of the sysfs backlight interface, like this: BRIGHTNESS_STEP_AMOUNT(max) ((max) < 20 ? 1 : (max) / 20) This is important because some older laptops where we depend on the vendor specific ACPI method (from e.g. dell-laptop or thinkpad_acpi) there are only 8 levels. So if g-s-d where to simply fake a 1-100 range and would leave the stepping up to the DBus API user and that user would want 20 steps, so 5 % per step, then the user would get Start -> 100% -> level 8 Press down -> 95% -> level 7 Press down -> 90% -> level 7 *no change* etc. Somewhat related on some embedded ARM devices there are tricks where when the entire scene being rendered does not use 100% white as color, the entire scene has all its rgb values upscaled (too a curve) so that the brightest colors do hit 100% of one of r/g/b, combined with dimming the backlight a bit to save power. As you can imagine for tricks like these you want as much backlight control precision as possible. So any backlight infra we add must expose the true range of the backlight control and not normalize it to a 0-100 range. So sorry, but nack for the current version because of the hardcoding of the range. No problem, I just had to start from somewhere, and I started with: Give the driver developer as few options as possible, no more than necessary, but I didn't really know what was necessary :-) The reason I chose a 0-100 range is because the backlight property ABI proposal had this range and it maps so nicely to percent. And can the ordinary human see brightness changes in more than 100 steps? This helper is only to be used by drm drivers and I assumed that all the current drivers registering a backlight device could at least do that range. Looking through the drivers and their max_brightness values that assumption isn't quite right: amd: 255 gma500: 100 i915: nouveau/nv40: 31 nouveau/nv50: 100 radeon: 255 shmobile: panel-dsi-cm.c: 255 panel-jdi-lt070me05000.c: 255 panel-orisetech-otm8009a.c: 255 panel-raydium-rm67191.c: 255 panel-samsung-s6e63m0.c: 10 panel-sony-acx424akp.c: 1023 panel-samsung-s6e3ha2.c: 100 panel-samsung-s6e63j0x03.c: 100 panel-sony-acx565akm.c: 255 bridge/parade-ps8622.c: 255 I'll add max_brightness as an argument together with scale which you commented on below. Ok, sounds good. Also the scale really should be specified by the driver, or be hardcoded to BACKLIGHT_SCALE_UNKNOWN for now. In many cases we do not really know. But for e.g. the acpi_video firmware backlight interface a good guess is that it actually represents a perceptual scale rather then controlling the wattage. Where as the native i915 backlight interface really is controlling the wattage without any perceptual correction. Another problem with your proposal is that it seems to assume that the backlight is controlled by the drm/kms driver. On x86 we have Yes, this backlight device is just for drm drivers. I was hoping you might have some clever ideas how to deal with / prepare for the backlight driver outside of drm-driver case too. But I completely understand that you want to limit your scope. The reason I spend time on this is because I want to pass backlight brightness changes through the atomic machinery like any other state change. I understand. Regards, Hans atleast 3 different drivers for the backlight: 1) The i915 (or amd/nouveau) native driver which more or less directly pokes the PWM controller of the GPU. 2) The ACPI video standard backlight interface 3) Vendor specific ACPI interfaces from older laptops ATM we always register 1. which could remain unchanged with your code and then also register 2/3 if we (the kernel) think that will work better (*) and then rely on userspace prefering these (they have a different backlight_type) over 1. Ideally any infra we add will also offer the option to tie 2. or 3. to the connector... Regards, Hans *) e.g. it will
Re: [PATCH 02/10] drm: Add backlight helper
Den 29.04.2020 16.13, skrev Hans de Goede: > Hi Noralf, > > On 4/29/20 2:48 PM, Noralf Trønnes wrote: >> This adds a function that creates a backlight device for a connector. >> It does not deal with the KMS backlight ABI proposition[1] to add a >> connector property. It only takes the current best practise to >> standardise >> the creation of a backlight device for DRM drivers while we wait for the >> property. >> >> The brightness value is set using a connector state variable and an >> atomic >> commit. >> >> I have looked through some of the backlight users and this is what >> I've found: >> >> GNOME [2] >> - >> >> Brightness range: 0-100 >> Scale: Assumes perceptual > > I'm afraid that this is an incaccurate view of how GNOME handles the > brightness. gnome-settings-daemon (g-s-d) exports a DBUS property which has > a range of 0 - 100%. But it also offers step-up and step-down DBUS methods > which are used for handling brightness hotkey presses. > > This is important because g-s-d internally also keeps a step_size variable > which depends on the brightness_max value of the sysfs backlight interface, > like this: > > BRIGHTNESS_STEP_AMOUNT(max) ((max) < 20 ? 1 : (max) / 20) > > This is important because some older laptops where we depend on the > vendor specific ACPI method (from e.g. dell-laptop or thinkpad_acpi) > there are only 8 levels. So if g-s-d where to simply fake a 1-100 > range and would leave the stepping up to the DBus API user and that > user would want 20 steps, so 5 % per step, then the user would get > > Start -> 100% -> level 8 > Press down -> 95% -> level 7 > Press down -> 90% -> level 7 *no change* > etc. > > Somewhat related on some embedded ARM devices there are tricks where > when the entire scene being rendered does not use 100% white as color, > the entire scene has all its rgb values upscaled (too a curve) so that > the brightest colors do hit 100% of one of r/g/b, combined with dimming > the backlight a bit to save power. As you can imagine for tricks like > these you want as much backlight control precision as possible. > > So any backlight infra we add must expose the true range of the > backlight control and not normalize it to a 0-100 range. > > So sorry, but nack for the current version because of the hardcoding > of the range. No problem, I just had to start from somewhere, and I started with: Give the driver developer as few options as possible, no more than necessary, but I didn't really know what was necessary :-) The reason I chose a 0-100 range is because the backlight property ABI proposal had this range and it maps so nicely to percent. And can the ordinary human see brightness changes in more than 100 steps? This helper is only to be used by drm drivers and I assumed that all the current drivers registering a backlight device could at least do that range. Looking through the drivers and their max_brightness values that assumption isn't quite right: amd: 255 gma500: 100 i915: nouveau/nv40: 31 nouveau/nv50: 100 radeon: 255 shmobile: panel-dsi-cm.c: 255 panel-jdi-lt070me05000.c: 255 panel-orisetech-otm8009a.c: 255 panel-raydium-rm67191.c: 255 panel-samsung-s6e63m0.c: 10 panel-sony-acx424akp.c: 1023 panel-samsung-s6e3ha2.c: 100 panel-samsung-s6e63j0x03.c: 100 panel-sony-acx565akm.c: 255 bridge/parade-ps8622.c: 255 I'll add max_brightness as an argument together with scale which you commented on below. > > Also the scale really should be specified by the driver, or be hardcoded > to BACKLIGHT_SCALE_UNKNOWN for now. In many cases we do not really know. > But for e.g. the acpi_video firmware backlight interface a good guess is > that it actually represents a perceptual scale rather then controlling > the wattage. > > Where as the native i915 backlight interface really is controlling > the wattage without any perceptual correction. > > Another problem with your proposal is that it seems to assume that > the backlight is controlled by the drm/kms driver. On x86 we have Yes, this backlight device is just for drm drivers. The reason I spend time on this is because I want to pass backlight brightness changes through the atomic machinery like any other state change. Noralf. > atleast 3 different drivers for the backlight: > > 1) The i915 (or amd/nouveau) native driver which more or less > directly pokes the PWM controller of the GPU. > 2) The ACPI video standard backlight interface > 3) Vendor specific ACPI interfaces from older laptops > > ATM we always register 1. which could remain unchanged with > your code and then also register 2/3 if we (the kernel) think > that will work better (*) and then rely on userspace prefering > these (they have a different backlight_type) over 1. > > Ideally any infra we add will also offer the option to tie > 2. or 3. to the connector... > > Regards, > > Hans > > > > *) e.g. it will work while the others will not work at all > > > > >> >> Avoids setting the sysfs brightness value to
Re: [PATCH 02/10] drm: Add backlight helper
Hi Noralf, On 4/29/20 2:48 PM, Noralf Trønnes wrote: This adds a function that creates a backlight device for a connector. It does not deal with the KMS backlight ABI proposition[1] to add a connector property. It only takes the current best practise to standardise the creation of a backlight device for DRM drivers while we wait for the property. The brightness value is set using a connector state variable and an atomic commit. I have looked through some of the backlight users and this is what I've found: GNOME [2] - Brightness range: 0-100 Scale: Assumes perceptual I'm afraid that this is an incaccurate view of how GNOME handles the brightness. gnome-settings-daemon (g-s-d) exports a DBUS property which has a range of 0 - 100%. But it also offers step-up and step-down DBUS methods which are used for handling brightness hotkey presses. This is important because g-s-d internally also keeps a step_size variable which depends on the brightness_max value of the sysfs backlight interface, like this: BRIGHTNESS_STEP_AMOUNT(max) ((max) < 20 ? 1 : (max) / 20) This is important because some older laptops where we depend on the vendor specific ACPI method (from e.g. dell-laptop or thinkpad_acpi) there are only 8 levels. So if g-s-d where to simply fake a 1-100 range and would leave the stepping up to the DBus API user and that user would want 20 steps, so 5 % per step, then the user would get Start -> 100% -> level 8 Press down -> 95% -> level 7 Press down -> 90% -> level 7 *no change* etc. Somewhat related on some embedded ARM devices there are tricks where when the entire scene being rendered does not use 100% white as color, the entire scene has all its rgb values upscaled (too a curve) so that the brightest colors do hit 100% of one of r/g/b, combined with dimming the backlight a bit to save power. As you can imagine for tricks like these you want as much backlight control precision as possible. So any backlight infra we add must expose the true range of the backlight control and not normalize it to a 0-100 range. So sorry, but nack for the current version because of the hardcoding of the range. Also the scale really should be specified by the driver, or be hardcoded to BACKLIGHT_SCALE_UNKNOWN for now. In many cases we do not really know. But for e.g. the acpi_video firmware backlight interface a good guess is that it actually represents a perceptual scale rather then controlling the wattage. Where as the native i915 backlight interface really is controlling the wattage without any perceptual correction. Another problem with your proposal is that it seems to assume that the backlight is controlled by the drm/kms driver. On x86 we have atleast 3 different drivers for the backlight: 1) The i915 (or amd/nouveau) native driver which more or less directly pokes the PWM controller of the GPU. 2) The ACPI video standard backlight interface 3) Vendor specific ACPI interfaces from older laptops ATM we always register 1. which could remain unchanged with your code and then also register 2/3 if we (the kernel) think that will work better (*) and then rely on userspace prefering these (they have a different backlight_type) over 1. Ideally any infra we add will also offer the option to tie 2. or 3. to the connector... Regards, Hans *) e.g. it will work while the others will not work at all Avoids setting the sysfs brightness value to zero if max_brightness >= 99. Can connect connector and backlight using the sysfs device. KDE [3] --- Brightness range: 0-100 Scale: Assumes perceptual Weston [4] -- Brightness range: 0-255 Scale: Assumes perceptual Chromium OS [5] --- Brightness range: 0-100 Scale: Depends on the sysfs file 'scale' which is a recent addition (2019) xserver [6] --- Brightness range: 0-x (driver specific) (1 is minimum, 0 is OFF) Scale: Assumes perceptual The builtin modesetting driver[7] does not support Backlight, Intel[8] does. [1] https://lore.kernel.org/dri-devel/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ [2] https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/power/gsd-backlight.c [3] https://github.com/KDE/powerdevil/blob/master/daemon/backends/upower/backlighthelper.cpp [4] https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/drm.c [5] https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/master/power_manager/powerd/system/internal_backlight.cc [6] https://github.com/freedesktop/xorg-randrproto/blob/master/randrproto.txt [7] https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c [8] https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/blob/master/src/backlight.c Cc: Hans de Goede Cc: Jani Nikula Cc: Martin Peres Cc: Daniel Thompson Signed-off-by: Noralf Trønnes --- Documentation/gpu/drm-kms-helpers.rst | 6 + drivers/gpu/drm/Kconfig| 7 ++
[PATCH 02/10] drm: Add backlight helper
This adds a function that creates a backlight device for a connector.
It does not deal with the KMS backlight ABI proposition[1] to add a
connector property. It only takes the current best practise to standardise
the creation of a backlight device for DRM drivers while we wait for the
property.
The brightness value is set using a connector state variable and an atomic
commit.
I have looked through some of the backlight users and this is what I've found:
GNOME [2]
-
Brightness range: 0-100
Scale: Assumes perceptual
Avoids setting the sysfs brightness value to zero if max_brightness >= 99.
Can connect connector and backlight using the sysfs device.
KDE [3]
---
Brightness range: 0-100
Scale: Assumes perceptual
Weston [4]
--
Brightness range: 0-255
Scale: Assumes perceptual
Chromium OS [5]
---
Brightness range: 0-100
Scale: Depends on the sysfs file 'scale' which is a recent addition (2019)
xserver [6]
---
Brightness range: 0-x (driver specific) (1 is minimum, 0 is OFF)
Scale: Assumes perceptual
The builtin modesetting driver[7] does not support Backlight, Intel[8] does.
[1]
https://lore.kernel.org/dri-devel/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
[2]
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/plugins/power/gsd-backlight.c
[3]
https://github.com/KDE/powerdevil/blob/master/daemon/backends/upower/backlighthelper.cpp
[4]
https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/drm.c
[5]
https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/master/power_manager/powerd/system/internal_backlight.cc
[6] https://github.com/freedesktop/xorg-randrproto/blob/master/randrproto.txt
[7]
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c
[8]
https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/blob/master/src/backlight.c
Cc: Hans de Goede
Cc: Jani Nikula
Cc: Martin Peres
Cc: Daniel Thompson
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/drm-kms-helpers.rst | 6 +
drivers/gpu/drm/Kconfig| 7 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_backlight_helper.c | 154 +
include/drm/drm_backlight_helper.h | 9 ++
include/drm/drm_connector.h| 10 ++
6 files changed, 187 insertions(+)
create mode 100644 drivers/gpu/drm/drm_backlight_helper.c
create mode 100644 include/drm/drm_backlight_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 9668a7fe2408..29a2f4b49fd2 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -411,3 +411,9 @@ SHMEM GEM Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
:export:
+
+Backlight Helper Reference
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_backlight_helper.c
+ :export:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d0aa6cff2e02..f6e13e18c9ca 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -224,6 +224,13 @@ config DRM_GEM_SHMEM_HELPER
help
Choose this if you need the GEM shmem helper functions
+config DRM_BACKLIGHT_HELPER
+ bool
+ depends on DRM
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ Choose this if you need the backlight device helper functions
+
config DRM_VM
bool
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6493088a0fdd..0d17662dde0a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) +=
drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
+drm_kms_helper-$(CONFIG_DRM_BACKLIGHT_HELPER) += drm_backlight_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
diff --git a/drivers/gpu/drm/drm_backlight_helper.c
b/drivers/gpu/drm/drm_backlight_helper.c
new file mode 100644
index ..06e6a75d1d0a
--- /dev/null
+++ b/drivers/gpu/drm/drm_backlight_helper.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright 2020 Noralf Trønnes
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+
+static int drm_backlight_update_status(struct backlight_device *bd)
+{
+ struct drm_connector *connector = bl_get_data(bd);
+ struct drm_connector_state *connector_state;
+ struct drm_device *dev = connector->dev;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_atomic_state *state;
+ int ret;
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return -ENOMEM;
+
+ drm_modeset_acquire_init(, 0);
+
