From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B907C3A59B for ; Mon, 19 Aug 2019 05:46:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D8D420651 for ; Mon, 19 Aug 2019 05:46:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726571AbfHSFqh (ORCPT ); Mon, 19 Aug 2019 01:46:37 -0400 Received: from metis.ext.pengutronix.de ([85.220.165.71]:42801 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726491AbfHSFqg (ORCPT ); Mon, 19 Aug 2019 01:46:36 -0400 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hzaUx-0002T6-GH; Mon, 19 Aug 2019 07:46:31 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1hzaUu-0004xO-7b; Mon, 19 Aug 2019 07:46:28 +0200 Date: Mon, 19 Aug 2019 07:46:28 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Matthias Kaehlcke Cc: Thierry Reding , Lee Jones , Daniel Thompson , Jingoo Han , Bartlomiej Zolnierkiewicz , linux-pwm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, Enric Balletbo i Serra , Douglas Anderson , Brian Norris , Pavel Machek , Jacek Anaszewski , kernel@pengutronix.de Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Message-ID: <20190819054628.asw3cxp46w3rpml7@pengutronix.de> References: <20190709190007.91260-1-mka@chromium.org> <20190709190007.91260-3-mka@chromium.org> <20190816165148.7keg45fmlndr22fl@pengutronix.de> <20190816175157.GT250418@google.com> <20190816194754.ldzjqy2yjonfvaat@pengutronix.de> <20190816211051.GV250418@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190816211051.GV250418@google.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > > > > > > 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/ | From mboxrd@z Thu Jan 1 00:00:00 1970 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Date: Mon, 19 Aug 2019 07:46:28 +0200 Message-ID: <20190819054628.asw3cxp46w3rpml7@pengutronix.de> References: <20190709190007.91260-1-mka@chromium.org> <20190709190007.91260-3-mka@chromium.org> <20190816165148.7keg45fmlndr22fl@pengutronix.de> <20190816175157.GT250418@google.com> <20190816194754.ldzjqy2yjonfvaat@pengutronix.de> <20190816211051.GV250418@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20190816211051.GV250418@google.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Matthias Kaehlcke Cc: linux-pwm@vger.kernel.org, Daniel Thompson , Douglas Anderson , kernel@pengutronix.de, Bartlomiej Zolnierkiewicz , Jingoo Han , Brian Norris , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Thierry Reding , Jacek Anaszewski , Pavel Machek , Enric Balletbo i Serra , Lee Jones List-Id: linux-pwm@vger.kernel.org SGVsbG8gTWF0dGhpYXMsCgpPbiBGcmksIEF1ZyAxNiwgMjAxOSBhdCAwMjoxMDo1MVBNIC0wNzAw LCBNYXR0aGlhcyBLYWVobGNrZSB3cm90ZToKPiBPbiBGcmksIEF1ZyAxNiwgMjAxOSBhdCAwOTo0 Nzo1NFBNICswMjAwLCBVd2UgS2xlaW5lLUvDtm5pZyB3cm90ZToKPiA+IE9uIEZyaSwgQXVnIDE2 LCAyMDE5IGF0IDEwOjUxOjU3QU0gLTA3MDAsIE1hdHRoaWFzIEthZWhsY2tlIHdyb3RlOgo+ID4g PiBIaSBVd2UsCj4gPiA+IAo+ID4gPiBPbiBGcmksIEF1ZyAxNiwgMjAxOSBhdCAwNjo1MTo0OFBN ICswMjAwLCBVd2UgS2xlaW5lLUvDtm5pZyB3cm90ZToKPiA+ID4gPiBPbiBUdWUsIEp1bCAwOSwg MjAxOSBhdCAxMjowMDowNVBNIC0wNzAwLCBNYXR0aGlhcyBLYWVobGNrZSB3cm90ZToKPiA+ID4g PiA+IEJhY2tsaWdodCBicmlnaHRuZXNzIGN1cnZlcyBjYW4gaGF2ZSBkaWZmZXJlbnQgc2hhcGVz LiBUaGUgdHdvIG1haW4KPiA+ID4gPiA+IHR5cGVzIGFyZSBsaW5lYXIgYW5kIG5vbi1saW5lYXIg Y3VydmVzLiBUaGUgaHVtYW4gZXllIGRvZXNuJ3QKPiA+ID4gPiA+IHBlcmNlaXZlIGxpbmVhcmx5 IGluY3JlYXNpbmcvZGVjcmVhc2luZyBicmlnaHRuZXNzIGFzIGxpbmVhciAoc2VlCj4gPiA+ID4g PiBhbHNvIDg4YmE5NWJlZGI3OSAiYmFja2xpZ2h0OiBwd21fYmw6IENvbXB1dGUgYnJpZ2h0bmVz cyBvZiBMRUQKPiA+ID4gPiA+IGxpbmVhcmx5IHRvIGh1bWFuIGV5ZSIpLCBoZW5jZSBtYW55IGJh Y2tsaWdodHMgdXNlIG5vbi1saW5lYXIgKG9mdGVuCj4gPiA+ID4gPiBsb2dhcml0aG1pYykgYnJp Z2h0bmVzcyBjdXJ2ZXMuIFRoZSB0eXBlIG9mIGN1cnZlIGN1cnJlbnRseSBpcyBvcGFxdWUKPiA+ ID4gPiA+IHRvIHVzZXJzcGFjZSwgc28gdXNlcnNwYWNlIG9mdGVuIHVzZXMgbW9yZSBvciBsZXNz IHJlbGlhYmxlIGhldXJpc3RpY3MKPiA+ID4gPiA+IChsaWtlIHRoZSBudW1iZXIgb2YgYnJpZ2h0 bmVzcyBsZXZlbHMpIHRvIGRlY2lkZSB3aGV0aGVyIHRvIHRyZWF0IGEKPiA+ID4gPiA+IGJhY2ts aWdodCBkZXZpY2UgYXMgbGluZWFyIG9yIG5vbi1saW5lYXIuCj4gPiA+ID4gPiAKPiA+ID4gPiA+ IEV4cG9ydCB0aGUgdHlwZSBvZiB0aGUgYnJpZ2h0bmVzcyBjdXJ2ZSB2aWEgdGhlIG5ldyBzeXNm cyBhdHRyaWJ1dGUKPiA+ID4gPiA+ICdzY2FsZScuIFRoZSB2YWx1ZSBvZiB0aGUgYXR0cmlidXRl IGNhbiBiZSAnbGluZWFyJywgJ25vbi1saW5lYXInIG9yCj4gPiA+ID4gPiAndW5rbm93bicuIEZv ciBkZXZpY2VzIHRoYXQgZG9uJ3QgcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc2NhbGUK PiA+ID4gPiA+IG9mIHRoZWlyIGJyaWdodG5lc3MgY3VydmUgdGhlIHZhbHVlIG9mIHRoZSAnc2Nh bGUnIGF0dHJpYnV0ZSBpcyAndW5rbm93bicuCj4gPiA+ID4gPiAKPiA+ID4gPiA+IFNpZ25lZC1v ZmYtYnk6IE1hdHRoaWFzIEthZWhsY2tlIDxta2FAY2hyb21pdW0ub3JnPgo+ID4gPiA+IAo+ID4g PiA+IEkgd29uZGVyIHdoYXQga2luZCBvZiBwcm9ibGVtIHlvdSBhcmUgc29sdmluZyBoZXJlLiBD YW4geW91IGRlc2NyaWJlCj4gPiA+ID4gdGhhdCBpbiBhIGZldyB3b3Jkcz8KPiA+ID4gCj4gPiA+ IFRoZSBodW1hbiBleWUgcGVyY2VpdmVzIGJyaWdodG5lc3MgaW4gYSBsb2dhcml0aG1pYyBtYW5u ZXIuIEZvcgo+ID4gPiBiYWNrbGlnaHRzIHdpdGggYSBsaW5lYXIgYnJpZ2h0bmVzcyBjdXJ2ZSBi cmlnaHRuZXNzIGNvbnRyb2xzIGxpa2UKPiA+ID4gc2xpZGVycyBuZWVkIHRvIHVzZSBhIG1hcHBp bmcgdG8gYWNoaWV2ZSBhIGJlaGF2aW9yIHRoYXQgaXMgcGVyY2VpdmVkCj4gPiA+IGFzIGxpbmVh ci1pc2ggKG1vcmUgZGV0YWlsczogaHR0cDovL3d3dy5wYXRod2F5bGlnaHRpbmcuY29tL3Byb2R1 Y3RzL2Rvd25sb2Fkcy9icm9jaHVyZS90ZWNobmljYWxfbWF0ZXJpYWxzXzE0NjY3OTcwNDRfTGlu ZWFyK3ZzK0xvZ2FyaXRobWljK0RpbW1pbmcrV2hpdGUrUGFwZXIucGRmKQo+ID4gPiAKPiA+ID4g QXMgb2Ygbm93IHVzZXJzcGFjZSBkb2Vzbid0IGhhdmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHR5 cGUgb2YgdGhlCj4gPiA+IGJyaWdodG5lc3MgY3VydmUsIGFuZCBvZnRlbiB1c2VzIGhldXJpc3Rp Y3MgdG8gbWFrZSBhIGd1ZXNzLCB3aGljaCBtYXkKPiA+ID4gYmUgcmlnaHQgbW9zdCBvZiB0aGUg dGltZSwgYnV0IG5vdCBhbHdheXMuIFRoZSBuZXcgYXR0cmlidXRlIGVsaW1pbmF0ZXMKPiA+ID4g dGhlIG5lZWQgdG8gZ3Vlc3MuCj4gPiAKPiA+IFRoaXMgaXMgYWJvdXQgYmFja2xpZ2h0cyByaWdo dD8gU28gdGhlIGtlcm5lbCBwcm92aWRlcyB0byB1c2Vyc3BhY2UgYW4KPiA+IGludGVydmFsIFsw LCB4XSBmb3Igc29tZSB4IGFuZCBkZXBlbmRpbmcgb24gdGhlIHBoeXNpY3Mgb2YgdGhlIHRoZQo+ ID4gYmFja2xpZ2h0IGNvbmZpZ3VyaW5nIHgvMiAocHJvYmFibHk/KSBlaXRoZXIgbWVhbnMgNTAl IG1lYXN1cmVkIGxpZ2h0IG9yCj4gPiA1MCUgcGVyY2VpdmVkIGxpZ2h0LCByaWdodD8KPiAKPiBj b3JyZWN0Cj4gCj4gPiBJIHdvbmRlciBpZiBpdCB3b3VsZCBiZSBwb3NzaWJsZSBpbnN0ZWFkIG9m IGdpdmluZyBkaWZmZXJlbnQgYmFja2xpZ2h0Cj4gPiBpbXBsZW1lbnRhdGlvbnMgdGhlIGZyZWVk b20gdG8gdXNlIGVpdGhlciBsaW5lYXIgb3IgbG9nYXJpdGhtaWMgKG9yCj4gPiBxdWFkcmF0aWM/ KSBzY2FsaW5nIGFuZCB0ZWxsIHVzZXJzcGFjZSB3aGljaCBvZiB0aGUgb3B0aW9ucyB3ZXJlIHBp Y2tlZAo+ID4gcmVxdWlyZSB0aGUgZHJpdmVycyB0byBwcm92aWRlIGEgKHNheSkgbGluZWFyIHNj YWxpbmcgYW5kIHRoZW4gdXNlcnNwYWNlCj4gPiB3b3VsZG4ndCBuZWVkIHRvIGNhcmUgYWJvdXQg dGhlIGV4YWN0IHBoeXNpY3MuCj4gCj4gSW4gYW4gaWRlYWwgd29ybGQgdGhlIGJhY2tsaWdodCBp bnRlcmZhY2Ugd291bGQgYmUgY29uc2lzdGVudCBhcyB5b3UKPiBzdWdnZXN0LCBob3dldmVyIHRo ZXJlIGFyZSBwbGVudHkgb2YgZXhpc3RpbmcgZGV2aWNlcyB3aGljaCB1c2UgdGhlCj4gJ290aGVy JyBzY2FsaW5nIChyZWdhcmRsZXNzIG9mIHdoaWNoIGlzIGNob3NlbiBhcyB0aGUgJ2NvcnJlY3Qn Cj4gb25lKS4gVXNlcnNwYWNlIHN0aWxsIGhhcyB0byBkZWFsIHdpdGggdGhlc2UuIEFuZCBjaGFu Z2luZyBwcmV2aW91c2x5Cj4gJ2xvZ2FyaXRobWljJyBkcml2ZXJzIHRvIGxpbmVhciAob3Igdmlj ZXZlcnNhKSBtYXkgJ2JyZWFrJyB1c2Vyc3BhY2UsCj4gd2hlbiBpdCBrZWVwcyB1c2luZyBpdHMg J29sZCcgc2NhbGluZywgd2hpY2ggbm93IGlzbid0IGNvcnJlY3QgYW55bW9yZS4KCkl0IG1pZ2h0 IGJlIHN1YmplY3RpdmUsIG9yIG1heWJlIEknbSBqdXN0IHRvbyBvcHRpbWlzdGljLCBidXQgSSB0 aGluayBpZgp0aGVyZSB3YXMgbm8gcG9saWN5IGJlZm9yZSBhYm91dCB0aGUgbWVhbmluZyBvZgoK CWVjaG8gMTcgPiBicmlnaHRuZXNzCgpvdGhlciB0aGFuICJicmlnaHRlciB0aGFuIGxvd2VyIHZh bHVlcyBhbmQgZGFya2VyIHRoYW4gaGlnaGVyIG9uZXMiCmludHJvZHVjaW5nIChzYXkpIHRoZSBz Y2FsZSBpcyBpbnRlbmRlZCB0byByZXByZXNlbnQgYSBsaW5lYXIgYnJpZ2h0bmVzcwpjdXJ2ZSBp cyBvay4KClVubGVzcyB1c2Vyc3BhY2UganVtcHMgdGhyb3VnaCBob29wcyBhbmQgdHJpZXMgdG8g aWRlbnRpZnkgdGhlIGFjdHVhbApkZXZpY2UgaXQgaXMgcnVubmluZyBvbiBpdCBpcyB3cm9uZyBv biBzb21lIG1hY2hpbmVzIGFueWhvdyBhbmQgd2UncmUKb25seSBzaGlmdGluZyB0aGUgc2V0IG9m IGFmZmVjdGVkIG1hY2hpbmVzIHdpdGggYSB0aWdodGVyIHBvbGljeSAodW50aWwKdGhhdCB1c2Vy c3BhY2UgYXBwbGljYXRpb24gaXMgZml4ZWQpLgoKQW5kIHRoZSBiaWcgdXBzaWRlIGlzIHRoYXQg aW4gdGhlIGVuZCAoaS5lLiB3aGVuIGFsbCBrZXJuZWwgZHJpdmVycyBhbmQKdXNlcnNwYWNlIGFw cGxpY2F0aW9ucyBhcmUgYWRhcHRlZCB0byBwcm92aWRlL2NvbnN1bWUgdGhlICJjb3JyZWN0Igpj dXJ2ZSkgdGhlIHJlc3VsdCBpcyBzaW1wbGVyLgoKSnVzdCBteSAwLjAy4oKsClV3ZQoKLS0gClBl bmd1dHJvbml4IGUuSy4gICAgICAgICAgICAgICAgICAgICAgICAgICB8IFV3ZSBLbGVpbmUtS8O2 bmlnICAgICAgICAgICAgfApJbmR1c3RyaWFsIExpbnV4IFNvbHV0aW9ucyAgICAgICAgICAgICAg ICAgfCBodHRwOi8vd3d3LnBlbmd1dHJvbml4LmRlLyAgfApfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZl bEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby9kcmktZGV2ZWw= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Date: Mon, 19 Aug 2019 05:46:28 +0000 Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Message-Id: <20190819054628.asw3cxp46w3rpml7@pengutronix.de> List-Id: References: <20190709190007.91260-1-mka@chromium.org> <20190709190007.91260-3-mka@chromium.org> <20190816165148.7keg45fmlndr22fl@pengutronix.de> <20190816175157.GT250418@google.com> <20190816194754.ldzjqy2yjonfvaat@pengutronix.de> <20190816211051.GV250418@google.com> In-Reply-To: <20190816211051.GV250418@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Matthias Kaehlcke Cc: linux-pwm@vger.kernel.org, Daniel Thompson , Douglas Anderson , kernel@pengutronix.de, Bartlomiej Zolnierkiewicz , Jingoo Han , Brian Norris , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, 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 > > > > > > > > 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/ |