* [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs @ 2019-07-09 19:00 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve is currently opaque to userspace, so userspace often relies on more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via a new sysfs attribute. Matthias Kaehlcke (4): MAINTAINERS: Add entry for stable backlight sysfs ABI documentation backlight: Expose brightness curve type through sysfs backlight: pwm_bl: Set scale type for CIE 1931 curves backlight: pwm_bl: Set scale type for brightness curves specified in the DT .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ MAINTAINERS | 2 ++ drivers/video/backlight/backlight.c | 19 ++++++++++ drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- include/linux/backlight.h | 8 +++++ 5 files changed, 89 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs @ 2019-07-09 19:00 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve is currently opaque to userspace, so userspace often relies on more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via a new sysfs attribute. Matthias Kaehlcke (4): MAINTAINERS: Add entry for stable backlight sysfs ABI documentation backlight: Expose brightness curve type through sysfs backlight: pwm_bl: Set scale type for CIE 1931 curves backlight: pwm_bl: Set scale type for brightness curves specified in the DT .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ MAINTAINERS | 2 ++ drivers/video/backlight/backlight.c | 19 ++++++++++ drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- include/linux/backlight.h | 8 +++++ 5 files changed, 89 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-07-09 19:00 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke Add an entry for the stable backlight sysfs ABI to the MAINTAINERS file. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> --- Changes in v3: - none Changes in v2: - added Daniel's 'Acked-by' tag --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 57f496cff999..d51e74340870 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2857,6 +2857,7 @@ F: drivers/video/backlight/ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight +F: Documentation/ABI/stable/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner <mareklindner@neomailbox.ch> -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation @ 2019-07-09 19:00 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke Add an entry for the stable backlight sysfs ABI to the MAINTAINERS file. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> --- Changes in v3: - none Changes in v2: - added Daniel's 'Acked-by' tag --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 57f496cff999..d51e74340870 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2857,6 +2857,7 @@ F: drivers/video/backlight/ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight +F: Documentation/ABI/stable/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner <mareklindner@neomailbox.ch> -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation 2019-07-09 19:00 ` Matthias Kaehlcke (?) @ 2019-09-02 9:41 ` Lee Jones -1 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:41 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > Add an entry for the stable backlight sysfs ABI to the MAINTAINERS > file. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > Changes in v3: > - none > > Changes in v2: > - added Daniel's 'Acked-by' tag > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation @ 2019-09-02 9:41 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:41 UTC (permalink / raw) To: Matthias Kaehlcke Cc: linux-pwm, Daniel Thompson, Douglas Anderson, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > Add an entry for the stable backlight sysfs ABI to the MAINTAINERS > file. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > Changes in v3: > - none > > Changes in v2: > - added Daniel's 'Acked-by' tag > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation @ 2019-09-02 9:41 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:41 UTC (permalink / raw) To: Matthias Kaehlcke Cc: linux-pwm, Daniel Thompson, Douglas Anderson, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > Add an entry for the stable backlight sysfs ABI to the MAINTAINERS > file. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > Changes in v3: > - none > > Changes in v2: > - added Daniel's 'Acked-by' tag > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-07-09 19:00 ` Matthias Kaehlcke (?) @ 2019-07-09 19:00 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve currently is opaque to userspace, so userspace often uses more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via the new sysfs attribute 'scale'. The value of the attribute can be 'linear', 'non-linear' or 'unknown'. For devices that don't provide information about the scale of their brightness curve the value of the 'scale' attribute is 'unknown'. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> --- Feel free to suggest improvements in the documentation :) Changes in v3: - removed composite strings, only keep 'linear', 'non-linear' and 'unknown' - updated sysfs attribute documentation - updated commit message Changes in v2: - changed order of brightness scale enums, explicitly make 'unknown' zero - minor update of commit message - deleted excess blank line after 'backlight_scale_types' - s/curves/curve/ in sysfs doc --- .../ABI/testing/sysfs-class-backlight | 26 +++++++++++++++++++ MAINTAINERS | 1 + drivers/video/backlight/backlight.c | 19 ++++++++++++++ include/linux/backlight.h | 8 ++++++ 4 files changed, 54 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight diff --git a/Documentation/ABI/testing/sysfs-class-backlight b/Documentation/ABI/testing/sysfs-class-backlight new file mode 100644 index 000000000000..3ab175a3f5cb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight @@ -0,0 +1,26 @@ +What: /sys/class/backlight/<backlight>/scale +Date: July 2019 +KernelVersion: 5.4 +Contact: Daniel Thompson <daniel.thompson@linaro.org> +Description: + Description of the scale of the brightness curve. + + The human eye senses brightness approximately logarithmically, + hence linear changes in brightness are perceived as being + non-linear. To achieve a linear perception of brightness changes + controls like sliders need to apply a logarithmic mapping for + backlights with a linear brightness curve. + + Possible values of the attribute are: + + unknown + The scale of the brightness curve is unknown. + + linear + The brightness changes linearly with each step. Brightness + controls should apply a logarithmic mapping for a linear + perception. + + non-linear + The brightness changes non-linearly with each step. Brightness + controls should use a linear mapping for a linear perception. diff --git a/MAINTAINERS b/MAINTAINERS index d51e74340870..c46812510ba5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2858,6 +2858,7 @@ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight F: Documentation/ABI/stable/sysfs-class-backlight +F: Documentation/ABI/testing/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner <mareklindner@neomailbox.ch> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 1ef8b6fd62ac..277abc76c83a 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -32,6 +32,12 @@ static const char *const backlight_types[] = { [BACKLIGHT_FIRMWARE] = "firmware", }; +static const char *const backlight_scale_types[] = { + [BACKLIGHT_SCALE_UNKNOWN] = "unknown", + [BACKLIGHT_SCALE_LINEAR] = "linear", + [BACKLIGHT_SCALE_NON_LINEAR] = "non-linear", +}; + #if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \ defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)) /* This callback gets called when something important happens inside a @@ -246,6 +252,18 @@ static ssize_t actual_brightness_show(struct device *dev, } static DEVICE_ATTR_RO(actual_brightness); +static ssize_t scale_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct backlight_device *bd = to_backlight_device(dev); + + if (WARN_ON(bd->props.scale > BACKLIGHT_SCALE_NON_LINEAR)) + return sprintf(buf, "unknown\n"); + + return sprintf(buf, "%s\n", backlight_scale_types[bd->props.scale]); +} +static DEVICE_ATTR_RO(scale); + static struct class *backlight_class; #ifdef CONFIG_PM_SLEEP @@ -292,6 +310,7 @@ static struct attribute *bl_device_attrs[] = { &dev_attr_brightness.attr, &dev_attr_actual_brightness.attr, &dev_attr_max_brightness.attr, + &dev_attr_scale.attr, &dev_attr_type.attr, NULL, }; diff --git a/include/linux/backlight.h b/include/linux/backlight.h index 0b5897446dca..c7d6b2e8c3b5 100644 --- a/include/linux/backlight.h +++ b/include/linux/backlight.h @@ -46,6 +46,12 @@ enum backlight_notification { BACKLIGHT_UNREGISTERED, }; +enum backlight_scale { + BACKLIGHT_SCALE_UNKNOWN = 0, + BACKLIGHT_SCALE_LINEAR, + BACKLIGHT_SCALE_NON_LINEAR, +}; + struct backlight_device; struct fb_info; @@ -80,6 +86,8 @@ struct backlight_properties { enum backlight_type type; /* Flags used to signal drivers of state changes */ unsigned int state; + /* Type of the brightness scale (linear, non-linear, ...) */ + enum backlight_scale scale; #define BL_CORE_SUSPENDED (1 << 0) /* backlight is suspended */ #define BL_CORE_FBBLANK (1 << 1) /* backlight is under an fb blank event */ -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-07-09 19:00 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, linux-fbdev, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Matthias Kaehlcke, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve currently is opaque to userspace, so userspace often uses more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via the new sysfs attribute 'scale'. The value of the attribute can be 'linear', 'non-linear' or 'unknown'. For devices that don't provide information about the scale of their brightness curve the value of the 'scale' attribute is 'unknown'. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> --- Feel free to suggest improvements in the documentation :) Changes in v3: - removed composite strings, only keep 'linear', 'non-linear' and 'unknown' - updated sysfs attribute documentation - updated commit message Changes in v2: - changed order of brightness scale enums, explicitly make 'unknown' zero - minor update of commit message - deleted excess blank line after 'backlight_scale_types' - s/curves/curve/ in sysfs doc --- .../ABI/testing/sysfs-class-backlight | 26 +++++++++++++++++++ MAINTAINERS | 1 + drivers/video/backlight/backlight.c | 19 ++++++++++++++ include/linux/backlight.h | 8 ++++++ 4 files changed, 54 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight diff --git a/Documentation/ABI/testing/sysfs-class-backlight b/Documentation/ABI/testing/sysfs-class-backlight new file mode 100644 index 000000000000..3ab175a3f5cb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight @@ -0,0 +1,26 @@ +What: /sys/class/backlight/<backlight>/scale +Date: July 2019 +KernelVersion: 5.4 +Contact: Daniel Thompson <daniel.thompson@linaro.org> +Description: + Description of the scale of the brightness curve. + + The human eye senses brightness approximately logarithmically, + hence linear changes in brightness are perceived as being + non-linear. To achieve a linear perception of brightness changes + controls like sliders need to apply a logarithmic mapping for + backlights with a linear brightness curve. + + Possible values of the attribute are: + + unknown + The scale of the brightness curve is unknown. + + linear + The brightness changes linearly with each step. Brightness + controls should apply a logarithmic mapping for a linear + perception. + + non-linear + The brightness changes non-linearly with each step. Brightness + controls should use a linear mapping for a linear perception. diff --git a/MAINTAINERS b/MAINTAINERS index d51e74340870..c46812510ba5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2858,6 +2858,7 @@ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight F: Documentation/ABI/stable/sysfs-class-backlight +F: Documentation/ABI/testing/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner <mareklindner@neomailbox.ch> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 1ef8b6fd62ac..277abc76c83a 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -32,6 +32,12 @@ static const char *const backlight_types[] = { [BACKLIGHT_FIRMWARE] = "firmware", }; +static const char *const backlight_scale_types[] = { + [BACKLIGHT_SCALE_UNKNOWN] = "unknown", + [BACKLIGHT_SCALE_LINEAR] = "linear", + [BACKLIGHT_SCALE_NON_LINEAR] = "non-linear", +}; + #if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \ defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)) /* This callback gets called when something important happens inside a @@ -246,6 +252,18 @@ static ssize_t actual_brightness_show(struct device *dev, } static DEVICE_ATTR_RO(actual_brightness); +static ssize_t scale_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct backlight_device *bd = to_backlight_device(dev); + + if (WARN_ON(bd->props.scale > BACKLIGHT_SCALE_NON_LINEAR)) + return sprintf(buf, "unknown\n"); + + return sprintf(buf, "%s\n", backlight_scale_types[bd->props.scale]); +} +static DEVICE_ATTR_RO(scale); + static struct class *backlight_class; #ifdef CONFIG_PM_SLEEP @@ -292,6 +310,7 @@ static struct attribute *bl_device_attrs[] = { &dev_attr_brightness.attr, &dev_attr_actual_brightness.attr, &dev_attr_max_brightness.attr, + &dev_attr_scale.attr, &dev_attr_type.attr, NULL, }; diff --git a/include/linux/backlight.h b/include/linux/backlight.h index 0b5897446dca..c7d6b2e8c3b5 100644 --- a/include/linux/backlight.h +++ b/include/linux/backlight.h @@ -46,6 +46,12 @@ enum backlight_notification { BACKLIGHT_UNREGISTERED, }; +enum backlight_scale { + BACKLIGHT_SCALE_UNKNOWN = 0, + BACKLIGHT_SCALE_LINEAR, + BACKLIGHT_SCALE_NON_LINEAR, +}; + struct backlight_device; struct fb_info; @@ -80,6 +86,8 @@ struct backlight_properties { enum backlight_type type; /* Flags used to signal drivers of state changes */ unsigned int state; + /* Type of the brightness scale (linear, non-linear, ...) */ + enum backlight_scale scale; #define BL_CORE_SUSPENDED (1 << 0) /* backlight is suspended */ #define BL_CORE_FBBLANK (1 << 1) /* backlight is under an fb blank event */ -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-07-09 19:00 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, linux-fbdev, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Matthias Kaehlcke, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra Backlight brightness curves can have different shapes. The two main types are linear and non-linear curves. The human eye doesn't perceive linearly increasing/decreasing brightness as linear (see also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED linearly to human eye"), hence many backlights use non-linear (often logarithmic) brightness curves. The type of curve currently is opaque to userspace, so userspace often uses more or less reliable heuristics (like the number of brightness levels) to decide whether to treat a backlight device as linear or non-linear. Export the type of the brightness curve via the new sysfs attribute 'scale'. The value of the attribute can be 'linear', 'non-linear' or 'unknown'. For devices that don't provide information about the scale of their brightness curve the value of the 'scale' attribute is 'unknown'. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> --- Feel free to suggest improvements in the documentation :) Changes in v3: - removed composite strings, only keep 'linear', 'non-linear' and 'unknown' - updated sysfs attribute documentation - updated commit message Changes in v2: - changed order of brightness scale enums, explicitly make 'unknown' zero - minor update of commit message - deleted excess blank line after 'backlight_scale_types' - s/curves/curve/ in sysfs doc --- .../ABI/testing/sysfs-class-backlight | 26 +++++++++++++++++++ MAINTAINERS | 1 + drivers/video/backlight/backlight.c | 19 ++++++++++++++ include/linux/backlight.h | 8 ++++++ 4 files changed, 54 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight diff --git a/Documentation/ABI/testing/sysfs-class-backlight b/Documentation/ABI/testing/sysfs-class-backlight new file mode 100644 index 000000000000..3ab175a3f5cb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight @@ -0,0 +1,26 @@ +What: /sys/class/backlight/<backlight>/scale +Date: July 2019 +KernelVersion: 5.4 +Contact: Daniel Thompson <daniel.thompson@linaro.org> +Description: + Description of the scale of the brightness curve. + + The human eye senses brightness approximately logarithmically, + hence linear changes in brightness are perceived as being + non-linear. To achieve a linear perception of brightness changes + controls like sliders need to apply a logarithmic mapping for + backlights with a linear brightness curve. + + Possible values of the attribute are: + + unknown + The scale of the brightness curve is unknown. + + linear + The brightness changes linearly with each step. Brightness + controls should apply a logarithmic mapping for a linear + perception. + + non-linear + The brightness changes non-linearly with each step. Brightness + controls should use a linear mapping for a linear perception. diff --git a/MAINTAINERS b/MAINTAINERS index d51e74340870..c46812510ba5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2858,6 +2858,7 @@ F: include/linux/backlight.h F: include/linux/pwm_backlight.h F: Documentation/devicetree/bindings/leds/backlight F: Documentation/ABI/stable/sysfs-class-backlight +F: Documentation/ABI/testing/sysfs-class-backlight BATMAN ADVANCED M: Marek Lindner <mareklindner@neomailbox.ch> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 1ef8b6fd62ac..277abc76c83a 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -32,6 +32,12 @@ static const char *const backlight_types[] = { [BACKLIGHT_FIRMWARE] = "firmware", }; +static const char *const backlight_scale_types[] = { + [BACKLIGHT_SCALE_UNKNOWN] = "unknown", + [BACKLIGHT_SCALE_LINEAR] = "linear", + [BACKLIGHT_SCALE_NON_LINEAR] = "non-linear", +}; + #if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \ defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)) /* This callback gets called when something important happens inside a @@ -246,6 +252,18 @@ static ssize_t actual_brightness_show(struct device *dev, } static DEVICE_ATTR_RO(actual_brightness); +static ssize_t scale_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct backlight_device *bd = to_backlight_device(dev); + + if (WARN_ON(bd->props.scale > BACKLIGHT_SCALE_NON_LINEAR)) + return sprintf(buf, "unknown\n"); + + return sprintf(buf, "%s\n", backlight_scale_types[bd->props.scale]); +} +static DEVICE_ATTR_RO(scale); + static struct class *backlight_class; #ifdef CONFIG_PM_SLEEP @@ -292,6 +310,7 @@ static struct attribute *bl_device_attrs[] = { &dev_attr_brightness.attr, &dev_attr_actual_brightness.attr, &dev_attr_max_brightness.attr, + &dev_attr_scale.attr, &dev_attr_type.attr, NULL, }; diff --git a/include/linux/backlight.h b/include/linux/backlight.h index 0b5897446dca..c7d6b2e8c3b5 100644 --- a/include/linux/backlight.h +++ b/include/linux/backlight.h @@ -46,6 +46,12 @@ enum backlight_notification { BACKLIGHT_UNREGISTERED, }; +enum backlight_scale { + BACKLIGHT_SCALE_UNKNOWN = 0, + BACKLIGHT_SCALE_LINEAR, + BACKLIGHT_SCALE_NON_LINEAR, +}; + struct backlight_device; struct fb_info; @@ -80,6 +86,8 @@ struct backlight_properties { enum backlight_type type; /* Flags used to signal drivers of state changes */ unsigned int state; + /* Type of the brightness scale (linear, non-linear, ...) */ + enum backlight_scale scale; #define BL_CORE_SUSPENDED (1 << 0) /* backlight is suspended */ #define BL_CORE_FBBLANK (1 << 1) /* backlight is under an fb blank event */ -- 2.22.0.410.gd8fdbe21b5-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-08-07 20:15 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-07 20:15 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve currently is opaque > to userspace, so userspace often uses more or less reliable heuristics > (like the number of brightness levels) to decide whether to treat a > backlight device as linear or non-linear. > > Export the type of the brightness curve via the new sysfs attribute > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > 'unknown'. For devices that don't provide information about the scale > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Daniel (et al): do you have any more comments on this patch/series or is it ready to land? Thanks Matthias ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-07 20:15 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-07 20:15 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve currently is opaque > to userspace, so userspace often uses more or less reliable heuristics > (like the number of brightness levels) to decide whether to treat a > backlight device as linear or non-linear. > > Export the type of the brightness curve via the new sysfs attribute > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > 'unknown'. For devices that don't provide information about the scale > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Daniel (et al): do you have any more comments on this patch/series or is it ready to land? Thanks Matthias ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-07 20:15 ` Matthias Kaehlcke @ 2019-08-16 15:54 ` Daniel Thompson -1 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-16 15:54 UTC (permalink / raw) To: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On 07/08/2019 21:15, Matthias Kaehlcke wrote: > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: >> Backlight brightness curves can have different shapes. The two main >> types are linear and non-linear curves. The human eye doesn't >> perceive linearly increasing/decreasing brightness as linear (see >> also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED >> linearly to human eye"), hence many backlights use non-linear (often >> logarithmic) brightness curves. The type of curve currently is opaque >> to userspace, so userspace often uses more or less reliable heuristics >> (like the number of brightness levels) to decide whether to treat a >> backlight device as linear or non-linear. >> >> Export the type of the brightness curve via the new sysfs attribute >> 'scale'. The value of the attribute can be 'linear', 'non-linear' or >> 'unknown'. For devices that don't provide information about the scale >> of their brightness curve the value of the 'scale' attribute is 'unknown'. >> >> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > Daniel (et al): do you have any more comments on this patch/series or > is it ready to land? I decided to leave it for a long while for others to review since I'm still a tiny bit uneasy about the linear/non-linear terminology. However that's my only concern, its fairly minor and I've dragged by feet for more then long enough, so: Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-16 15:54 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-16 15:54 UTC (permalink / raw) To: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On 07/08/2019 21:15, Matthias Kaehlcke wrote: > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: >> Backlight brightness curves can have different shapes. The two main >> types are linear and non-linear curves. The human eye doesn't >> perceive linearly increasing/decreasing brightness as linear (see >> also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED >> linearly to human eye"), hence many backlights use non-linear (often >> logarithmic) brightness curves. The type of curve currently is opaque >> to userspace, so userspace often uses more or less reliable heuristics >> (like the number of brightness levels) to decide whether to treat a >> backlight device as linear or non-linear. >> >> Export the type of the brightness curve via the new sysfs attribute >> 'scale'. The value of the attribute can be 'linear', 'non-linear' or >> 'unknown'. For devices that don't provide information about the scale >> of their brightness curve the value of the 'scale' attribute is 'unknown'. >> >> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > Daniel (et al): do you have any more comments on this patch/series or > is it ready to land? I decided to leave it for a long while for others to review since I'm still a tiny bit uneasy about the linear/non-linear terminology. However that's my only concern, its fairly minor and I've dragged by feet for more then long enough, so: Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-16 15:54 ` Daniel Thompson @ 2019-08-16 17:53 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-16 17:53 UTC (permalink / raw) To: Daniel Thompson Cc: Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve currently is opaque > > > to userspace, so userspace often uses more or less reliable heuristics > > > (like the number of brightness levels) to decide whether to treat a > > > backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > 'unknown'. For devices that don't provide information about the scale > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > Daniel (et al): do you have any more comments on this patch/series or > > is it ready to land? > > I decided to leave it for a long while for others to review since I'm still > a tiny bit uneasy about the linear/non-linear terminology. > > However that's my only concern, its fairly minor and I've dragged by feet > for more then long enough, so: > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Thanks! If you or someone else has another suggestion for the terminology that we can all agree on I'm happy to change it. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-16 17:53 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-16 17:53 UTC (permalink / raw) To: Daniel Thompson Cc: Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve currently is opaque > > > to userspace, so userspace often uses more or less reliable heuristics > > > (like the number of brightness levels) to decide whether to treat a > > > backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > 'unknown'. For devices that don't provide information about the scale > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > Daniel (et al): do you have any more comments on this patch/series or > > is it ready to land? > > I decided to leave it for a long while for others to review since I'm still > a tiny bit uneasy about the linear/non-linear terminology. > > However that's my only concern, its fairly minor and I've dragged by feet > for more then long enough, so: > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Thanks! If you or someone else has another suggestion for the terminology that we can all agree on I'm happy to change it. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-16 17:53 ` Matthias Kaehlcke @ 2019-08-19 10:02 ` Daniel Thompson -1 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-19 10:02 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > (like the number of brightness levels) to decide whether to treat a > > > > backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > 'unknown'. For devices that don't provide information about the scale > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > Daniel (et al): do you have any more comments on this patch/series or > > > is it ready to land? > > > > I decided to leave it for a long while for others to review since I'm still > > a tiny bit uneasy about the linear/non-linear terminology. > > > > However that's my only concern, its fairly minor and I've dragged by feet > > for more then long enough, so: > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > Thanks! > > If you or someone else has another suggestion for the terminology that > we can all agree on I'm happy to change it. As you will see in my reply to Uwe. The term I tend to adopt when I want to be precise about userspace behaviour is "perceptual" (e.g. that a backlight can be mapped directly to a slider and it will feel right). However that raises its own concerns: mostly about what is perceptual enough. Clear the automatic brightness curve support in the PWM driver is perceptual. To be honest I suspect that in most cases a true logarithmic curve (given a sane exponent) would be perceptual enough. In other words it will feel comfortable with a direct mapped slider and using it for animation won't be too bad. However when we get right down to it *that* is the information that is actually most useful to userspace: explicit confirmation that the scale can be mapped directly to a slider. I think it also aligned better with Uwe's feedback (e.g. to start working towards having a preferred scale). Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 10:02 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-19 10:02 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > (like the number of brightness levels) to decide whether to treat a > > > > backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > 'unknown'. For devices that don't provide information about the scale > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > Daniel (et al): do you have any more comments on this patch/series or > > > is it ready to land? > > > > I decided to leave it for a long while for others to review since I'm still > > a tiny bit uneasy about the linear/non-linear terminology. > > > > However that's my only concern, its fairly minor and I've dragged by feet > > for more then long enough, so: > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > Thanks! > > If you or someone else has another suggestion for the terminology that > we can all agree on I'm happy to change it. As you will see in my reply to Uwe. The term I tend to adopt when I want to be precise about userspace behaviour is "perceptual" (e.g. that a backlight can be mapped directly to a slider and it will feel right). However that raises its own concerns: mostly about what is perceptual enough. Clear the automatic brightness curve support in the PWM driver is perceptual. To be honest I suspect that in most cases a true logarithmic curve (given a sane exponent) would be perceptual enough. In other words it will feel comfortable with a direct mapped slider and using it for animation won't be too bad. However when we get right down to it *that* is the information that is actually most useful to userspace: explicit confirmation that the scale can be mapped directly to a slider. I think it also aligned better with Uwe's feedback (e.g. to start working towards having a preferred scale). Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-19 10:02 ` Daniel Thompson (?) @ 2019-08-19 18:50 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-19 18:50 UTC (permalink / raw) To: Daniel Thompson Cc: Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski Hi Daniel, On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote: > On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > Backlight brightness curves can have different shapes. The two main > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > backlight device as linear or non-linear. > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > Daniel (et al): do you have any more comments on this patch/series or > > > > is it ready to land? > > > > > > I decided to leave it for a long while for others to review since I'm still > > > a tiny bit uneasy about the linear/non-linear terminology. > > > > > > However that's my only concern, its fairly minor and I've dragged by feet > > > for more then long enough, so: > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > > > Thanks! > > > > If you or someone else has another suggestion for the terminology that > > we can all agree on I'm happy to change it. > > As you will see in my reply to Uwe. The term I tend to adopt when I want > to be precise about userspace behaviour is "perceptual" (e.g. that a > backlight can be mapped directly to a slider and it will feel right). > > However that raises its own concerns: mostly about what is perceptual > enough. > > Clear the automatic brightness curve support in the PWM driver is > perceptual. > > To be honest I suspect that in most cases a true logarithmic curve (given a > sane exponent) would be perceptual enough. In other words it will feel > comfortable with a direct mapped slider and using it for animation > won't be too bad. > > However when we get right down to it *that* is the information that is > actually most useful to userspace: explicit confirmation that the scale > can be mapped directly to a slider. I think it also aligned better with > Uwe's feedback (e.g. to start working towards having a preferred scale). IIUC the conclusion is that there is no need for a string attribute because we only need to distinguish between 'perceptual' and 'non-perceptual'. If that is correct, do you have any preference for the attribute name ('perceptual_scale', 'perceptual', ...)? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 18:50 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-19 18:50 UTC (permalink / raw) To: Daniel Thompson Cc: linux-pwm, linux-fbdev, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones Hi Daniel, On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote: > On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > Backlight brightness curves can have different shapes. The two main > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > backlight device as linear or non-linear. > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > Daniel (et al): do you have any more comments on this patch/series or > > > > is it ready to land? > > > > > > I decided to leave it for a long while for others to review since I'm still > > > a tiny bit uneasy about the linear/non-linear terminology. > > > > > > However that's my only concern, its fairly minor and I've dragged by feet > > > for more then long enough, so: > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > > > Thanks! > > > > If you or someone else has another suggestion for the terminology that > > we can all agree on I'm happy to change it. > > As you will see in my reply to Uwe. The term I tend to adopt when I want > to be precise about userspace behaviour is "perceptual" (e.g. that a > backlight can be mapped directly to a slider and it will feel right). > > However that raises its own concerns: mostly about what is perceptual > enough. > > Clear the automatic brightness curve support in the PWM driver is > perceptual. > > To be honest I suspect that in most cases a true logarithmic curve (given a > sane exponent) would be perceptual enough. In other words it will feel > comfortable with a direct mapped slider and using it for animation > won't be too bad. > > However when we get right down to it *that* is the information that is > actually most useful to userspace: explicit confirmation that the scale > can be mapped directly to a slider. I think it also aligned better with > Uwe's feedback (e.g. to start working towards having a preferred scale). IIUC the conclusion is that there is no need for a string attribute because we only need to distinguish between 'perceptual' and 'non-perceptual'. If that is correct, do you have any preference for the attribute name ('perceptual_scale', 'perceptual', ...)? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 18:50 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-19 18:50 UTC (permalink / raw) To: Daniel Thompson Cc: linux-pwm, linux-fbdev, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones Hi Daniel, On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote: > On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > Backlight brightness curves can have different shapes. The two main > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > backlight device as linear or non-linear. > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > Daniel (et al): do you have any more comments on this patch/series or > > > > is it ready to land? > > > > > > I decided to leave it for a long while for others to review since I'm still > > > a tiny bit uneasy about the linear/non-linear terminology. > > > > > > However that's my only concern, its fairly minor and I've dragged by feet > > > for more then long enough, so: > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > > > Thanks! > > > > If you or someone else has another suggestion for the terminology that > > we can all agree on I'm happy to change it. > > As you will see in my reply to Uwe. The term I tend to adopt when I want > to be precise about userspace behaviour is "perceptual" (e.g. that a > backlight can be mapped directly to a slider and it will feel right). > > However that raises its own concerns: mostly about what is perceptual > enough. > > Clear the automatic brightness curve support in the PWM driver is > perceptual. > > To be honest I suspect that in most cases a true logarithmic curve (given a > sane exponent) would be perceptual enough. In other words it will feel > comfortable with a direct mapped slider and using it for animation > won't be too bad. > > However when we get right down to it *that* is the information that is > actually most useful to userspace: explicit confirmation that the scale > can be mapped directly to a slider. I think it also aligned better with > Uwe's feedback (e.g. to start working towards having a preferred scale). IIUC the conclusion is that there is no need for a string attribute because we only need to distinguish between 'perceptual' and 'non-perceptual'. If that is correct, do you have any preference for the attribute name ('perceptual_scale', 'perceptual', ...)? _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-19 18:50 ` Matthias Kaehlcke @ 2019-08-20 13:56 ` Daniel Thompson -1 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-20 13:56 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Mon, Aug 19, 2019 at 11:50:49AM -0700, Matthias Kaehlcke wrote: > Hi Daniel, > > On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote: > > On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > Daniel (et al): do you have any more comments on this patch/series or > > > > > is it ready to land? > > > > > > > > I decided to leave it for a long while for others to review since I'm still > > > > a tiny bit uneasy about the linear/non-linear terminology. > > > > > > > > However that's my only concern, its fairly minor and I've dragged by feet > > > > for more then long enough, so: > > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > > > > > Thanks! > > > > > > If you or someone else has another suggestion for the terminology that > > > we can all agree on I'm happy to change it. > > > > As you will see in my reply to Uwe. The term I tend to adopt when I want > > to be precise about userspace behaviour is "perceptual" (e.g. that a > > backlight can be mapped directly to a slider and it will feel right). > > > > However that raises its own concerns: mostly about what is perceptual > > enough. > > > > Clear the automatic brightness curve support in the PWM driver is > > perceptual. > > > > To be honest I suspect that in most cases a true logarithmic curve (given a > > sane exponent) would be perceptual enough. In other words it will feel > > comfortable with a direct mapped slider and using it for animation > > won't be too bad. > > > > However when we get right down to it *that* is the information that is > > actually most useful to userspace: explicit confirmation that the scale > > can be mapped directly to a slider. I think it also aligned better with > > Uwe's feedback (e.g. to start working towards having a preferred scale). > > IIUC the conclusion is that there is no need for a string attribute > because we only need to distinguish between 'perceptual' and > 'non-perceptual'. If that is correct, do you have any preference for > the attribute name ('perceptual_scale', 'perceptual', ...)? More a summary than a conclusion! There is a reason I have left a bit or space for others to comment on this over the last month (and a bit). To be clear my Reviewed-by: means that I believe that the kernel is better with "non-linear/linear/unknown" than without it and that I am comfortable the API isn't likely to be a millstone for us. Lee, Jingoo: Either of you care to offer $0.02 Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-20 13:56 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-20 13:56 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Mon, Aug 19, 2019 at 11:50:49AM -0700, Matthias Kaehlcke wrote: > Hi Daniel, > > On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote: > > On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote: > > > > On 07/08/2019 21:15, Matthias Kaehlcke wrote: > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > Daniel (et al): do you have any more comments on this patch/series or > > > > > is it ready to land? > > > > > > > > I decided to leave it for a long while for others to review since I'm still > > > > a tiny bit uneasy about the linear/non-linear terminology. > > > > > > > > However that's my only concern, its fairly minor and I've dragged by feet > > > > for more then long enough, so: > > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> > > > > > > Thanks! > > > > > > If you or someone else has another suggestion for the terminology that > > > we can all agree on I'm happy to change it. > > > > As you will see in my reply to Uwe. The term I tend to adopt when I want > > to be precise about userspace behaviour is "perceptual" (e.g. that a > > backlight can be mapped directly to a slider and it will feel right). > > > > However that raises its own concerns: mostly about what is perceptual > > enough. > > > > Clear the automatic brightness curve support in the PWM driver is > > perceptual. > > > > To be honest I suspect that in most cases a true logarithmic curve (given a > > sane exponent) would be perceptual enough. In other words it will feel > > comfortable with a direct mapped slider and using it for animation > > won't be too bad. > > > > However when we get right down to it *that* is the information that is > > actually most useful to userspace: explicit confirmation that the scale > > can be mapped directly to a slider. I think it also aligned better with > > Uwe's feedback (e.g. to start working towards having a preferred scale). > > IIUC the conclusion is that there is no need for a string attribute > because we only need to distinguish between 'perceptual' and > 'non-perceptual'. If that is correct, do you have any preference for > the attribute name ('perceptual_scale', 'perceptual', ...)? More a summary than a conclusion! There is a reason I have left a bit or space for others to comment on this over the last month (and a bit). To be clear my Reviewed-by: means that I believe that the kernel is better with "non-linear/linear/unknown" than without it and that I am comfortable the API isn't likely to be a millstone for us. Lee, Jingoo: Either of you care to offer $0.02 Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-20 13:56 ` Daniel Thompson @ 2019-08-27 9:44 ` Lee Jones -1 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-08-27 9:44 UTC (permalink / raw) To: Daniel Thompson Cc: Matthias Kaehlcke, Thierry Reding, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski [...] > > IIUC the conclusion is that there is no need for a string attribute > > because we only need to distinguish between 'perceptual' and > > 'non-perceptual'. If that is correct, do you have any preference for > > the attribute name ('perceptual_scale', 'perceptual', ...)? > > More a summary than a conclusion! There is a reason I have left a bit or > space for others to comment on this over the last month (and a bit). > > To be clear my Reviewed-by: means that I believe that the kernel is better > with "non-linear/linear/unknown" than without it and that I am comfortable > the API isn't likely to be a millstone for us. > > Lee, Jingoo: Either of you care to offer $0.02 No, not really. Happy to leave it to your good judgement. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-27 9:44 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-08-27 9:44 UTC (permalink / raw) To: Daniel Thompson Cc: Matthias Kaehlcke, Thierry Reding, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski [...] > > IIUC the conclusion is that there is no need for a string attribute > > because we only need to distinguish between 'perceptual' and > > 'non-perceptual'. If that is correct, do you have any preference for > > the attribute name ('perceptual_scale', 'perceptual', ...)? > > More a summary than a conclusion! There is a reason I have left a bit or > space for others to comment on this over the last month (and a bit). > > To be clear my Reviewed-by: means that I believe that the kernel is better > with "non-linear/linear/unknown" than without it and that I am comfortable > the API isn't likely to be a millstone for us. > > Lee, Jingoo: Either of you care to offer $0.02 No, not really. Happy to leave it to your good judgement. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-27 9:44 ` Lee Jones @ 2019-08-29 14:09 ` Daniel Thompson -1 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-29 14:09 UTC (permalink / raw) To: Lee Jones Cc: Matthias Kaehlcke, Thierry Reding, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Aug 27, 2019 at 10:44:59AM +0100, Lee Jones wrote: > [...] > > > > IIUC the conclusion is that there is no need for a string attribute > > > because we only need to distinguish between 'perceptual' and > > > 'non-perceptual'. If that is correct, do you have any preference for > > > the attribute name ('perceptual_scale', 'perceptual', ...)? > > > > More a summary than a conclusion! There is a reason I have left a bit or > > space for others to comment on this over the last month (and a bit). > > > > To be clear my Reviewed-by: means that I believe that the kernel is better > > with "non-linear/linear/unknown" than without it and that I am comfortable > > the API isn't likely to be a millstone for us. > > > > Lee, Jingoo: Either of you care to offer $0.02 > > No, not really. Happy to leave it to your good judgement. In that case... the patch has my reviewed-by and although the concerns raised in the associated threads have merit I don't think they are enough to stop the patch. Please merge. Daniel. > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-29 14:09 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-29 14:09 UTC (permalink / raw) To: Lee Jones Cc: Matthias Kaehlcke, Thierry Reding, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Aug 27, 2019 at 10:44:59AM +0100, Lee Jones wrote: > [...] > > > > IIUC the conclusion is that there is no need for a string attribute > > > because we only need to distinguish between 'perceptual' and > > > 'non-perceptual'. If that is correct, do you have any preference for > > > the attribute name ('perceptual_scale', 'perceptual', ...)? > > > > More a summary than a conclusion! There is a reason I have left a bit or > > space for others to comment on this over the last month (and a bit). > > > > To be clear my Reviewed-by: means that I believe that the kernel is better > > with "non-linear/linear/unknown" than without it and that I am comfortable > > the API isn't likely to be a millstone for us. > > > > Lee, Jingoo: Either of you care to offer $0.02 > > No, not really. Happy to leave it to your good judgement. In that case... the patch has my reviewed-by and although the concerns raised in the associated threads have merit I don't think they are enough to stop the patch. Please merge. Daniel. > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-08-16 16:51 ` Uwe Kleine-König -1 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-16 16:51 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve currently is opaque > to userspace, so userspace often uses more or less reliable heuristics > (like the number of brightness levels) to decide whether to treat a > backlight device as linear or non-linear. > > Export the type of the brightness curve via the new sysfs attribute > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > 'unknown'. For devices that don't provide information about the scale > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> I wonder what kind of problem you are solving here. Can you describe that in a few words? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-16 16:51 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-16 16:51 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve currently is opaque > to userspace, so userspace often uses more or less reliable heuristics > (like the number of brightness levels) to decide whether to treat a > backlight device as linear or non-linear. > > Export the type of the brightness curve via the new sysfs attribute > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > 'unknown'. For devices that don't provide information about the scale > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> I wonder what kind of problem you are solving here. Can you describe that in a few words? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-16 16:51 ` Uwe Kleine-König @ 2019-08-16 17:51 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-16 17:51 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski Hi Uwe, On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > Backlight brightness curves can have different shapes. The two main > > types are linear and non-linear curves. The human eye doesn't > > perceive linearly increasing/decreasing brightness as linear (see > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > linearly to human eye"), hence many backlights use non-linear (often > > logarithmic) brightness curves. The type of curve currently is opaque > > to userspace, so userspace often uses more or less reliable heuristics > > (like the number of brightness levels) to decide whether to treat a > > backlight device as linear or non-linear. > > > > Export the type of the brightness curve via the new sysfs attribute > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > 'unknown'. For devices that don't provide information about the scale > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > I wonder what kind of problem you are solving here. Can you describe > that in a few words? The human eye perceives brightness in a logarithmic manner. For backlights with a linear brightness curve brightness controls like sliders need to use a mapping to achieve a behavior that is perceived as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) As of now userspace doesn't have information about the type of the brightness curve, and often uses heuristics to make a guess, which may be right most of the time, but not always. The new attribute eliminates the need to guess. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-16 17:51 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-16 17:51 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski Hi Uwe, On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > Backlight brightness curves can have different shapes. The two main > > types are linear and non-linear curves. The human eye doesn't > > perceive linearly increasing/decreasing brightness as linear (see > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > linearly to human eye"), hence many backlights use non-linear (often > > logarithmic) brightness curves. The type of curve currently is opaque > > to userspace, so userspace often uses more or less reliable heuristics > > (like the number of brightness levels) to decide whether to treat a > > backlight device as linear or non-linear. > > > > Export the type of the brightness curve via the new sysfs attribute > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > 'unknown'. For devices that don't provide information about the scale > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > I wonder what kind of problem you are solving here. Can you describe > that in a few words? The human eye perceives brightness in a logarithmic manner. For backlights with a linear brightness curve brightness controls like sliders need to use a mapping to achieve a behavior that is perceived as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) As of now userspace doesn't have information about the type of the brightness curve, and often uses heuristics to make a guess, which may be right most of the time, but not always. The new attribute eliminates the need to guess. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-16 17:51 ` Matthias Kaehlcke (?) @ 2019-08-16 19:47 ` Uwe Kleine-König -1 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-16 19:47 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > Hi Uwe, > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve currently is opaque > > > to userspace, so userspace often uses more or less reliable heuristics > > > (like the number of brightness levels) to decide whether to treat a > > > backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > 'unknown'. For devices that don't provide information about the scale > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > I wonder what kind of problem you are solving here. Can you describe > > that in a few words? > > The human eye perceives brightness in a logarithmic manner. For > backlights with a linear brightness curve brightness controls like > sliders need to use a mapping to achieve a behavior that is perceived > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > As of now userspace doesn't have information about the type of the > brightness curve, and often uses heuristics to make a guess, which may > be right most of the time, but not always. The new attribute eliminates > the need to guess. This is about backlights right? So the kernel provides to userspace an interval [0, x] for some x and depending on the physics of the the backlight configuring x/2 (probably?) either means 50% measured light or 50% perceived light, right? I wonder if it would be possible instead of giving different backlight implementations the freedom to use either linear or logarithmic (or quadratic?) scaling and tell userspace which of the options were picked require the drivers to provide a (say) linear scaling and then userspace wouldn't need to care about the exact physics. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-16 19:47 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-16 19:47 UTC (permalink / raw) To: Matthias Kaehlcke Cc: linux-pwm, Daniel Thompson, Douglas Anderson, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > Hi Uwe, > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve currently is opaque > > > to userspace, so userspace often uses more or less reliable heuristics > > > (like the number of brightness levels) to decide whether to treat a > > > backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > 'unknown'. For devices that don't provide information about the scale > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > I wonder what kind of problem you are solving here. Can you describe > > that in a few words? > > The human eye perceives brightness in a logarithmic manner. For > backlights with a linear brightness curve brightness controls like > sliders need to use a mapping to achieve a behavior that is perceived > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > As of now userspace doesn't have information about the type of the > brightness curve, and often uses heuristics to make a guess, which may > be right most of the time, but not always. The new attribute eliminates > the need to guess. This is about backlights right? So the kernel provides to userspace an interval [0, x] for some x and depending on the physics of the the backlight configuring x/2 (probably?) either means 50% measured light or 50% perceived light, right? I wonder if it would be possible instead of giving different backlight implementations the freedom to use either linear or logarithmic (or quadratic?) scaling and tell userspace which of the options were picked require the drivers to provide a (say) linear scaling and then userspace wouldn't need to care about the exact physics. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-16 19:47 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-16 19:47 UTC (permalink / raw) To: Matthias Kaehlcke Cc: linux-pwm, Daniel Thompson, Douglas Anderson, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > Hi Uwe, > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve currently is opaque > > > to userspace, so userspace often uses more or less reliable heuristics > > > (like the number of brightness levels) to decide whether to treat a > > > backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > 'unknown'. For devices that don't provide information about the scale > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > I wonder what kind of problem you are solving here. Can you describe > > that in a few words? > > The human eye perceives brightness in a logarithmic manner. For > backlights with a linear brightness curve brightness controls like > sliders need to use a mapping to achieve a behavior that is perceived > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > As of now userspace doesn't have information about the type of the > brightness curve, and often uses heuristics to make a guess, which may > be right most of the time, but not always. The new attribute eliminates > the need to guess. This is about backlights right? So the kernel provides to userspace an interval [0, x] for some x and depending on the physics of the the backlight configuring x/2 (probably?) either means 50% measured light or 50% perceived light, right? I wonder if it would be possible instead of giving different backlight implementations the freedom to use either linear or logarithmic (or quadratic?) scaling and tell userspace which of the options were picked require the drivers to provide a (say) linear scaling and then userspace wouldn't need to care about the exact physics. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-16 19:47 ` Uwe Kleine-König @ 2019-08-16 21:10 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-16 21:10 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > Hi Uwe, > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > (like the number of brightness levels) to decide whether to treat a > > > > backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > 'unknown'. For devices that don't provide information about the scale > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > that in a few words? > > > > The human eye perceives brightness in a logarithmic manner. For > > backlights with a linear brightness curve brightness controls like > > sliders need to use a mapping to achieve a behavior that is perceived > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > As of now userspace doesn't have information about the type of the > > brightness curve, and often uses heuristics to make a guess, which may > > be right most of the time, but not always. The new attribute eliminates > > the need to guess. > > This is about backlights right? So the kernel provides to userspace an > interval [0, x] for some x and depending on the physics of the the > backlight configuring x/2 (probably?) either means 50% measured light or > 50% perceived light, right? correct > I wonder if it would be possible instead of giving different backlight > implementations the freedom to use either linear or logarithmic (or > quadratic?) scaling and tell userspace which of the options were picked > require the drivers to provide a (say) linear scaling and then userspace > wouldn't need to care about the exact physics. In an ideal world the backlight interface would be consistent as you suggest, however there are plenty of existing devices which use the 'other' scaling (regardless of which is chosen as the 'correct' one). Userspace still has to deal with these. And changing previously 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, when it keeps using its 'old' scaling, which now isn't correct anymore. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-16 21:10 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-08-16 21:10 UTC (permalink / raw) To: Uwe Kleine-König Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > Hi Uwe, > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > (like the number of brightness levels) to decide whether to treat a > > > > backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > 'unknown'. For devices that don't provide information about the scale > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > that in a few words? > > > > The human eye perceives brightness in a logarithmic manner. For > > backlights with a linear brightness curve brightness controls like > > sliders need to use a mapping to achieve a behavior that is perceived > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > As of now userspace doesn't have information about the type of the > > brightness curve, and often uses heuristics to make a guess, which may > > be right most of the time, but not always. The new attribute eliminates > > the need to guess. > > This is about backlights right? So the kernel provides to userspace an > interval [0, x] for some x and depending on the physics of the the > backlight configuring x/2 (probably?) either means 50% measured light or > 50% perceived light, right? correct > I wonder if it would be possible instead of giving different backlight > implementations the freedom to use either linear or logarithmic (or > quadratic?) scaling and tell userspace which of the options were picked > require the drivers to provide a (say) linear scaling and then userspace > wouldn't need to care about the exact physics. In an ideal world the backlight interface would be consistent as you suggest, however there are plenty of existing devices which use the 'other' scaling (regardless of which is chosen as the 'correct' one). Userspace still has to deal with these. And changing previously 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, when it keeps using its 'old' scaling, which now isn't correct anymore. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-16 21:10 ` Matthias Kaehlcke (?) @ 2019-08-19 5:46 ` Uwe Kleine-König -1 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 5:46 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, kernel Hello Matthias, On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > Hi Uwe, > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > Backlight brightness curves can have different shapes. The two main > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > backlight device as linear or non-linear. > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > that in a few words? > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > backlights with a linear brightness curve brightness controls like > > > sliders need to use a mapping to achieve a behavior that is perceived > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > As of now userspace doesn't have information about the type of the > > > brightness curve, and often uses heuristics to make a guess, which may > > > be right most of the time, but not always. The new attribute eliminates > > > the need to guess. > > > > This is about backlights right? So the kernel provides to userspace an > > interval [0, x] for some x and depending on the physics of the the > > backlight configuring x/2 (probably?) either means 50% measured light or > > 50% perceived light, right? > > correct > > > I wonder if it would be possible instead of giving different backlight > > implementations the freedom to use either linear or logarithmic (or > > quadratic?) scaling and tell userspace which of the options were picked > > require the drivers to provide a (say) linear scaling and then userspace > > wouldn't need to care about the exact physics. > > In an ideal world the backlight interface would be consistent as you > suggest, however there are plenty of existing devices which use the > 'other' scaling (regardless of which is chosen as the 'correct' > one). Userspace still has to deal with these. And changing previously > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > when it keeps using its 'old' scaling, which now isn't correct anymore. It might be subjective, or maybe I'm just too optimistic, but I think if there was no policy before about the meaning of echo 17 > brightness other than "brighter than lower values and darker than higher ones" introducing (say) the scale is intended to represent a linear brightness curve is ok. Unless userspace jumps through hoops and tries to identify the actual device it is running on it is wrong on some machines anyhow and we're only shifting the set of affected machines with a tighter policy (until that userspace application is fixed). And the big upside is that in the end (i.e. when all kernel drivers and userspace applications are adapted to provide/consume the "correct" curve) the result is simpler. Just my 0.02€ Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 5:46 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 5:46 UTC (permalink / raw) To: Matthias Kaehlcke Cc: linux-pwm, Daniel Thompson, Douglas Anderson, kernel, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones Hello Matthias, On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > Hi Uwe, > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > Backlight brightness curves can have different shapes. The two main > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > backlight device as linear or non-linear. > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > that in a few words? > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > backlights with a linear brightness curve brightness controls like > > > sliders need to use a mapping to achieve a behavior that is perceived > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > As of now userspace doesn't have information about the type of the > > > brightness curve, and often uses heuristics to make a guess, which may > > > be right most of the time, but not always. The new attribute eliminates > > > the need to guess. > > > > This is about backlights right? So the kernel provides to userspace an > > interval [0, x] for some x and depending on the physics of the the > > backlight configuring x/2 (probably?) either means 50% measured light or > > 50% perceived light, right? > > correct > > > I wonder if it would be possible instead of giving different backlight > > implementations the freedom to use either linear or logarithmic (or > > quadratic?) scaling and tell userspace which of the options were picked > > require the drivers to provide a (say) linear scaling and then userspace > > wouldn't need to care about the exact physics. > > In an ideal world the backlight interface would be consistent as you > suggest, however there are plenty of existing devices which use the > 'other' scaling (regardless of which is chosen as the 'correct' > one). Userspace still has to deal with these. And changing previously > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > when it keeps using its 'old' scaling, which now isn't correct anymore. It might be subjective, or maybe I'm just too optimistic, but I think if there was no policy before about the meaning of echo 17 > brightness other than "brighter than lower values and darker than higher ones" introducing (say) the scale is intended to represent a linear brightness curve is ok. Unless userspace jumps through hoops and tries to identify the actual device it is running on it is wrong on some machines anyhow and we're only shifting the set of affected machines with a tighter policy (until that userspace application is fixed). And the big upside is that in the end (i.e. when all kernel drivers and userspace applications are adapted to provide/consume the "correct" curve) the result is simpler. Just my 0.02€ Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 5:46 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 5:46 UTC (permalink / raw) To: Matthias Kaehlcke Cc: linux-pwm, Daniel Thompson, Douglas Anderson, kernel, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones Hello Matthias, On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > Hi Uwe, > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > Backlight brightness curves can have different shapes. The two main > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > backlight device as linear or non-linear. > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > that in a few words? > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > backlights with a linear brightness curve brightness controls like > > > sliders need to use a mapping to achieve a behavior that is perceived > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > As of now userspace doesn't have information about the type of the > > > brightness curve, and often uses heuristics to make a guess, which may > > > be right most of the time, but not always. The new attribute eliminates > > > the need to guess. > > > > This is about backlights right? So the kernel provides to userspace an > > interval [0, x] for some x and depending on the physics of the the > > backlight configuring x/2 (probably?) either means 50% measured light or > > 50% perceived light, right? > > correct > > > I wonder if it would be possible instead of giving different backlight > > implementations the freedom to use either linear or logarithmic (or > > quadratic?) scaling and tell userspace which of the options were picked > > require the drivers to provide a (say) linear scaling and then userspace > > wouldn't need to care about the exact physics. > > In an ideal world the backlight interface would be consistent as you > suggest, however there are plenty of existing devices which use the > 'other' scaling (regardless of which is chosen as the 'correct' > one). Userspace still has to deal with these. And changing previously > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > when it keeps using its 'old' scaling, which now isn't correct anymore. It might be subjective, or maybe I'm just too optimistic, but I think if there was no policy before about the meaning of echo 17 > brightness other than "brighter than lower values and darker than higher ones" introducing (say) the scale is intended to represent a linear brightness curve is ok. Unless userspace jumps through hoops and tries to identify the actual device it is running on it is wrong on some machines anyhow and we're only shifting the set of affected machines with a tighter policy (until that userspace application is fixed). And the big upside is that in the end (i.e. when all kernel drivers and userspace applications are adapted to provide/consume the "correct" curve) the result is simpler. Just my 0.02€ Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-19 5:46 ` Uwe Kleine-König (?) @ 2019-08-19 9:50 ` Daniel Thompson -1 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-19 9:50 UTC (permalink / raw) To: Uwe Kleine-König Cc: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, kernel On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > Hello Matthias, > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > Hi Uwe, > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > that in a few words? > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > backlights with a linear brightness curve brightness controls like > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > As of now userspace doesn't have information about the type of the > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > be right most of the time, but not always. The new attribute eliminates > > > > the need to guess. > > > > > > This is about backlights right? So the kernel provides to userspace an > > > interval [0, x] for some x and depending on the physics of the the > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > 50% perceived light, right? > > > > correct > > > > > I wonder if it would be possible instead of giving different backlight > > > implementations the freedom to use either linear or logarithmic (or > > > quadratic?) scaling and tell userspace which of the options were picked > > > require the drivers to provide a (say) linear scaling and then userspace > > > wouldn't need to care about the exact physics. > > > > In an ideal world the backlight interface would be consistent as you > > suggest, however there are plenty of existing devices which use the > > 'other' scaling (regardless of which is chosen as the 'correct' > > one). Userspace still has to deal with these. And changing previously > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > It might be subjective, or maybe I'm just too optimistic, but I think if > there was no policy before about the meaning of > > echo 17 > brightness > > other than "brighter than lower values and darker than higher ones" > introducing (say) the scale is intended to represent a linear brightness > curve is ok. > > Unless userspace jumps through hoops and tries to identify the actual > device it is running on it is wrong on some machines anyhow and we're > only shifting the set of affected machines with a tighter policy (until > that userspace application is fixed). I believe that there are two common approaches by userspace at present: 1. Assume the scale is perceptual and we can directly map a slider to the backlight value. This is common simply because most ACPI backlights are perceptual and therefore when tested in a laptop it works OK. 2. Assume that is max brightness is small (e.g. ACPI) then the scale is perceptual and if the max brightness is large (e.g. a PWM) then the scale is linear and apply a correction function between the slider and the control. That historic baggage makes is diffcult to "just define a standardized scale"... especially given that if we selected a standardized scale we would probably want a perceptual scale with lots of steps (e.g. break the heuristic). > And the big upside is that in the end (i.e. when all kernel drivers and > userspace applications are adapted to provide/consume the "correct" > curve) the result is simpler. My view is that this convergence will eventually be achieved but it will happen through the obsolescence of the backlight sysfs interface. The sysfs interface has other flaws, in particular no integration with the DRM connector API. Thus I would expect an alternative interface to emerge, most likely as part of the DRM connector API. I'd expect such a new API to a perceptual scale and to have a fixed max brightness with enough steps to support animated backlight effects (IIRC 0..100 has been proposed in the past) In the mean time getting the existing collection of backlight drivers marked up as linear/logarithmic/etc will ease the introduction of that API because, within the kernel, we might have gathered enough knowledge to have some hope of correctly mapping each backlight onto a standardized scale. Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 9:50 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-19 9:50 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-pwm, linux-fbdev, kernel, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > Hello Matthias, > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > Hi Uwe, > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > that in a few words? > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > backlights with a linear brightness curve brightness controls like > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > As of now userspace doesn't have information about the type of the > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > be right most of the time, but not always. The new attribute eliminates > > > > the need to guess. > > > > > > This is about backlights right? So the kernel provides to userspace an > > > interval [0, x] for some x and depending on the physics of the the > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > 50% perceived light, right? > > > > correct > > > > > I wonder if it would be possible instead of giving different backlight > > > implementations the freedom to use either linear or logarithmic (or > > > quadratic?) scaling and tell userspace which of the options were picked > > > require the drivers to provide a (say) linear scaling and then userspace > > > wouldn't need to care about the exact physics. > > > > In an ideal world the backlight interface would be consistent as you > > suggest, however there are plenty of existing devices which use the > > 'other' scaling (regardless of which is chosen as the 'correct' > > one). Userspace still has to deal with these. And changing previously > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > It might be subjective, or maybe I'm just too optimistic, but I think if > there was no policy before about the meaning of > > echo 17 > brightness > > other than "brighter than lower values and darker than higher ones" > introducing (say) the scale is intended to represent a linear brightness > curve is ok. > > Unless userspace jumps through hoops and tries to identify the actual > device it is running on it is wrong on some machines anyhow and we're > only shifting the set of affected machines with a tighter policy (until > that userspace application is fixed). I believe that there are two common approaches by userspace at present: 1. Assume the scale is perceptual and we can directly map a slider to the backlight value. This is common simply because most ACPI backlights are perceptual and therefore when tested in a laptop it works OK. 2. Assume that is max brightness is small (e.g. ACPI) then the scale is perceptual and if the max brightness is large (e.g. a PWM) then the scale is linear and apply a correction function between the slider and the control. That historic baggage makes is diffcult to "just define a standardized scale"... especially given that if we selected a standardized scale we would probably want a perceptual scale with lots of steps (e.g. break the heuristic). > And the big upside is that in the end (i.e. when all kernel drivers and > userspace applications are adapted to provide/consume the "correct" > curve) the result is simpler. My view is that this convergence will eventually be achieved but it will happen through the obsolescence of the backlight sysfs interface. The sysfs interface has other flaws, in particular no integration with the DRM connector API. Thus I would expect an alternative interface to emerge, most likely as part of the DRM connector API. I'd expect such a new API to a perceptual scale and to have a fixed max brightness with enough steps to support animated backlight effects (IIRC 0..100 has been proposed in the past) In the mean time getting the existing collection of backlight drivers marked up as linear/logarithmic/etc will ease the introduction of that API because, within the kernel, we might have gathered enough knowledge to have some hope of correctly mapping each backlight onto a standardized scale. Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 9:50 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-19 9:50 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-pwm, linux-fbdev, kernel, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > Hello Matthias, > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > Hi Uwe, > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > that in a few words? > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > backlights with a linear brightness curve brightness controls like > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > As of now userspace doesn't have information about the type of the > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > be right most of the time, but not always. The new attribute eliminates > > > > the need to guess. > > > > > > This is about backlights right? So the kernel provides to userspace an > > > interval [0, x] for some x and depending on the physics of the the > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > 50% perceived light, right? > > > > correct > > > > > I wonder if it would be possible instead of giving different backlight > > > implementations the freedom to use either linear or logarithmic (or > > > quadratic?) scaling and tell userspace which of the options were picked > > > require the drivers to provide a (say) linear scaling and then userspace > > > wouldn't need to care about the exact physics. > > > > In an ideal world the backlight interface would be consistent as you > > suggest, however there are plenty of existing devices which use the > > 'other' scaling (regardless of which is chosen as the 'correct' > > one). Userspace still has to deal with these. And changing previously > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > It might be subjective, or maybe I'm just too optimistic, but I think if > there was no policy before about the meaning of > > echo 17 > brightness > > other than "brighter than lower values and darker than higher ones" > introducing (say) the scale is intended to represent a linear brightness > curve is ok. > > Unless userspace jumps through hoops and tries to identify the actual > device it is running on it is wrong on some machines anyhow and we're > only shifting the set of affected machines with a tighter policy (until > that userspace application is fixed). I believe that there are two common approaches by userspace at present: 1. Assume the scale is perceptual and we can directly map a slider to the backlight value. This is common simply because most ACPI backlights are perceptual and therefore when tested in a laptop it works OK. 2. Assume that is max brightness is small (e.g. ACPI) then the scale is perceptual and if the max brightness is large (e.g. a PWM) then the scale is linear and apply a correction function between the slider and the control. That historic baggage makes is diffcult to "just define a standardized scale"... especially given that if we selected a standardized scale we would probably want a perceptual scale with lots of steps (e.g. break the heuristic). > And the big upside is that in the end (i.e. when all kernel drivers and > userspace applications are adapted to provide/consume the "correct" > curve) the result is simpler. My view is that this convergence will eventually be achieved but it will happen through the obsolescence of the backlight sysfs interface. The sysfs interface has other flaws, in particular no integration with the DRM connector API. Thus I would expect an alternative interface to emerge, most likely as part of the DRM connector API. I'd expect such a new API to a perceptual scale and to have a fixed max brightness with enough steps to support animated backlight effects (IIRC 0..100 has been proposed in the past) In the mean time getting the existing collection of backlight drivers marked up as linear/logarithmic/etc will ease the introduction of that API because, within the kernel, we might have gathered enough knowledge to have some hope of correctly mapping each backlight onto a standardized scale. Daniel. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-19 9:50 ` Daniel Thompson (?) @ 2019-08-19 10:21 ` Uwe Kleine-König -1 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 10:21 UTC (permalink / raw) To: Daniel Thompson Cc: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, kernel Hello Daniel, On Mon, Aug 19, 2019 at 10:50:37AM +0100, Daniel Thompson wrote: > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > Hello Matthias, > > > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > > Hi Uwe, > > > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > > that in a few words? > > > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > > backlights with a linear brightness curve brightness controls like > > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > > > As of now userspace doesn't have information about the type of the > > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > > be right most of the time, but not always. The new attribute eliminates > > > > > the need to guess. > > > > > > > > This is about backlights right? So the kernel provides to userspace an > > > > interval [0, x] for some x and depending on the physics of the the > > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > > 50% perceived light, right? > > > > > > correct > > > > > > > I wonder if it would be possible instead of giving different backlight > > > > implementations the freedom to use either linear or logarithmic (or > > > > quadratic?) scaling and tell userspace which of the options were picked > > > > require the drivers to provide a (say) linear scaling and then userspace > > > > wouldn't need to care about the exact physics. > > > > > > In an ideal world the backlight interface would be consistent as you > > > suggest, however there are plenty of existing devices which use the > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > one). Userspace still has to deal with these. And changing previously > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > there was no policy before about the meaning of > > > > echo 17 > brightness > > > > other than "brighter than lower values and darker than higher ones" > > introducing (say) the scale is intended to represent a linear brightness > > curve is ok. > > > > Unless userspace jumps through hoops and tries to identify the actual > > device it is running on it is wrong on some machines anyhow and we're > > only shifting the set of affected machines with a tighter policy (until > > that userspace application is fixed). > > I believe that there are two common approaches by userspace at present: > > 1. Assume the scale is perceptual and we can directly map a slider > to the backlight value. This is common simply because most ACPI > backlights are perceptual and therefore when tested in a laptop > it works OK. > > 2. Assume that is max brightness is small (e.g. ACPI) then the > scale is perceptual and if the max brightness is large (e.g. > a PWM) then the scale is linear and apply a correction > function between the slider and the control. > > That historic baggage makes is diffcult to "just define a standardized > scale"... especially given that if we selected a standardized scale we > would probably want a perceptual scale with lots of steps (e.g. break > the heuristic). With "perceptual" you mean that logarithmic stuff, right? I would tend to go for linear because this is easily measureable and also is straight forward to implement in the usual cases (attention: I assume that "usual" means something like PWM and I don't know much about the physics of backlights but just assume that a PWM will create a linear mapping). > > And the big upside is that in the end (i.e. when all kernel drivers and > > userspace applications are adapted to provide/consume the "correct" > > curve) the result is simpler. > > My view is that this convergence will eventually be achieved but it will > happen through the obsolescence of the backlight sysfs interface. The > sysfs interface has other flaws, in particular no integration with the > DRM connector API. > > Thus I would expect an alternative interface to emerge, most likely as > part of the DRM connector API. I'd expect such a new API to a > perceptual scale and to have a fixed max brightness with enough > steps to support animated backlight effects (IIRC 0..100 has been > proposed in the past) Then work on the new stuff instead of making the old stuff (that is intended to die) harder to use correctly? > In the mean time getting the existing collection of backlight drivers > marked up as linear/logarithmic/etc will ease the introduction of that > API because, within the kernel, we might have gathered enough knowledge > to have some hope of correctly mapping each backlight onto a > standardized scale. It would be enough to do this in a code comment then. That would come without the need to adapt the old userspace API. Also when the old solution works at 95% instead of 90% before, it will resist harder to dying. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 10:21 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 10:21 UTC (permalink / raw) To: Daniel Thompson Cc: linux-pwm, linux-fbdev, kernel, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones Hello Daniel, On Mon, Aug 19, 2019 at 10:50:37AM +0100, Daniel Thompson wrote: > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > Hello Matthias, > > > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > > Hi Uwe, > > > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > > that in a few words? > > > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > > backlights with a linear brightness curve brightness controls like > > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > > > As of now userspace doesn't have information about the type of the > > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > > be right most of the time, but not always. The new attribute eliminates > > > > > the need to guess. > > > > > > > > This is about backlights right? So the kernel provides to userspace an > > > > interval [0, x] for some x and depending on the physics of the the > > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > > 50% perceived light, right? > > > > > > correct > > > > > > > I wonder if it would be possible instead of giving different backlight > > > > implementations the freedom to use either linear or logarithmic (or > > > > quadratic?) scaling and tell userspace which of the options were picked > > > > require the drivers to provide a (say) linear scaling and then userspace > > > > wouldn't need to care about the exact physics. > > > > > > In an ideal world the backlight interface would be consistent as you > > > suggest, however there are plenty of existing devices which use the > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > one). Userspace still has to deal with these. And changing previously > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > there was no policy before about the meaning of > > > > echo 17 > brightness > > > > other than "brighter than lower values and darker than higher ones" > > introducing (say) the scale is intended to represent a linear brightness > > curve is ok. > > > > Unless userspace jumps through hoops and tries to identify the actual > > device it is running on it is wrong on some machines anyhow and we're > > only shifting the set of affected machines with a tighter policy (until > > that userspace application is fixed). > > I believe that there are two common approaches by userspace at present: > > 1. Assume the scale is perceptual and we can directly map a slider > to the backlight value. This is common simply because most ACPI > backlights are perceptual and therefore when tested in a laptop > it works OK. > > 2. Assume that is max brightness is small (e.g. ACPI) then the > scale is perceptual and if the max brightness is large (e.g. > a PWM) then the scale is linear and apply a correction > function between the slider and the control. > > That historic baggage makes is diffcult to "just define a standardized > scale"... especially given that if we selected a standardized scale we > would probably want a perceptual scale with lots of steps (e.g. break > the heuristic). With "perceptual" you mean that logarithmic stuff, right? I would tend to go for linear because this is easily measureable and also is straight forward to implement in the usual cases (attention: I assume that "usual" means something like PWM and I don't know much about the physics of backlights but just assume that a PWM will create a linear mapping). > > And the big upside is that in the end (i.e. when all kernel drivers and > > userspace applications are adapted to provide/consume the "correct" > > curve) the result is simpler. > > My view is that this convergence will eventually be achieved but it will > happen through the obsolescence of the backlight sysfs interface. The > sysfs interface has other flaws, in particular no integration with the > DRM connector API. > > Thus I would expect an alternative interface to emerge, most likely as > part of the DRM connector API. I'd expect such a new API to a > perceptual scale and to have a fixed max brightness with enough > steps to support animated backlight effects (IIRC 0..100 has been > proposed in the past) Then work on the new stuff instead of making the old stuff (that is intended to die) harder to use correctly? > In the mean time getting the existing collection of backlight drivers > marked up as linear/logarithmic/etc will ease the introduction of that > API because, within the kernel, we might have gathered enough knowledge > to have some hope of correctly mapping each backlight onto a > standardized scale. It would be enough to do this in a code comment then. That would come without the need to adapt the old userspace API. Also when the old solution works at 95% instead of 90% before, it will resist harder to dying. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 10:21 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 10:21 UTC (permalink / raw) To: Daniel Thompson Cc: linux-pwm, linux-fbdev, kernel, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-kernel, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones Hello Daniel, On Mon, Aug 19, 2019 at 10:50:37AM +0100, Daniel Thompson wrote: > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > Hello Matthias, > > > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > > Hi Uwe, > > > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > > that in a few words? > > > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > > backlights with a linear brightness curve brightness controls like > > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > > > As of now userspace doesn't have information about the type of the > > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > > be right most of the time, but not always. The new attribute eliminates > > > > > the need to guess. > > > > > > > > This is about backlights right? So the kernel provides to userspace an > > > > interval [0, x] for some x and depending on the physics of the the > > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > > 50% perceived light, right? > > > > > > correct > > > > > > > I wonder if it would be possible instead of giving different backlight > > > > implementations the freedom to use either linear or logarithmic (or > > > > quadratic?) scaling and tell userspace which of the options were picked > > > > require the drivers to provide a (say) linear scaling and then userspace > > > > wouldn't need to care about the exact physics. > > > > > > In an ideal world the backlight interface would be consistent as you > > > suggest, however there are plenty of existing devices which use the > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > one). Userspace still has to deal with these. And changing previously > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > there was no policy before about the meaning of > > > > echo 17 > brightness > > > > other than "brighter than lower values and darker than higher ones" > > introducing (say) the scale is intended to represent a linear brightness > > curve is ok. > > > > Unless userspace jumps through hoops and tries to identify the actual > > device it is running on it is wrong on some machines anyhow and we're > > only shifting the set of affected machines with a tighter policy (until > > that userspace application is fixed). > > I believe that there are two common approaches by userspace at present: > > 1. Assume the scale is perceptual and we can directly map a slider > to the backlight value. This is common simply because most ACPI > backlights are perceptual and therefore when tested in a laptop > it works OK. > > 2. Assume that is max brightness is small (e.g. ACPI) then the > scale is perceptual and if the max brightness is large (e.g. > a PWM) then the scale is linear and apply a correction > function between the slider and the control. > > That historic baggage makes is diffcult to "just define a standardized > scale"... especially given that if we selected a standardized scale we > would probably want a perceptual scale with lots of steps (e.g. break > the heuristic). With "perceptual" you mean that logarithmic stuff, right? I would tend to go for linear because this is easily measureable and also is straight forward to implement in the usual cases (attention: I assume that "usual" means something like PWM and I don't know much about the physics of backlights but just assume that a PWM will create a linear mapping). > > And the big upside is that in the end (i.e. when all kernel drivers and > > userspace applications are adapted to provide/consume the "correct" > > curve) the result is simpler. > > My view is that this convergence will eventually be achieved but it will > happen through the obsolescence of the backlight sysfs interface. The > sysfs interface has other flaws, in particular no integration with the > DRM connector API. > > Thus I would expect an alternative interface to emerge, most likely as > part of the DRM connector API. I'd expect such a new API to a > perceptual scale and to have a fixed max brightness with enough > steps to support animated backlight effects (IIRC 0..100 has been > proposed in the past) Then work on the new stuff instead of making the old stuff (that is intended to die) harder to use correctly? > In the mean time getting the existing collection of backlight drivers > marked up as linear/logarithmic/etc will ease the introduction of that > API because, within the kernel, we might have gathered enough knowledge > to have some hope of correctly mapping each backlight onto a > standardized scale. It would be enough to do this in a code comment then. That would come without the need to adapt the old userspace API. Also when the old solution works at 95% instead of 90% before, it will resist harder to dying. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-19 10:21 ` Uwe Kleine-König @ 2019-08-19 11:16 ` Daniel Thompson -1 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-19 11:16 UTC (permalink / raw) To: Uwe Kleine-König Cc: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, kernel On Mon, Aug 19, 2019 at 12:21:27PM +0200, Uwe Kleine-König wrote: > > > > In an ideal world the backlight interface would be consistent as you > > > > suggest, however there are plenty of existing devices which use the > > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > > one). Userspace still has to deal with these. And changing previously > > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > > there was no policy before about the meaning of > > > > > > echo 17 > brightness > > > > > > other than "brighter than lower values and darker than higher ones" > > > introducing (say) the scale is intended to represent a linear brightness > > > curve is ok. > > > > > > Unless userspace jumps through hoops and tries to identify the actual > > > device it is running on it is wrong on some machines anyhow and we're > > > only shifting the set of affected machines with a tighter policy (until > > > that userspace application is fixed). > > > > I believe that there are two common approaches by userspace at present: > > > > 1. Assume the scale is perceptual and we can directly map a slider > > to the backlight value. This is common simply because most ACPI > > backlights are perceptual and therefore when tested in a laptop > > it works OK. > > > > 2. Assume that is max brightness is small (e.g. ACPI) then the > > scale is perceptual and if the max brightness is large (e.g. > > a PWM) then the scale is linear and apply a correction > > function between the slider and the control. > > > > That historic baggage makes is diffcult to "just define a standardized > > scale"... especially given that if we selected a standardized scale we > > would probably want a perceptual scale with lots of steps (e.g. break > > the heuristic). > > With "perceptual" you mean that logarithmic stuff, right? Human perception is fairly complex so it depends how strict you want to get. At the end of the day what it means is you can map a slider UI component directly to the backlight range and it will feel right. Thus a userspace that maps directly to a slider *is* assuming the scale is perceptual. Logarithmic scales are often mentioned in this kind of conversation because they are hoped to be "perceptual enough". They are not strictly matched to human perception but with a sane exponent shouldn't feel as broken as a linear scale does. Finally note that for people with an audio background then logarithmic and perceptual are used interchangably (based on the assumption that decibels are a preceptual scale). > I would tend to go for linear because this is easily measureable and > also is straight forward to implement in the usual cases (attention: I > assume that "usual" means something like PWM and I don't know much about > the physics of backlights but just assume that a PWM will create a > linear mapping). Mandating a linear scale makes things difficult for ACPI systems (which are amoung the most common cases) since we would have to un-perceptualize it. Additionally it is not a particularly helpful scale to offer the userspace. All proposals I have seen in this space assume we will map linear hardware to a perceptual scale rather than trying to unmap devices that are already perceptual. Within the backlight space we are also moving (slowly) towards perceptual scales to align with this. For example pwm_bl.c will automatically generate a perceptual table unless the DT tells it not to. > > > And the big upside is that in the end (i.e. when all kernel drivers and > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > Then work on the new stuff instead of making the old stuff (that is > intended to die) harder to use correctly? I do not accept this this change makes it harder to use the backlight correctly. We know the current userspace heuristics are fragile and that as backlight animation becomes more popular will become unmaintainable (backlight animation encourages backlights with a perceptual scale to introduce more steps... resulting in them being mishandled by userspace). Anyhow given we know sophisticated userspaces already have two code paths controls by heuristic and that this will break then we are simply providing a clear indication that allows their maintainers a non-heuristic solution when bug reports come in. It also means that userspaces that are currently naive (e.g. assume perceptual scale) need not introduce a heuristic if they get a bug report. > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. > > It would be enough to do this in a code comment then. That would come > without the need to adapt the old userspace API. Also when the old > solution works at 95% instead of 90% before, it will resist harder to > dying. To be honest I think the traction for the sysfs interface comes from the fact that, with or without the proposed change, it is good enough for the ACPI systems that dominate the landscape. Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 11:16 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-19 11:16 UTC (permalink / raw) To: Uwe Kleine-König Cc: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, kernel On Mon, Aug 19, 2019 at 12:21:27PM +0200, Uwe Kleine-König wrote: > > > > In an ideal world the backlight interface would be consistent as you > > > > suggest, however there are plenty of existing devices which use the > > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > > one). Userspace still has to deal with these. And changing previously > > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > > there was no policy before about the meaning of > > > > > > echo 17 > brightness > > > > > > other than "brighter than lower values and darker than higher ones" > > > introducing (say) the scale is intended to represent a linear brightness > > > curve is ok. > > > > > > Unless userspace jumps through hoops and tries to identify the actual > > > device it is running on it is wrong on some machines anyhow and we're > > > only shifting the set of affected machines with a tighter policy (until > > > that userspace application is fixed). > > > > I believe that there are two common approaches by userspace at present: > > > > 1. Assume the scale is perceptual and we can directly map a slider > > to the backlight value. This is common simply because most ACPI > > backlights are perceptual and therefore when tested in a laptop > > it works OK. > > > > 2. Assume that is max brightness is small (e.g. ACPI) then the > > scale is perceptual and if the max brightness is large (e.g. > > a PWM) then the scale is linear and apply a correction > > function between the slider and the control. > > > > That historic baggage makes is diffcult to "just define a standardized > > scale"... especially given that if we selected a standardized scale we > > would probably want a perceptual scale with lots of steps (e.g. break > > the heuristic). > > With "perceptual" you mean that logarithmic stuff, right? Human perception is fairly complex so it depends how strict you want to get. At the end of the day what it means is you can map a slider UI component directly to the backlight range and it will feel right. Thus a userspace that maps directly to a slider *is* assuming the scale is perceptual. Logarithmic scales are often mentioned in this kind of conversation because they are hoped to be "perceptual enough". They are not strictly matched to human perception but with a sane exponent shouldn't feel as broken as a linear scale does. Finally note that for people with an audio background then logarithmic and perceptual are used interchangably (based on the assumption that decibels are a preceptual scale). > I would tend to go for linear because this is easily measureable and > also is straight forward to implement in the usual cases (attention: I > assume that "usual" means something like PWM and I don't know much about > the physics of backlights but just assume that a PWM will create a > linear mapping). Mandating a linear scale makes things difficult for ACPI systems (which are amoung the most common cases) since we would have to un-perceptualize it. Additionally it is not a particularly helpful scale to offer the userspace. All proposals I have seen in this space assume we will map linear hardware to a perceptual scale rather than trying to unmap devices that are already perceptual. Within the backlight space we are also moving (slowly) towards perceptual scales to align with this. For example pwm_bl.c will automatically generate a perceptual table unless the DT tells it not to. > > > And the big upside is that in the end (i.e. when all kernel drivers and > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > Then work on the new stuff instead of making the old stuff (that is > intended to die) harder to use correctly? I do not accept this this change makes it harder to use the backlight correctly. We know the current userspace heuristics are fragile and that as backlight animation becomes more popular will become unmaintainable (backlight animation encourages backlights with a perceptual scale to introduce more steps... resulting in them being mishandled by userspace). Anyhow given we know sophisticated userspaces already have two code paths controls by heuristic and that this will break then we are simply providing a clear indication that allows their maintainers a non-heuristic solution when bug reports come in. It also means that userspaces that are currently naive (e.g. assume perceptual scale) need not introduce a heuristic if they get a bug report. > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. > > It would be enough to do this in a code comment then. That would come > without the need to adapt the old userspace API. Also when the old > solution works at 95% instead of 90% before, it will resist harder to > dying. To be honest I think the traction for the sysfs interface comes from the fact that, with or without the proposed change, it is good enough for the ACPI systems that dominate the landscape. Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-19 11:16 ` Daniel Thompson @ 2019-08-19 12:29 ` Uwe Kleine-König -1 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 12:29 UTC (permalink / raw) To: Daniel Thompson Cc: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, kernel On Mon, Aug 19, 2019 at 12:16:13PM +0100, Daniel Thompson wrote: > On Mon, Aug 19, 2019 at 12:21:27PM +0200, Uwe Kleine-König wrote: > > > > > In an ideal world the backlight interface would be consistent as you > > > > > suggest, however there are plenty of existing devices which use the > > > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > > > one). Userspace still has to deal with these. And changing previously > > > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > > > there was no policy before about the meaning of > > > > > > > > echo 17 > brightness > > > > > > > > other than "brighter than lower values and darker than higher ones" > > > > introducing (say) the scale is intended to represent a linear brightness > > > > curve is ok. > > > > > > > > Unless userspace jumps through hoops and tries to identify the actual > > > > device it is running on it is wrong on some machines anyhow and we're > > > > only shifting the set of affected machines with a tighter policy (until > > > > that userspace application is fixed). > > > > > > I believe that there are two common approaches by userspace at present: > > > > > > 1. Assume the scale is perceptual and we can directly map a slider > > > to the backlight value. This is common simply because most ACPI > > > backlights are perceptual and therefore when tested in a laptop > > > it works OK. > > > > > > 2. Assume that is max brightness is small (e.g. ACPI) then the > > > scale is perceptual and if the max brightness is large (e.g. > > > a PWM) then the scale is linear and apply a correction > > > function between the slider and the control. > > > > > > That historic baggage makes is diffcult to "just define a standardized > > > scale"... especially given that if we selected a standardized scale we > > > would probably want a perceptual scale with lots of steps (e.g. break > > > the heuristic). > > > > With "perceptual" you mean that logarithmic stuff, right? > > Human perception is fairly complex so it depends how strict you want to > get. At the end of the day what it means is you can map a slider UI > component directly to the backlight range and it will feel right. Thus > a userspace that maps directly to a slider *is* assuming the scale > is perceptual. I have problems to declare something as "the right thing to do" that depends on feeling of users. I much prefer to make a technical device authoritative here (in this case a device that measures emitted light). Other than that I don't have enough experience with backlights to judge the decisions that have to be done and so will stop my participation in this thread now. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-19 12:29 ` Uwe Kleine-König 0 siblings, 0 replies; 74+ messages in thread From: Uwe Kleine-König @ 2019-08-19 12:29 UTC (permalink / raw) To: Daniel Thompson Cc: Matthias Kaehlcke, Thierry Reding, Lee Jones, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, kernel On Mon, Aug 19, 2019 at 12:16:13PM +0100, Daniel Thompson wrote: > On Mon, Aug 19, 2019 at 12:21:27PM +0200, Uwe Kleine-König wrote: > > > > > In an ideal world the backlight interface would be consistent as you > > > > > suggest, however there are plenty of existing devices which use the > > > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > > > one). Userspace still has to deal with these. And changing previously > > > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > > > there was no policy before about the meaning of > > > > > > > > echo 17 > brightness > > > > > > > > other than "brighter than lower values and darker than higher ones" > > > > introducing (say) the scale is intended to represent a linear brightness > > > > curve is ok. > > > > > > > > Unless userspace jumps through hoops and tries to identify the actual > > > > device it is running on it is wrong on some machines anyhow and we're > > > > only shifting the set of affected machines with a tighter policy (until > > > > that userspace application is fixed). > > > > > > I believe that there are two common approaches by userspace at present: > > > > > > 1. Assume the scale is perceptual and we can directly map a slider > > > to the backlight value. This is common simply because most ACPI > > > backlights are perceptual and therefore when tested in a laptop > > > it works OK. > > > > > > 2. Assume that is max brightness is small (e.g. ACPI) then the > > > scale is perceptual and if the max brightness is large (e.g. > > > a PWM) then the scale is linear and apply a correction > > > function between the slider and the control. > > > > > > That historic baggage makes is diffcult to "just define a standardized > > > scale"... especially given that if we selected a standardized scale we > > > would probably want a perceptual scale with lots of steps (e.g. break > > > the heuristic). > > > > With "perceptual" you mean that logarithmic stuff, right? > > Human perception is fairly complex so it depends how strict you want to > get. At the end of the day what it means is you can map a slider UI > component directly to the backlight range and it will feel right. Thus > a userspace that maps directly to a slider *is* assuming the scale > is perceptual. I have problems to declare something as "the right thing to do" that depends on feeling of users. I much prefer to make a technical device authoritative here (in this case a device that measures emitted light). Other than that I don't have enough experience with backlights to judge the decisions that have to be done and so will stop my participation in this thread now. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-19 9:50 ` Daniel Thompson (?) @ 2019-08-20 14:49 ` Daniel Vetter -1 siblings, 0 replies; 74+ messages in thread From: Daniel Vetter @ 2019-08-20 14:49 UTC (permalink / raw) To: Daniel Thompson Cc: Uwe Kleine-König, linux-pwm, Linux Fbdev development list, Sascha Hauer, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, Linux Kernel Mailing List, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > Hello Matthias, > > > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > > Hi Uwe, > > > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > > that in a few words? > > > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > > backlights with a linear brightness curve brightness controls like > > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > > > As of now userspace doesn't have information about the type of the > > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > > be right most of the time, but not always. The new attribute eliminates > > > > > the need to guess. > > > > > > > > This is about backlights right? So the kernel provides to userspace an > > > > interval [0, x] for some x and depending on the physics of the the > > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > > 50% perceived light, right? > > > > > > correct > > > > > > > I wonder if it would be possible instead of giving different backlight > > > > implementations the freedom to use either linear or logarithmic (or > > > > quadratic?) scaling and tell userspace which of the options were picked > > > > require the drivers to provide a (say) linear scaling and then userspace > > > > wouldn't need to care about the exact physics. > > > > > > In an ideal world the backlight interface would be consistent as you > > > suggest, however there are plenty of existing devices which use the > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > one). Userspace still has to deal with these. And changing previously > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > there was no policy before about the meaning of > > > > echo 17 > brightness > > > > other than "brighter than lower values and darker than higher ones" > > introducing (say) the scale is intended to represent a linear brightness > > curve is ok. > > > > Unless userspace jumps through hoops and tries to identify the actual > > device it is running on it is wrong on some machines anyhow and we're > > only shifting the set of affected machines with a tighter policy (until > > that userspace application is fixed). > > I believe that there are two common approaches by userspace at present: > > 1. Assume the scale is perceptual and we can directly map a slider > to the backlight value. This is common simply because most ACPI > backlights are perceptual and therefore when tested in a laptop > it works OK. > > 2. Assume that is max brightness is small (e.g. ACPI) then the > scale is perceptual and if the max brightness is large (e.g. > a PWM) then the scale is linear and apply a correction > function between the slider and the control. > > That historic baggage makes is diffcult to "just define a standardized > scale"... especially given that if we selected a standardized scale we > would probably want a perceptual scale with lots of steps (e.g. break > the heuristic). > > > > And the big upside is that in the end (i.e. when all kernel drivers and > > userspace applications are adapted to provide/consume the "correct" > > curve) the result is simpler. > > My view is that this convergence will eventually be achieved but it will > happen through the obsolescence of the backlight sysfs interface. The > sysfs interface has other flaws, in particular no integration with the > DRM connector API. > > Thus I would expect an alternative interface to emerge, most likely as > part of the DRM connector API. I'd expect such a new API to a > perceptual scale and to have a fixed max brightness with enough > steps to support animated backlight effects (IIRC 0..100 has been > proposed in the past) > > In the mean time getting the existing collection of backlight drivers > marked up as linear/logarithmic/etc will ease the introduction of that > API because, within the kernel, we might have gathered enough knowledge > to have some hope of correctly mapping each backlight onto a > standardized scale. In case people wonder why the drm connector based backlight interface hasn't happened ages ago, some more context: - userspace (well libbacklight) selects the right backlight, using some priority search. Plus blacklists in drivers to make sure they're not overriding the real backlight driver (e.g. acpi has higher priority in libbacklight, but on modern system it's not the backlight driver you want. If we move that into the kernel it's going to be somewhat a mess, since defacto you never know when loading is complete and you actually have the right backlight driver. This isn't a problem on DT platforms, but really just for x86/acpi platforms. But if we don't fix them, then userspace adoption of these new interfaces will likely be too low to matter. - second issue is that right now the kms client is supposed to handle backlight around modeset, like fbdev does through the fb notifier. Except for drivers which do handle the backlight across modesets, but maybe not the right backlight. If we move the backlight interface to drm connectors then the right thing would be for the drm driver to handle backlight enable/disable across modesets. But to make that work, userspace needs to stop touching it (otherwise userspace first disables, then the kernel and then on restore the two fight and usually black screen wins), and that's a bit a tricky uapi problem of not breaking existing userspace. - finally there's some userspace which assumes the lowest backlight setting is actually off, and uses that to do fast modesets. This doesn't work on most ACPI backlights, so I think that problem isn't widespread. Anyway from watching from afar, I think this clarification on what the backlight scale means internally should at least help us somewhat in the long term. But the long term solution itself needs someone with way too much time I fear, so lets not hold up anything on that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-20 14:49 ` Daniel Vetter 0 siblings, 0 replies; 74+ messages in thread From: Daniel Vetter @ 2019-08-20 14:49 UTC (permalink / raw) To: Daniel Thompson Cc: linux-pwm, Linux Fbdev development list, Pavel Machek, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, Linux Kernel Mailing List, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Sascha Hauer, Uwe Kleine-König, Enric Balletbo i Serra, Lee Jones On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > Hello Matthias, > > > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > > Hi Uwe, > > > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > > that in a few words? > > > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > > backlights with a linear brightness curve brightness controls like > > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > > > As of now userspace doesn't have information about the type of the > > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > > be right most of the time, but not always. The new attribute eliminates > > > > > the need to guess. > > > > > > > > This is about backlights right? So the kernel provides to userspace an > > > > interval [0, x] for some x and depending on the physics of the the > > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > > 50% perceived light, right? > > > > > > correct > > > > > > > I wonder if it would be possible instead of giving different backlight > > > > implementations the freedom to use either linear or logarithmic (or > > > > quadratic?) scaling and tell userspace which of the options were picked > > > > require the drivers to provide a (say) linear scaling and then userspace > > > > wouldn't need to care about the exact physics. > > > > > > In an ideal world the backlight interface would be consistent as you > > > suggest, however there are plenty of existing devices which use the > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > one). Userspace still has to deal with these. And changing previously > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > there was no policy before about the meaning of > > > > echo 17 > brightness > > > > other than "brighter than lower values and darker than higher ones" > > introducing (say) the scale is intended to represent a linear brightness > > curve is ok. > > > > Unless userspace jumps through hoops and tries to identify the actual > > device it is running on it is wrong on some machines anyhow and we're > > only shifting the set of affected machines with a tighter policy (until > > that userspace application is fixed). > > I believe that there are two common approaches by userspace at present: > > 1. Assume the scale is perceptual and we can directly map a slider > to the backlight value. This is common simply because most ACPI > backlights are perceptual and therefore when tested in a laptop > it works OK. > > 2. Assume that is max brightness is small (e.g. ACPI) then the > scale is perceptual and if the max brightness is large (e.g. > a PWM) then the scale is linear and apply a correction > function between the slider and the control. > > That historic baggage makes is diffcult to "just define a standardized > scale"... especially given that if we selected a standardized scale we > would probably want a perceptual scale with lots of steps (e.g. break > the heuristic). > > > > And the big upside is that in the end (i.e. when all kernel drivers and > > userspace applications are adapted to provide/consume the "correct" > > curve) the result is simpler. > > My view is that this convergence will eventually be achieved but it will > happen through the obsolescence of the backlight sysfs interface. The > sysfs interface has other flaws, in particular no integration with the > DRM connector API. > > Thus I would expect an alternative interface to emerge, most likely as > part of the DRM connector API. I'd expect such a new API to a > perceptual scale and to have a fixed max brightness with enough > steps to support animated backlight effects (IIRC 0..100 has been > proposed in the past) > > In the mean time getting the existing collection of backlight drivers > marked up as linear/logarithmic/etc will ease the introduction of that > API because, within the kernel, we might have gathered enough knowledge > to have some hope of correctly mapping each backlight onto a > standardized scale. In case people wonder why the drm connector based backlight interface hasn't happened ages ago, some more context: - userspace (well libbacklight) selects the right backlight, using some priority search. Plus blacklists in drivers to make sure they're not overriding the real backlight driver (e.g. acpi has higher priority in libbacklight, but on modern system it's not the backlight driver you want. If we move that into the kernel it's going to be somewhat a mess, since defacto you never know when loading is complete and you actually have the right backlight driver. This isn't a problem on DT platforms, but really just for x86/acpi platforms. But if we don't fix them, then userspace adoption of these new interfaces will likely be too low to matter. - second issue is that right now the kms client is supposed to handle backlight around modeset, like fbdev does through the fb notifier. Except for drivers which do handle the backlight across modesets, but maybe not the right backlight. If we move the backlight interface to drm connectors then the right thing would be for the drm driver to handle backlight enable/disable across modesets. But to make that work, userspace needs to stop touching it (otherwise userspace first disables, then the kernel and then on restore the two fight and usually black screen wins), and that's a bit a tricky uapi problem of not breaking existing userspace. - finally there's some userspace which assumes the lowest backlight setting is actually off, and uses that to do fast modesets. This doesn't work on most ACPI backlights, so I think that problem isn't widespread. Anyway from watching from afar, I think this clarification on what the backlight scale means internally should at least help us somewhat in the long term. But the long term solution itself needs someone with way too much time I fear, so lets not hold up anything on that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-20 14:49 ` Daniel Vetter 0 siblings, 0 replies; 74+ messages in thread From: Daniel Vetter @ 2019-08-20 14:49 UTC (permalink / raw) To: Daniel Thompson Cc: linux-pwm, Linux Fbdev development list, Pavel Machek, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, Linux Kernel Mailing List, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Sascha Hauer, Uwe Kleine-König, Enric Balletbo i Serra, Lee Jones On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > Hello Matthias, > > > > On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote: > > > On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote: > > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > > Hi Uwe, > > > > > > > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König wrote: > > > > > > On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote: > > > > > > > Backlight brightness curves can have different shapes. The two main > > > > > > > types are linear and non-linear curves. The human eye doesn't > > > > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > > > > logarithmic) brightness curves. The type of curve currently is opaque > > > > > > > to userspace, so userspace often uses more or less reliable heuristics > > > > > > > (like the number of brightness levels) to decide whether to treat a > > > > > > > backlight device as linear or non-linear. > > > > > > > > > > > > > > Export the type of the brightness curve via the new sysfs attribute > > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > > > > > > > 'unknown'. For devices that don't provide information about the scale > > > > > > > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > > > > > > > > > > > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > > > > > > > > > > > I wonder what kind of problem you are solving here. Can you describe > > > > > > that in a few words? > > > > > > > > > > The human eye perceives brightness in a logarithmic manner. For > > > > > backlights with a linear brightness curve brightness controls like > > > > > sliders need to use a mapping to achieve a behavior that is perceived > > > > > as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf) > > > > > > > > > > As of now userspace doesn't have information about the type of the > > > > > brightness curve, and often uses heuristics to make a guess, which may > > > > > be right most of the time, but not always. The new attribute eliminates > > > > > the need to guess. > > > > > > > > This is about backlights right? So the kernel provides to userspace an > > > > interval [0, x] for some x and depending on the physics of the the > > > > backlight configuring x/2 (probably?) either means 50% measured light or > > > > 50% perceived light, right? > > > > > > correct > > > > > > > I wonder if it would be possible instead of giving different backlight > > > > implementations the freedom to use either linear or logarithmic (or > > > > quadratic?) scaling and tell userspace which of the options were picked > > > > require the drivers to provide a (say) linear scaling and then userspace > > > > wouldn't need to care about the exact physics. > > > > > > In an ideal world the backlight interface would be consistent as you > > > suggest, however there are plenty of existing devices which use the > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > one). Userspace still has to deal with these. And changing previously > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > there was no policy before about the meaning of > > > > echo 17 > brightness > > > > other than "brighter than lower values and darker than higher ones" > > introducing (say) the scale is intended to represent a linear brightness > > curve is ok. > > > > Unless userspace jumps through hoops and tries to identify the actual > > device it is running on it is wrong on some machines anyhow and we're > > only shifting the set of affected machines with a tighter policy (until > > that userspace application is fixed). > > I believe that there are two common approaches by userspace at present: > > 1. Assume the scale is perceptual and we can directly map a slider > to the backlight value. This is common simply because most ACPI > backlights are perceptual and therefore when tested in a laptop > it works OK. > > 2. Assume that is max brightness is small (e.g. ACPI) then the > scale is perceptual and if the max brightness is large (e.g. > a PWM) then the scale is linear and apply a correction > function between the slider and the control. > > That historic baggage makes is diffcult to "just define a standardized > scale"... especially given that if we selected a standardized scale we > would probably want a perceptual scale with lots of steps (e.g. break > the heuristic). > > > > And the big upside is that in the end (i.e. when all kernel drivers and > > userspace applications are adapted to provide/consume the "correct" > > curve) the result is simpler. > > My view is that this convergence will eventually be achieved but it will > happen through the obsolescence of the backlight sysfs interface. The > sysfs interface has other flaws, in particular no integration with the > DRM connector API. > > Thus I would expect an alternative interface to emerge, most likely as > part of the DRM connector API. I'd expect such a new API to a > perceptual scale and to have a fixed max brightness with enough > steps to support animated backlight effects (IIRC 0..100 has been > proposed in the past) > > In the mean time getting the existing collection of backlight drivers > marked up as linear/logarithmic/etc will ease the introduction of that > API because, within the kernel, we might have gathered enough knowledge > to have some hope of correctly mapping each backlight onto a > standardized scale. In case people wonder why the drm connector based backlight interface hasn't happened ages ago, some more context: - userspace (well libbacklight) selects the right backlight, using some priority search. Plus blacklists in drivers to make sure they're not overriding the real backlight driver (e.g. acpi has higher priority in libbacklight, but on modern system it's not the backlight driver you want. If we move that into the kernel it's going to be somewhat a mess, since defacto you never know when loading is complete and you actually have the right backlight driver. This isn't a problem on DT platforms, but really just for x86/acpi platforms. But if we don't fix them, then userspace adoption of these new interfaces will likely be too low to matter. - second issue is that right now the kms client is supposed to handle backlight around modeset, like fbdev does through the fb notifier. Except for drivers which do handle the backlight across modesets, but maybe not the right backlight. If we move the backlight interface to drm connectors then the right thing would be for the drm driver to handle backlight enable/disable across modesets. But to make that work, userspace needs to stop touching it (otherwise userspace first disables, then the kernel and then on restore the two fight and usually black screen wins), and that's a bit a tricky uapi problem of not breaking existing userspace. - finally there's some userspace which assumes the lowest backlight setting is actually off, and uses that to do fast modesets. This doesn't work on most ACPI backlights, so I think that problem isn't widespread. Anyway from watching from afar, I think this clarification on what the backlight scale means internally should at least help us somewhat in the long term. But the long term solution itself needs someone with way too much time I fear, so lets not hold up anything on that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-08-20 14:49 ` Daniel Vetter (?) @ 2019-08-21 14:16 ` Daniel Thompson -1 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-21 14:16 UTC (permalink / raw) To: Daniel Vetter Cc: Uwe Kleine-König, linux-pwm, Linux Fbdev development list, Sascha Hauer, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, Linux Kernel Mailing List, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra, Lee Jones On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote: > On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson > <daniel.thompson@linaro.org> wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > > And the big upside is that in the end (i.e. when all kernel drivers and > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. > > In case people wonder why the drm connector based backlight interface > hasn't happened ages ago, some more context: > > - userspace (well libbacklight) selects the right backlight, using > some priority search. Plus blacklists in drivers to make sure they're > not overriding the real backlight driver (e.g. acpi has higher > priority in libbacklight, but on modern system it's not the backlight > driver you want. If we move that into the kernel it's going to be > somewhat a mess, since defacto you never know when loading is complete > and you actually have the right backlight driver. > > This isn't a problem on DT platforms, but really just for x86/acpi > platforms. But if we don't fix them, then userspace adoption of these > new interfaces will likely be too low to matter. > > - second issue is that right now the kms client is supposed to handle > backlight around modeset, like fbdev does through the fb notifier. > Except for drivers which do handle the backlight across modesets, but > maybe not the right backlight. If we move the backlight interface to > drm connectors then the right thing would be for the drm driver to > handle backlight enable/disable across modesets. But to make that > work, userspace needs to stop touching it (otherwise userspace first > disables, then the kernel and then on restore the two fight and > usually black screen wins), and that's a bit a tricky uapi problem of > not breaking existing userspace. > > - finally there's some userspace which assumes the lowest backlight > setting is actually off, and uses that to do fast modesets. This > doesn't work on most ACPI backlights, so I think that problem isn't > widespread. > > Anyway from watching from afar, I think this clarification on what the > backlight scale means internally should at least help us somewhat in > the long term. But the long term solution itself needs someone with > way too much time I fear, so lets not hold up anything on that. Thanks for sharing your views on this. Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-21 14:16 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-21 14:16 UTC (permalink / raw) To: Daniel Vetter Cc: linux-pwm, Linux Fbdev development list, Pavel Machek, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, Linux Kernel Mailing List, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Sascha Hauer, Uwe Kleine-König, Enric Balletbo i Serra, Lee Jones On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote: > On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson > <daniel.thompson@linaro.org> wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > > And the big upside is that in the end (i.e. when all kernel drivers and > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. > > In case people wonder why the drm connector based backlight interface > hasn't happened ages ago, some more context: > > - userspace (well libbacklight) selects the right backlight, using > some priority search. Plus blacklists in drivers to make sure they're > not overriding the real backlight driver (e.g. acpi has higher > priority in libbacklight, but on modern system it's not the backlight > driver you want. If we move that into the kernel it's going to be > somewhat a mess, since defacto you never know when loading is complete > and you actually have the right backlight driver. > > This isn't a problem on DT platforms, but really just for x86/acpi > platforms. But if we don't fix them, then userspace adoption of these > new interfaces will likely be too low to matter. > > - second issue is that right now the kms client is supposed to handle > backlight around modeset, like fbdev does through the fb notifier. > Except for drivers which do handle the backlight across modesets, but > maybe not the right backlight. If we move the backlight interface to > drm connectors then the right thing would be for the drm driver to > handle backlight enable/disable across modesets. But to make that > work, userspace needs to stop touching it (otherwise userspace first > disables, then the kernel and then on restore the two fight and > usually black screen wins), and that's a bit a tricky uapi problem of > not breaking existing userspace. > > - finally there's some userspace which assumes the lowest backlight > setting is actually off, and uses that to do fast modesets. This > doesn't work on most ACPI backlights, so I think that problem isn't > widespread. > > Anyway from watching from afar, I think this clarification on what the > backlight scale means internally should at least help us somewhat in > the long term. But the long term solution itself needs someone with > way too much time I fear, so lets not hold up anything on that. Thanks for sharing your views on this. Daniel. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-08-21 14:16 ` Daniel Thompson 0 siblings, 0 replies; 74+ messages in thread From: Daniel Thompson @ 2019-08-21 14:16 UTC (permalink / raw) To: Daniel Vetter Cc: linux-pwm, Linux Fbdev development list, Pavel Machek, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, Linux Kernel Mailing List, dri-devel, Douglas Anderson, Matthias Kaehlcke, Thierry Reding, Jacek Anaszewski, Sascha Hauer, Uwe Kleine-König, Enric Balletbo i Serra, Lee Jones On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote: > On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson > <daniel.thompson@linaro.org> wrote: > > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote: > > > And the big upside is that in the end (i.e. when all kernel drivers and > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. > > In case people wonder why the drm connector based backlight interface > hasn't happened ages ago, some more context: > > - userspace (well libbacklight) selects the right backlight, using > some priority search. Plus blacklists in drivers to make sure they're > not overriding the real backlight driver (e.g. acpi has higher > priority in libbacklight, but on modern system it's not the backlight > driver you want. If we move that into the kernel it's going to be > somewhat a mess, since defacto you never know when loading is complete > and you actually have the right backlight driver. > > This isn't a problem on DT platforms, but really just for x86/acpi > platforms. But if we don't fix them, then userspace adoption of these > new interfaces will likely be too low to matter. > > - second issue is that right now the kms client is supposed to handle > backlight around modeset, like fbdev does through the fb notifier. > Except for drivers which do handle the backlight across modesets, but > maybe not the right backlight. If we move the backlight interface to > drm connectors then the right thing would be for the drm driver to > handle backlight enable/disable across modesets. But to make that > work, userspace needs to stop touching it (otherwise userspace first > disables, then the kernel and then on restore the two fight and > usually black screen wins), and that's a bit a tricky uapi problem of > not breaking existing userspace. > > - finally there's some userspace which assumes the lowest backlight > setting is actually off, and uses that to do fast modesets. This > doesn't work on most ACPI backlights, so I think that problem isn't > widespread. > > Anyway from watching from afar, I think this clarification on what the > backlight scale means internally should at least help us somewhat in > the long term. But the long term solution itself needs someone with > way too much time I fear, so lets not hold up anything on that. Thanks for sharing your views on this. Daniel. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-09-02 9:41 ` Lee Jones -1 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:41 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve currently is opaque > to userspace, so userspace often uses more or less reliable heuristics > (like the number of brightness levels) to decide whether to treat a > backlight device as linear or non-linear. > > Export the type of the brightness curve via the new sysfs attribute > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > 'unknown'. For devices that don't provide information about the scale > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > --- > Feel free to suggest improvements in the documentation :) > > Changes in v3: > - removed composite strings, only keep 'linear', 'non-linear' and > 'unknown' > - updated sysfs attribute documentation > - updated commit message > > Changes in v2: > - changed order of brightness scale enums, explicitly make 'unknown' zero > - minor update of commit message > - deleted excess blank line after 'backlight_scale_types' > - s/curves/curve/ in sysfs doc > --- > .../ABI/testing/sysfs-class-backlight | 26 +++++++++++++++++++ > MAINTAINERS | 1 + > drivers/video/backlight/backlight.c | 19 ++++++++++++++ > include/linux/backlight.h | 8 ++++++ > 4 files changed, 54 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs @ 2019-09-02 9:41 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:41 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve currently is opaque > to userspace, so userspace often uses more or less reliable heuristics > (like the number of brightness levels) to decide whether to treat a > backlight device as linear or non-linear. > > Export the type of the brightness curve via the new sysfs attribute > 'scale'. The value of the attribute can be 'linear', 'non-linear' or > 'unknown'. For devices that don't provide information about the scale > of their brightness curve the value of the 'scale' attribute is 'unknown'. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > --- > Feel free to suggest improvements in the documentation :) > > Changes in v3: > - removed composite strings, only keep 'linear', 'non-linear' and > 'unknown' > - updated sysfs attribute documentation > - updated commit message > > Changes in v2: > - changed order of brightness scale enums, explicitly make 'unknown' zero > - minor update of commit message > - deleted excess blank line after 'backlight_scale_types' > - s/curves/curve/ in sysfs doc > --- > .../ABI/testing/sysfs-class-backlight | 26 +++++++++++++++++++ > MAINTAINERS | 1 + > drivers/video/backlight/backlight.c | 19 ++++++++++++++ > include/linux/backlight.h | 8 ++++++ > 4 files changed, 54 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-07-09 19:00 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke For backlight curves calculated with the CIE 1931 algorithm set the brightness scale type to non-linear. This makes the scale type available to userspace via the 'scale' sysfs attribute. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> --- Changes in v3: - mark scale as non-linear instead of using the CIE1931 type which has been removed - updated commit message Changes in v2: - added Enric's 'Tested-by' tag - added Daniel's 'Acked-by' tag --- drivers/video/backlight/pwm_bl.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index fb45f866b923..7c6dfc4a601d 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -553,6 +553,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) goto err_alloc; } + memset(&props, 0, sizeof(struct backlight_properties)); + if (data->levels) { /* * For the DT case, only when brightness levels is defined @@ -591,6 +593,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->levels = data->levels; } + + props.scale = BACKLIGHT_SCALE_NON_LINEAR; } else { /* * That only happens for the non-DT case, where platform data @@ -601,7 +605,6 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); - memset(&props, 0, sizeof(struct backlight_properties)); props.type = BACKLIGHT_RAW; props.max_brightness = data->max_brightness; bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb, -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves @ 2019-07-09 19:00 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke For backlight curves calculated with the CIE 1931 algorithm set the brightness scale type to non-linear. This makes the scale type available to userspace via the 'scale' sysfs attribute. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> --- Changes in v3: - mark scale as non-linear instead of using the CIE1931 type which has been removed - updated commit message Changes in v2: - added Enric's 'Tested-by' tag - added Daniel's 'Acked-by' tag --- drivers/video/backlight/pwm_bl.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index fb45f866b923..7c6dfc4a601d 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -553,6 +553,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) goto err_alloc; } + memset(&props, 0, sizeof(struct backlight_properties)); + if (data->levels) { /* * For the DT case, only when brightness levels is defined @@ -591,6 +593,8 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->levels = data->levels; } + + props.scale = BACKLIGHT_SCALE_NON_LINEAR; } else { /* * That only happens for the non-DT case, where platform data @@ -601,7 +605,6 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); - memset(&props, 0, sizeof(struct backlight_properties)); props.type = BACKLIGHT_RAW; props.max_brightness = data->max_brightness; bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb, -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-09-02 9:41 ` Lee Jones -1 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:41 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > For backlight curves calculated with the CIE 1931 algorithm set > the brightness scale type to non-linear. This makes the scale type > available to userspace via the 'scale' sysfs attribute. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > Changes in v3: > - mark scale as non-linear instead of using the CIE1931 type which > has been removed > - updated commit message > > Changes in v2: > - added Enric's 'Tested-by' tag > - added Daniel's 'Acked-by' tag > --- > drivers/video/backlight/pwm_bl.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves @ 2019-09-02 9:41 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:41 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > For backlight curves calculated with the CIE 1931 algorithm set > the brightness scale type to non-linear. This makes the scale type > available to userspace via the 'scale' sysfs attribute. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > Changes in v3: > - mark scale as non-linear instead of using the CIE1931 type which > has been removed > - updated commit message > > Changes in v2: > - added Enric's 'Tested-by' tag > - added Daniel's 'Acked-by' tag > --- > drivers/video/backlight/pwm_bl.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH v3 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-07-09 19:00 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke Check if a brightness curve specified in the device tree is linear or not and set the corresponding property accordingly. This makes the scale type available to userspace via the 'scale' sysfs attribute. To determine if a curve is linear it is compared to a interpolated linear curve between min and max brightness. The curve is considered linear if no value deviates more than +/-5% of ${brightness_range} from their interpolated value. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> --- Changes in v3: - none Changes in v2: - use 128 (power of two) instead of 100 as factor for the slope - add comment about max quantization error - added Daniel's 'Acked-by' tag --- drivers/video/backlight/pwm_bl.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index 7c6dfc4a601d..fef98beb8b7e 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -404,6 +404,31 @@ int pwm_backlight_brightness_default(struct device *dev, } #endif +static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data *data) +{ + unsigned int nlevels = data->max_brightness + 1; + unsigned int min_val = data->levels[0]; + unsigned int max_val = data->levels[nlevels - 1]; + /* + * Multiplying by 128 means that even in pathological cases such + * as (max_val - min_val) == nlevels the error at max_val is less + * than 1%. + */ + unsigned int slope = (128 * (max_val - min_val)) / nlevels; + unsigned int margin = (max_val - min_val) / 20; /* 5% */ + int i; + + for (i = 1; i < nlevels; i++) { + unsigned int linear_value = min_val + ((i * slope) / 128); + unsigned int delta = abs(linear_value - data->levels[i]); + + if (delta > margin) + return false; + } + + return true; +} + static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb) { struct device_node *node = pb->dev->of_node; @@ -567,6 +592,11 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->levels = data->levels; } + + if (pwm_backlight_is_linear(data)) + props.scale = BACKLIGHT_SCALE_LINEAR; + else + props.scale = BACKLIGHT_SCALE_NON_LINEAR; } else if (!data->max_brightness) { /* * If no brightness levels are provided and max_brightness is -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH v3 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT @ 2019-07-09 19:00 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-09 19:00 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski, Matthias Kaehlcke Check if a brightness curve specified in the device tree is linear or not and set the corresponding property accordingly. This makes the scale type available to userspace via the 'scale' sysfs attribute. To determine if a curve is linear it is compared to a interpolated linear curve between min and max brightness. The curve is considered linear if no value deviates more than +/-5% of ${brightness_range} from their interpolated value. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> --- Changes in v3: - none Changes in v2: - use 128 (power of two) instead of 100 as factor for the slope - add comment about max quantization error - added Daniel's 'Acked-by' tag --- drivers/video/backlight/pwm_bl.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index 7c6dfc4a601d..fef98beb8b7e 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -404,6 +404,31 @@ int pwm_backlight_brightness_default(struct device *dev, } #endif +static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data *data) +{ + unsigned int nlevels = data->max_brightness + 1; + unsigned int min_val = data->levels[0]; + unsigned int max_val = data->levels[nlevels - 1]; + /* + * Multiplying by 128 means that even in pathological cases such + * as (max_val - min_val) = nlevels the error at max_val is less + * than 1%. + */ + unsigned int slope = (128 * (max_val - min_val)) / nlevels; + unsigned int margin = (max_val - min_val) / 20; /* 5% */ + int i; + + for (i = 1; i < nlevels; i++) { + unsigned int linear_value = min_val + ((i * slope) / 128); + unsigned int delta = abs(linear_value - data->levels[i]); + + if (delta > margin) + return false; + } + + return true; +} + static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb) { struct device_node *node = pb->dev->of_node; @@ -567,6 +592,11 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->levels = data->levels; } + + if (pwm_backlight_is_linear(data)) + props.scale = BACKLIGHT_SCALE_LINEAR; + else + props.scale = BACKLIGHT_SCALE_NON_LINEAR; } else if (!data->max_brightness) { /* * If no brightness levels are provided and max_brightness is -- 2.22.0.410.gd8fdbe21b5-goog ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [PATCH v3 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-09-02 9:42 ` Lee Jones -1 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:42 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > Check if a brightness curve specified in the device tree is linear or > not and set the corresponding property accordingly. This makes the > scale type available to userspace via the 'scale' sysfs attribute. > > To determine if a curve is linear it is compared to a interpolated linear > curve between min and max brightness. The curve is considered linear if > no value deviates more than +/-5% of ${brightness_range} from their > interpolated value. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > Changes in v3: > - none > > Changes in v2: > - use 128 (power of two) instead of 100 as factor for the slope > - add comment about max quantization error > - added Daniel's 'Acked-by' tag > --- > drivers/video/backlight/pwm_bl.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT @ 2019-09-02 9:42 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-09-02 9:42 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, 09 Jul 2019, Matthias Kaehlcke wrote: > Check if a brightness curve specified in the device tree is linear or > not and set the corresponding property accordingly. This makes the > scale type available to userspace via the 'scale' sysfs attribute. > > To determine if a curve is linear it is compared to a interpolated linear > curve between min and max brightness. The curve is considered linear if > no value deviates more than +/-5% of ${brightness_range} from their > interpolated value. > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > Acked-by: Daniel Thompson <daniel.thompson@linaro.org> > --- > Changes in v3: > - none > > Changes in v2: > - use 128 (power of two) instead of 100 as factor for the slope > - add comment about max quantization error > - added Daniel's 'Acked-by' tag > --- > drivers/video/backlight/pwm_bl.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs 2019-07-09 19:00 ` Matthias Kaehlcke @ 2019-07-22 23:59 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-22 23:59 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve is currently opaque > to userspace, so userspace often relies on more or less reliable > heuristics (like the number of brightness levels) to decide whether > to treat a backlight device as linear or non-linear. > > Export the type of the brightness curve via a new sysfs attribute. > > Matthias Kaehlcke (4): > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > backlight: Expose brightness curve type through sysfs > backlight: pwm_bl: Set scale type for CIE 1931 curves > backlight: pwm_bl: Set scale type for brightness curves specified in > the DT > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > MAINTAINERS | 2 ++ > drivers/video/backlight/backlight.c | 19 ++++++++++ > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > include/linux/backlight.h | 8 +++++ > 5 files changed, 89 insertions(+), 1 deletion(-) > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight ping, any comments on v3? Thanks Matthias ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs @ 2019-07-22 23:59 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-22 23:59 UTC (permalink / raw) To: Thierry Reding, Lee Jones, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz Cc: linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > Backlight brightness curves can have different shapes. The two main > types are linear and non-linear curves. The human eye doesn't > perceive linearly increasing/decreasing brightness as linear (see > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > linearly to human eye"), hence many backlights use non-linear (often > logarithmic) brightness curves. The type of curve is currently opaque > to userspace, so userspace often relies on more or less reliable > heuristics (like the number of brightness levels) to decide whether > to treat a backlight device as linear or non-linear. > > Export the type of the brightness curve via a new sysfs attribute. > > Matthias Kaehlcke (4): > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > backlight: Expose brightness curve type through sysfs > backlight: pwm_bl: Set scale type for CIE 1931 curves > backlight: pwm_bl: Set scale type for brightness curves specified in > the DT > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > MAINTAINERS | 2 ++ > drivers/video/backlight/backlight.c | 19 ++++++++++ > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > include/linux/backlight.h | 8 +++++ > 5 files changed, 89 insertions(+), 1 deletion(-) > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight ping, any comments on v3? Thanks Matthias ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs 2019-07-22 23:59 ` Matthias Kaehlcke @ 2019-07-25 11:15 ` Lee Jones -1 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-07-25 11:15 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > Backlight brightness curves can have different shapes. The two main > > types are linear and non-linear curves. The human eye doesn't > > perceive linearly increasing/decreasing brightness as linear (see > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > linearly to human eye"), hence many backlights use non-linear (often > > logarithmic) brightness curves. The type of curve is currently opaque > > to userspace, so userspace often relies on more or less reliable > > heuristics (like the number of brightness levels) to decide whether > > to treat a backlight device as linear or non-linear. > > > > Export the type of the brightness curve via a new sysfs attribute. > > > > Matthias Kaehlcke (4): > > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > > backlight: Expose brightness curve type through sysfs > > backlight: pwm_bl: Set scale type for CIE 1931 curves > > backlight: pwm_bl: Set scale type for brightness curves specified in > > the DT > > > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > > MAINTAINERS | 2 ++ > > drivers/video/backlight/backlight.c | 19 ++++++++++ > > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > > include/linux/backlight.h | 8 +++++ > > 5 files changed, 89 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight > > ping, any comments on v3? Looks like PATCH 2/4 still needs seeing to. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs @ 2019-07-25 11:15 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-07-25 11:15 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > Backlight brightness curves can have different shapes. The two main > > types are linear and non-linear curves. The human eye doesn't > > perceive linearly increasing/decreasing brightness as linear (see > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > linearly to human eye"), hence many backlights use non-linear (often > > logarithmic) brightness curves. The type of curve is currently opaque > > to userspace, so userspace often relies on more or less reliable > > heuristics (like the number of brightness levels) to decide whether > > to treat a backlight device as linear or non-linear. > > > > Export the type of the brightness curve via a new sysfs attribute. > > > > Matthias Kaehlcke (4): > > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > > backlight: Expose brightness curve type through sysfs > > backlight: pwm_bl: Set scale type for CIE 1931 curves > > backlight: pwm_bl: Set scale type for brightness curves specified in > > the DT > > > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > > MAINTAINERS | 2 ++ > > drivers/video/backlight/backlight.c | 19 ++++++++++ > > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > > include/linux/backlight.h | 8 +++++ > > 5 files changed, 89 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight > > ping, any comments on v3? Looks like PATCH 2/4 still needs seeing to. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs 2019-07-25 11:15 ` Lee Jones (?) @ 2019-07-25 17:17 ` Matthias Kaehlcke -1 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-25 17:17 UTC (permalink / raw) To: Lee Jones Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Thu, Jul 25, 2019 at 12:15:41PM +0100, Lee Jones wrote: > On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > > > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve is currently opaque > > > to userspace, so userspace often relies on more or less reliable > > > heuristics (like the number of brightness levels) to decide whether > > > to treat a backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via a new sysfs attribute. > > > > > > Matthias Kaehlcke (4): > > > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > > > backlight: Expose brightness curve type through sysfs > > > backlight: pwm_bl: Set scale type for CIE 1931 curves > > > backlight: pwm_bl: Set scale type for brightness curves specified in > > > the DT > > > > > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > > > MAINTAINERS | 2 ++ > > > drivers/video/backlight/backlight.c | 19 ++++++++++ > > > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > > > include/linux/backlight.h | 8 +++++ > > > 5 files changed, 89 insertions(+), 1 deletion(-) > > > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight > > > > ping, any comments on v3? > > Looks like PATCH 2/4 still needs seeing to. The patch currently doesn't have any comments. Do you see any specific things that need improvement? If so, could you comment on the patch? Thanks Matthias ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs @ 2019-07-25 17:17 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-25 17:17 UTC (permalink / raw) To: Lee Jones Cc: linux-pwm, Daniel Thompson, Douglas Anderson, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra On Thu, Jul 25, 2019 at 12:15:41PM +0100, Lee Jones wrote: > On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > > > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve is currently opaque > > > to userspace, so userspace often relies on more or less reliable > > > heuristics (like the number of brightness levels) to decide whether > > > to treat a backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via a new sysfs attribute. > > > > > > Matthias Kaehlcke (4): > > > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > > > backlight: Expose brightness curve type through sysfs > > > backlight: pwm_bl: Set scale type for CIE 1931 curves > > > backlight: pwm_bl: Set scale type for brightness curves specified in > > > the DT > > > > > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > > > MAINTAINERS | 2 ++ > > > drivers/video/backlight/backlight.c | 19 ++++++++++ > > > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > > > include/linux/backlight.h | 8 +++++ > > > 5 files changed, 89 insertions(+), 1 deletion(-) > > > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight > > > > ping, any comments on v3? > > Looks like PATCH 2/4 still needs seeing to. The patch currently doesn't have any comments. Do you see any specific things that need improvement? If so, could you comment on the patch? Thanks Matthias ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs @ 2019-07-25 17:17 ` Matthias Kaehlcke 0 siblings, 0 replies; 74+ messages in thread From: Matthias Kaehlcke @ 2019-07-25 17:17 UTC (permalink / raw) To: Lee Jones Cc: linux-pwm, Daniel Thompson, Douglas Anderson, Bartlomiej Zolnierkiewicz, Jingoo Han, Brian Norris, linux-fbdev, dri-devel, linux-kernel, Thierry Reding, Jacek Anaszewski, Pavel Machek, Enric Balletbo i Serra On Thu, Jul 25, 2019 at 12:15:41PM +0100, Lee Jones wrote: > On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > > > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > > Backlight brightness curves can have different shapes. The two main > > > types are linear and non-linear curves. The human eye doesn't > > > perceive linearly increasing/decreasing brightness as linear (see > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > linearly to human eye"), hence many backlights use non-linear (often > > > logarithmic) brightness curves. The type of curve is currently opaque > > > to userspace, so userspace often relies on more or less reliable > > > heuristics (like the number of brightness levels) to decide whether > > > to treat a backlight device as linear or non-linear. > > > > > > Export the type of the brightness curve via a new sysfs attribute. > > > > > > Matthias Kaehlcke (4): > > > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > > > backlight: Expose brightness curve type through sysfs > > > backlight: pwm_bl: Set scale type for CIE 1931 curves > > > backlight: pwm_bl: Set scale type for brightness curves specified in > > > the DT > > > > > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > > > MAINTAINERS | 2 ++ > > > drivers/video/backlight/backlight.c | 19 ++++++++++ > > > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > > > include/linux/backlight.h | 8 +++++ > > > 5 files changed, 89 insertions(+), 1 deletion(-) > > > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight > > > > ping, any comments on v3? > > Looks like PATCH 2/4 still needs seeing to. The patch currently doesn't have any comments. Do you see any specific things that need improvement? If so, could you comment on the patch? Thanks Matthias _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs 2019-07-25 17:17 ` Matthias Kaehlcke @ 2019-08-05 10:37 ` Lee Jones -1 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-08-05 10:37 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Thu, 25 Jul 2019, Matthias Kaehlcke wrote: > On Thu, Jul 25, 2019 at 12:15:41PM +0100, Lee Jones wrote: > > On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > > > > > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve is currently opaque > > > > to userspace, so userspace often relies on more or less reliable > > > > heuristics (like the number of brightness levels) to decide whether > > > > to treat a backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via a new sysfs attribute. > > > > > > > > Matthias Kaehlcke (4): > > > > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > > > > backlight: Expose brightness curve type through sysfs > > > > backlight: pwm_bl: Set scale type for CIE 1931 curves > > > > backlight: pwm_bl: Set scale type for brightness curves specified in > > > > the DT > > > > > > > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > > > > MAINTAINERS | 2 ++ > > > > drivers/video/backlight/backlight.c | 19 ++++++++++ > > > > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > > > > include/linux/backlight.h | 8 +++++ > > > > 5 files changed, 89 insertions(+), 1 deletion(-) > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight > > > > > > ping, any comments on v3? > > > > Looks like PATCH 2/4 still needs seeing to. > > The patch currently doesn't have any comments. > > Do you see any specific things that need improvement? If so, could you > comment on the patch? It needs Daniel T's Ack. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs @ 2019-08-05 10:37 ` Lee Jones 0 siblings, 0 replies; 74+ messages in thread From: Lee Jones @ 2019-08-05 10:37 UTC (permalink / raw) To: Matthias Kaehlcke Cc: Thierry Reding, Daniel Thompson, Jingoo Han, Bartlomiej Zolnierkiewicz, linux-pwm, dri-devel, linux-fbdev, linux-kernel, Enric Balletbo i Serra, Douglas Anderson, Brian Norris, Pavel Machek, Jacek Anaszewski On Thu, 25 Jul 2019, Matthias Kaehlcke wrote: > On Thu, Jul 25, 2019 at 12:15:41PM +0100, Lee Jones wrote: > > On Mon, 22 Jul 2019, Matthias Kaehlcke wrote: > > > > > On Tue, Jul 09, 2019 at 12:00:03PM -0700, Matthias Kaehlcke wrote: > > > > Backlight brightness curves can have different shapes. The two main > > > > types are linear and non-linear curves. The human eye doesn't > > > > perceive linearly increasing/decreasing brightness as linear (see > > > > also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED > > > > linearly to human eye"), hence many backlights use non-linear (often > > > > logarithmic) brightness curves. The type of curve is currently opaque > > > > to userspace, so userspace often relies on more or less reliable > > > > heuristics (like the number of brightness levels) to decide whether > > > > to treat a backlight device as linear or non-linear. > > > > > > > > Export the type of the brightness curve via a new sysfs attribute. > > > > > > > > Matthias Kaehlcke (4): > > > > MAINTAINERS: Add entry for stable backlight sysfs ABI documentation > > > > backlight: Expose brightness curve type through sysfs > > > > backlight: pwm_bl: Set scale type for CIE 1931 curves > > > > backlight: pwm_bl: Set scale type for brightness curves specified in > > > > the DT > > > > > > > > .../ABI/testing/sysfs-class-backlight | 26 ++++++++++++++ > > > > MAINTAINERS | 2 ++ > > > > drivers/video/backlight/backlight.c | 19 ++++++++++ > > > > drivers/video/backlight/pwm_bl.c | 35 ++++++++++++++++++- > > > > include/linux/backlight.h | 8 +++++ > > > > 5 files changed, 89 insertions(+), 1 deletion(-) > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight > > > > > > ping, any comments on v3? > > > > Looks like PATCH 2/4 still needs seeing to. > > The patch currently doesn't have any comments. > > Do you see any specific things that need improvement? If so, could you > comment on the patch? It needs Daniel T's Ack. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~2019-09-02 9:42 UTC | newest] Thread overview: 74+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-09 19:00 [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs Matthias Kaehlcke 2019-07-09 19:00 ` Matthias Kaehlcke 2019-07-09 19:00 ` [PATCH v3 1/4] MAINTAINERS: Add entry for stable backlight sysfs ABI documentation Matthias Kaehlcke 2019-07-09 19:00 ` Matthias Kaehlcke 2019-09-02 9:41 ` Lee Jones 2019-09-02 9:41 ` Lee Jones 2019-09-02 9:41 ` Lee Jones 2019-07-09 19:00 ` [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Matthias Kaehlcke 2019-07-09 19:00 ` Matthias Kaehlcke 2019-07-09 19:00 ` Matthias Kaehlcke 2019-08-07 20:15 ` Matthias Kaehlcke 2019-08-07 20:15 ` Matthias Kaehlcke 2019-08-16 15:54 ` Daniel Thompson 2019-08-16 15:54 ` Daniel Thompson 2019-08-16 17:53 ` Matthias Kaehlcke 2019-08-16 17:53 ` Matthias Kaehlcke 2019-08-19 10:02 ` Daniel Thompson 2019-08-19 10:02 ` Daniel Thompson 2019-08-19 18:50 ` Matthias Kaehlcke 2019-08-19 18:50 ` Matthias Kaehlcke 2019-08-19 18:50 ` Matthias Kaehlcke 2019-08-20 13:56 ` Daniel Thompson 2019-08-20 13:56 ` Daniel Thompson 2019-08-27 9:44 ` Lee Jones 2019-08-27 9:44 ` Lee Jones 2019-08-29 14:09 ` Daniel Thompson 2019-08-29 14:09 ` Daniel Thompson 2019-08-16 16:51 ` Uwe Kleine-König 2019-08-16 16:51 ` Uwe Kleine-König 2019-08-16 17:51 ` Matthias Kaehlcke 2019-08-16 17:51 ` Matthias Kaehlcke 2019-08-16 19:47 ` Uwe Kleine-König 2019-08-16 19:47 ` Uwe Kleine-König 2019-08-16 19:47 ` Uwe Kleine-König 2019-08-16 21:10 ` Matthias Kaehlcke 2019-08-16 21:10 ` Matthias Kaehlcke 2019-08-19 5:46 ` Uwe Kleine-König 2019-08-19 5:46 ` Uwe Kleine-König 2019-08-19 5:46 ` Uwe Kleine-König 2019-08-19 9:50 ` Daniel Thompson 2019-08-19 9:50 ` Daniel Thompson 2019-08-19 9:50 ` Daniel Thompson 2019-08-19 10:21 ` Uwe Kleine-König 2019-08-19 10:21 ` Uwe Kleine-König 2019-08-19 10:21 ` Uwe Kleine-König 2019-08-19 11:16 ` Daniel Thompson 2019-08-19 11:16 ` Daniel Thompson 2019-08-19 12:29 ` Uwe Kleine-König 2019-08-19 12:29 ` Uwe Kleine-König 2019-08-20 14:49 ` Daniel Vetter 2019-08-20 14:49 ` Daniel Vetter 2019-08-20 14:49 ` Daniel Vetter 2019-08-21 14:16 ` Daniel Thompson 2019-08-21 14:16 ` Daniel Thompson 2019-08-21 14:16 ` Daniel Thompson 2019-09-02 9:41 ` Lee Jones 2019-09-02 9:41 ` Lee Jones 2019-07-09 19:00 ` [PATCH v3 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves Matthias Kaehlcke 2019-07-09 19:00 ` Matthias Kaehlcke 2019-09-02 9:41 ` Lee Jones 2019-09-02 9:41 ` Lee Jones 2019-07-09 19:00 ` [PATCH v3 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT Matthias Kaehlcke 2019-07-09 19:00 ` Matthias Kaehlcke 2019-09-02 9:42 ` Lee Jones 2019-09-02 9:42 ` Lee Jones 2019-07-22 23:59 ` [PATCH v3 0/4] backlight: Expose brightness curve type through sysfs Matthias Kaehlcke 2019-07-22 23:59 ` Matthias Kaehlcke 2019-07-25 11:15 ` Lee Jones 2019-07-25 11:15 ` Lee Jones 2019-07-25 17:17 ` Matthias Kaehlcke 2019-07-25 17:17 ` Matthias Kaehlcke 2019-07-25 17:17 ` Matthias Kaehlcke 2019-08-05 10:37 ` Lee Jones 2019-08-05 10:37 ` Lee Jones
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.