| Message ID | 20200720212502.2.Iab4d2192e4cf50226e0a58d58df7d90ef92713ce@changeid |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | PWM backlight interpolation adjustments | expand |
On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > Some displays need the low end of the curve cropped in order to make > them happy. In that case we still want to have the 0% point, even though > anything between 0% and 5%(example) would be skipped. > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > --- > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > index 5193a72305a2..b24711ddf504 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > /* Fill in the last point, since no line starts here. */ > table[x2] = y2; > > + /* > + * If we don't start at 0 yet we're increasing, assume > + * the dts wanted to crop the low end of the range, so > + * insert a 0 to provide a display off mode. > + */ > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > + table[0] = 0; Isn't that what the enable/disable switch in backlights are for? There's lots of backligh drivers (mostly the firmware variety) where setting the backlight to 0 does not shut it off, it's just the lowest setting. But I've not been involved in the details of these discussions. -Daniel > + > /* > * As we use interpolation lets remove current > * brightness levels table and replace for the > -- > 2.27.0 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Aug 07, 2020 at 10:21:13AM +0200, daniel@ffwll.ch wrote: > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > > Some displays need the low end of the curve cropped in order to make > > them happy. In that case we still want to have the 0% point, even though > > anything between 0% and 5%(example) would be skipped. > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > --- > > > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > index 5193a72305a2..b24711ddf504 100644 > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > > /* Fill in the last point, since no line starts here. */ > > table[x2] = y2; > > > > + /* > > + * If we don't start at 0 yet we're increasing, assume > > + * the dts wanted to crop the low end of the range, so > > + * insert a 0 to provide a display off mode. > > + */ > > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > > + table[0] = 0; > > Isn't that what the enable/disable switch in backlights are for? There's > lots of backligh drivers (mostly the firmware variety) where setting the > backlight to 0 does not shut it off, it's just the lowest setting. > > But I've not been involved in the details of these discussions. It's been a long standing complaint that the backlight drivers are not consistent w.r.t. whether 0 means off or lowest. The most commonly used backlights (ACPI in particular) do not adopt 0 means off but lots of specific drivers do. IMHO what is "right" depends on the display technology. For displays that are essentially black when the backlight is off and become difficult or impossible to read I'm a little dubious about standardizing on zero means off. There are situations when zero means off does make sense however. For example front-lit or transflexive displays are readable when the "backlight" is off and on these displays it would make sense. Daniel.
On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > Some displays need the low end of the curve cropped in order to make > them happy. In that case we still want to have the 0% point, even though > anything between 0% and 5%(example) would be skipped. For backlights it is not defined that 0 means off and, to be honest, 0 means off is actually rather weird for anything except transflexive or front lit reflective displays[1]. There is a problem on several systems that when the backlight slider is reduced to zero you can't see the screen properly to turn it back up. This patch looks like it would make that problem worse by hurting systems with will written device trees. There is some nasty legacy here: some backlight displays that are off at zero and that sucks because userspace doesn't know whether zero is off or lowest possible setting. Nevertheless perhaps a better way to handle this case is for 0 to map to 5% power and for the userspace to turn the backlight on/off as final step in an animated backlight fade out (and one again for a fade in). Daniel. > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > --- > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > index 5193a72305a2..b24711ddf504 100644 > --- a/drivers/video/backlight/pwm_bl.c > +++ b/drivers/video/backlight/pwm_bl.c > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > /* Fill in the last point, since no line starts here. */ > table[x2] = y2; > > + /* > + * If we don't start at 0 yet we're increasing, assume > + * the dts wanted to crop the low end of the range, so > + * insert a 0 to provide a display off mode. > + */ > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > + table[0] = 0; > + > /* > * As we use interpolation lets remove current > * brightness levels table and replace for the > -- > 2.27.0
On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote: > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > > Some displays need the low end of the curve cropped in order to make > > them happy. In that case we still want to have the 0% point, even though > > anything between 0% and 5%(example) would be skipped. > > For backlights it is not defined that 0 means off and, to be honest, 0 > means off is actually rather weird for anything except transflexive > or front lit reflective displays[1]. There is a problem on several > systems that when the backlight slider is reduced to zero you can't > see the screen properly to turn it back up. This patch looks like it > would make that problem worse by hurting systems with will written > device trees. > > There is some nasty legacy here: some backlight displays that are off > at zero and that sucks because userspace doesn't know whether zero is > off or lowest possible setting. > > Nevertheless perhaps a better way to handle this case is for 0 to map to > 5% power and for the userspace to turn the backlight on/off as final > step in an animated backlight fade out (and one again for a fade in). Afaik chromeos encodes "0 means off" somewhere in there stack. We've gotten similar patches for the i915 backlight driver when we started obeying the panel's lower limit in our pwm backlight driver thing that's sometimes used instead of acpi. There's also the problem that with fancy panels with protocol (dsi, edp, ...) shutting of the backlight completely out of the proper power sequence hangs the panel (for some panels at least), so providing a backlight off that doesn't go through the drm modeset sequence isn't always possible. It's a bit a mess indeed :-/ -Daniel > > > Daniel. > > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > --- > > > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > index 5193a72305a2..b24711ddf504 100644 > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > > /* Fill in the last point, since no line starts here. */ > > table[x2] = y2; > > > > + /* > > + * If we don't start at 0 yet we're increasing, assume > > + * the dts wanted to crop the low end of the range, so > > + * insert a 0 to provide a display off mode. > > + */ > > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > > + table[0] = 0; > > + > > /* > > * As we use interpolation lets remove current > > * brightness levels table and replace for the > > -- > > 2.27.0 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote: > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote: > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > > > Some displays need the low end of the curve cropped in order to make > > > them happy. In that case we still want to have the 0% point, even though > > > anything between 0% and 5%(example) would be skipped. > > > > For backlights it is not defined that 0 means off and, to be honest, 0 > > means off is actually rather weird for anything except transflexive > > or front lit reflective displays[1]. There is a problem on several > > systems that when the backlight slider is reduced to zero you can't > > see the screen properly to turn it back up. This patch looks like it > > would make that problem worse by hurting systems with will written > > device trees. > > > > There is some nasty legacy here: some backlight displays that are off > > at zero and that sucks because userspace doesn't know whether zero is > > off or lowest possible setting. > > > > Nevertheless perhaps a better way to handle this case is for 0 to map to > > 5% power and for the userspace to turn the backlight on/off as final > > step in an animated backlight fade out (and one again for a fade in). > > Afaik chromeos encodes "0 means off" somewhere in there stack. We've > gotten similar patches for the i915 backlight driver when we started > obeying the panel's lower limit in our pwm backlight driver thing that's > sometimes used instead of acpi. Out of interest... were they accepted? I did took a quick look at intel_panel.c and didn't see anything that appeared to be special casing zero but I thought I might double check. Daniel. > There's also the problem that with fancy panels with protocol (dsi, edp, > ...) shutting of the backlight completely out of the proper power sequence > hangs the panel (for some panels at least), so providing a backlight off > that doesn't go through the drm modeset sequence isn't always possible. > > It's a bit a mess indeed :-/ > -Daniel > > > > > > > Daniel. > > > > > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > > --- > > > > > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > > index 5193a72305a2..b24711ddf504 100644 > > > --- a/drivers/video/backlight/pwm_bl.c > > > +++ b/drivers/video/backlight/pwm_bl.c > > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > > > /* Fill in the last point, since no line starts here. */ > > > table[x2] = y2; > > > > > > + /* > > > + * If we don't start at 0 yet we're increasing, assume > > > + * the dts wanted to crop the low end of the range, so > > > + * insert a 0 to provide a display off mode. > > > + */ > > > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > > > + table[0] = 0; > > > + > > > /* > > > * As we use interpolation lets remove current > > > * brightness levels table and replace for the > > > -- > > > 2.27.0 > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
On Wed, Sep 9, 2020 at 4:45 PM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote: > > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote: > > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > > > > Some displays need the low end of the curve cropped in order to make > > > > them happy. In that case we still want to have the 0% point, even though > > > > anything between 0% and 5%(example) would be skipped. > > > > > > For backlights it is not defined that 0 means off and, to be honest, 0 > > > means off is actually rather weird for anything except transflexive > > > or front lit reflective displays[1]. There is a problem on several > > > systems that when the backlight slider is reduced to zero you can't > > > see the screen properly to turn it back up. This patch looks like it > > > would make that problem worse by hurting systems with will written > > > device trees. > > > > > > There is some nasty legacy here: some backlight displays that are off > > > at zero and that sucks because userspace doesn't know whether zero is > > > off or lowest possible setting. > > > > > > Nevertheless perhaps a better way to handle this case is for 0 to map to > > > 5% power and for the userspace to turn the backlight on/off as final > > > step in an animated backlight fade out (and one again for a fade in). > > > > Afaik chromeos encodes "0 means off" somewhere in there stack. We've > > gotten similar patches for the i915 backlight driver when we started > > obeying the panel's lower limit in our pwm backlight driver thing that's > > sometimes used instead of acpi. > > Out of interest... were they accepted? > > I did took a quick look at intel_panel.c and didn't see anything > that appeared to be special casing zero but I thought I might double > check. I don't think so. Just figured I bring this up since it might explain why this is coming back again from an @chromium.com address. -Daniel > > > Daniel. > > > > There's also the problem that with fancy panels with protocol (dsi, edp, > > ...) shutting of the backlight completely out of the proper power sequence > > hangs the panel (for some panels at least), so providing a backlight off > > that doesn't go through the drm modeset sequence isn't always possible. > > > > It's a bit a mess indeed :-/ > > -Daniel > > > > > > > > > > > Daniel. > > > > > > > > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > > > --- > > > > > > > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > > > index 5193a72305a2..b24711ddf504 100644 > > > > --- a/drivers/video/backlight/pwm_bl.c > > > > +++ b/drivers/video/backlight/pwm_bl.c > > > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > > > > /* Fill in the last point, since no line starts here. */ > > > > table[x2] = y2; > > > > > > > > + /* > > > > + * If we don't start at 0 yet we're increasing, assume > > > > + * the dts wanted to crop the low end of the range, so > > > > + * insert a 0 to provide a display off mode. > > > > + */ > > > > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > > > > + table[0] = 0; > > > > + > > > > /* > > > > * As we use interpolation lets remove current > > > > * brightness levels table and replace for the > > > > -- > > > > 2.27.0 > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Sep 4, 2020 at 4:38 AM Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > > Some displays need the low end of the curve cropped in order to make > > them happy. In that case we still want to have the 0% point, even though > > anything between 0% and 5%(example) would be skipped. > > For backlights it is not defined that 0 means off and, to be honest, 0 > means off is actually rather weird for anything except transflexive > or front lit reflective displays[1]. There is a problem on several > systems that when the backlight slider is reduced to zero you can't > see the screen properly to turn it back up. This patch looks like it > would make that problem worse by hurting systems with will written > device trees. > > There is some nasty legacy here: some backlight displays that are off > at zero and that sucks because userspace doesn't know whether zero is > off or lowest possible setting. > > Nevertheless perhaps a better way to handle this case is for 0 to map to > 5% power and for the userspace to turn the backlight on/off as final > step in an animated backlight fade out (and one again for a fade in). Hello Apologies for my delay. Thanks for the responses! Yeah, I felt pretty sketchy about this 0% patch as well. But I figured it's better to send my suggestion and get corrected than lose the fixed interpolation patch. Turns out there's no reason to need 2/3. I was mistaken: echo "4" > /sys/devices/platform/backlight/backlight/backlight/bl_power seems to work just fine to turn the backlight off, nothing special about my device (pwm comes from cros_ec). Chrome OS user space already makes full use of that knob (https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/platform2/power_manager/powerd/system/internal_backlight.cc;l=169) I wanted to try X11 on the same device but I haven't gotten to it yet, perhaps I'll post my results in the next cover letter. So it seems I didn't have to worry about "not breaking userspace" on the existing devices. I'll respin this patch set: keep 1/3 and 3/3, remove 2/3, and potentially add another one to update trogdor's dtsi (since that's where I want this fixed linear interpolation to happen). Thank you, Alexandru Stan
On Wed, Sep 09, 2020 at 05:03:37PM +0200, Daniel Vetter wrote: > On Wed, Sep 9, 2020 at 4:45 PM Daniel Thompson > <daniel.thompson@linaro.org> wrote: > > > > On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote: > > > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote: > > > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote: > > > > > Some displays need the low end of the curve cropped in order to make > > > > > them happy. In that case we still want to have the 0% point, even though > > > > > anything between 0% and 5%(example) would be skipped. > > > > > > > > For backlights it is not defined that 0 means off and, to be honest, 0 > > > > means off is actually rather weird for anything except transflexive > > > > or front lit reflective displays[1]. There is a problem on several > > > > systems that when the backlight slider is reduced to zero you can't > > > > see the screen properly to turn it back up. This patch looks like it > > > > would make that problem worse by hurting systems with will written > > > > device trees. > > > > > > > > There is some nasty legacy here: some backlight displays that are off > > > > at zero and that sucks because userspace doesn't know whether zero is > > > > off or lowest possible setting. > > > > > > > > Nevertheless perhaps a better way to handle this case is for 0 to map to > > > > 5% power and for the userspace to turn the backlight on/off as final > > > > step in an animated backlight fade out (and one again for a fade in). > > > > > > Afaik chromeos encodes "0 means off" somewhere in there stack. We've > > > gotten similar patches for the i915 backlight driver when we started > > > obeying the panel's lower limit in our pwm backlight driver thing that's > > > sometimes used instead of acpi. > > > > Out of interest... were they accepted? > > > > I did took a quick look at intel_panel.c and didn't see anything > > that appeared to be special casing zero but I thought I might double > > check. > > I don't think so. Just figured I bring this up since it might explain > why this is coming back again from an @chromium.com address. Thanks to Alexandru pointing at the right code it's clear this got fix, over 5 years ago: https://source.chromium.org/chromiumos/_/chromium/chromiumos/platform2/+/6e83a6a8bb772ed8a2f939da1c7a152147c12789 power: Write to bl_power when backlight reaches or leaves 0. Make InternalBacklight write FB_BLANK_UNBLANK to bl_power just before setting the internal backlight brightness to a nonzero value, and FB_BLANK_POWERDOWN to bl_power just before setting the brightness to 0. This is needed for hardware that interprets a brightness level of 0 as meaning "dim" rather than "off". BUG=chromium:396218 TEST=added unit tests Change-Id: I914e333ab41db623564d5a67beac89f1a62bce9d Reviewed-on: https://chromium-review.googlesource.com/311010 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Dan Erat <derat@chromium.org> Cheers, Daniel > > > There's also the problem that with fancy panels with protocol (dsi, edp, > > > ...) shutting of the backlight completely out of the proper power sequence > > > hangs the panel (for some panels at least), so providing a backlight off > > > that doesn't go through the drm modeset sequence isn't always possible. > > > > > > It's a bit a mess indeed :-/ > > > -Daniel > > > > > > > > > > > > > > > Daniel. > > > > > > > > > > > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org> > > > > > --- > > > > > > > > > > drivers/video/backlight/pwm_bl.c | 8 ++++++++ > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c > > > > > index 5193a72305a2..b24711ddf504 100644 > > > > > --- a/drivers/video/backlight/pwm_bl.c > > > > > +++ b/drivers/video/backlight/pwm_bl.c > > > > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, > > > > > /* Fill in the last point, since no line starts here. */ > > > > > table[x2] = y2; > > > > > > > > > > + /* > > > > > + * If we don't start at 0 yet we're increasing, assume > > > > > + * the dts wanted to crop the low end of the range, so > > > > > + * insert a 0 to provide a display off mode. > > > > > + */ > > > > > + if (table[0] > 0 && table[0] < table[num_levels - 1]) > > > > > + table[0] = 0; > > > > > + > > > > > /* > > > > > * As we use interpolation lets remove current > > > > > * brightness levels table and replace for the > > > > > -- > > > > > 2.27.0 > > > > _______________________________________________ > > > > dri-devel mailing list > > > > dri-devel@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index 5193a72305a2..b24711ddf504 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev, /* Fill in the last point, since no line starts here. */ table[x2] = y2; + /* + * If we don't start at 0 yet we're increasing, assume + * the dts wanted to crop the low end of the range, so + * insert a 0 to provide a display off mode. + */ + if (table[0] > 0 && table[0] < table[num_levels - 1]) + table[0] = 0; + /* * As we use interpolation lets remove current * brightness levels table and replace for the
Some displays need the low end of the curve cropped in order to make them happy. In that case we still want to have the 0% point, even though anything between 0% and 5%(example) would be skipped. Signed-off-by: Alexandru Stan <amstan@chromium.org> --- drivers/video/backlight/pwm_bl.c | 8 ++++++++ 1 file changed, 8 insertions(+)