All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Matthias Kaehlcke <mka@chromium.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-pwm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Douglas Anderson <dianders@chromium.org>,
	Brian Norris <briannorris@chromium.org>,
	Pavel Machek <pavel@ucw.cz>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	kernel@pengutronix.de
Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
Date: Mon, 19 Aug 2019 14:29:15 +0200	[thread overview]
Message-ID: <20190819122915.icjszuvnwyjpa75n@pengutronix.de> (raw)
In-Reply-To: <20190819111613.2kkn25tmjgyjhbip@holly.lan>

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/  |

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Matthias Kaehlcke <mka@chromium.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-pwm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Douglas Anderson <dianders@chromium.org>,
	Brian Norris <briannorris@chromium.org>,
	Pavel Machek <pavel@ucw.cz>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	kernel@pengutronix.de
Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs
Date: Mon, 19 Aug 2019 12:29:15 +0000	[thread overview]
Message-ID: <20190819122915.icjszuvnwyjpa75n@pengutronix.de> (raw)
In-Reply-To: <20190819111613.2kkn25tmjgyjhbip@holly.lan>

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/  |

  reply	other threads:[~2019-08-19 12:29 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190819122915.icjszuvnwyjpa75n@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=b.zolnierkie@samsung.com \
    --cc=briannorris@chromium.org \
    --cc=daniel.thompson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=enric.balletbo@collabora.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=jingoohan1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=pavel@ucw.cz \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.