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.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 6FF54C3A59D for ; Mon, 19 Aug 2019 09:50:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3874C20989 for ; Mon, 19 Aug 2019 09:50:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="jWDr4u7K" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727064AbfHSJun (ORCPT ); Mon, 19 Aug 2019 05:50:43 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:38909 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726491AbfHSJum (ORCPT ); Mon, 19 Aug 2019 05:50:42 -0400 Received: by mail-wm1-f68.google.com with SMTP id m125so1026266wmm.3 for ; Mon, 19 Aug 2019 02:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=wICfFLnXhIBKpRL3MkChT8cnTtZKk7MVOyrCJIfR7D4=; b=jWDr4u7KdKLlFacXo7dujEGjOc/1AXUmMpT0Ji/Pdu4LLH2ALWJ8i7wPh/C1iVIbYn bwZnMTvkfCMFE4O3yPzd4bDvO1mXRsSRESmgwtTEetC0GVmNHDe4GX+8vIsFeHZfjLbK jAujLEvOtZxgzNlXLRW8NmUlr0QvI0c7rKtlMg42PU86FWlSxy0epJzqjrqiSupx2Z4w ZNP1BvKM2hnEZXgCYNgLKtW1CdFKQ49JTia96GIE6vT1jKxOdQ4NaKCpgArrzD2rZ3qV q4p6uw1juHGyc8DfyirFfCO0V/w4034IBfD/1/m/bAB1mZlnjXSBY+3d2Xdza74dTIRi 4sNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=wICfFLnXhIBKpRL3MkChT8cnTtZKk7MVOyrCJIfR7D4=; b=iJxaoGf9RifnyLwfKRLrz6ohJtG0zeIN8trh+eWU5OImTnJV/nsQ2GCozx1X8e4gIA ygTx0MW7AmcHcaLgvjSAAmKHVs1rqfShJvDUJxTTj9dcA6d4BZt2wRCzu7JcSeprplKw N57s6fWPwcJsmg0QgXTNFYApr94Ec8XsY2ZOFgmAS2QRBWQ4Bp+pHFrafwCaAZGQU6Kt Miy41jsZwZpwwILAR9t8DqsplzhNHTFhmSuyqeXST5YGFDdsswnlnYzdsm9wOIT6J1LD fJ0fb6skpSOCH0Kb8+CTEZ+TVx8YZf8tkup4yZDAFDNrJ+4Rm8pbb6OasapO7cyo0h5t a2GA== X-Gm-Message-State: APjAAAXT4A0prcOW/57VaTtTFyoSy24v0xNKG3xkT82OHz+uga+Lxw6y zZMFJGGvkzJmOWz6Jk3wrWpNOQ== X-Google-Smtp-Source: APXvYqzo8MEEXCCxdKSZfzaFQthu5ElI1s13ZbbnpzjLTOaUkTmyi8JDnWb7nZOqVe1cES2YKuJZjA== X-Received: by 2002:a1c:630b:: with SMTP id x11mr19227174wmb.135.1566208239870; Mon, 19 Aug 2019 02:50:39 -0700 (PDT) Received: from holly.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id f13sm4491631wrr.5.2019.08.19.02.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2019 02:50:39 -0700 (PDT) Date: Mon, 19 Aug 2019 10:50:37 +0100 From: Daniel Thompson To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= Cc: Matthias Kaehlcke , Thierry Reding , Lee Jones , 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: <20190819095037.h3gig3quyhnzshm7@holly.lan> 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> <20190819054628.asw3cxp46w3rpml7@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190819054628.asw3cxp46w3rpml7@pengutronix.de> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > > > > > > > > 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Thompson Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Date: Mon, 19 Aug 2019 10:50:37 +0100 Message-ID: <20190819095037.h3gig3quyhnzshm7@holly.lan> 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> <20190819054628.asw3cxp46w3rpml7@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20190819054628.asw3cxp46w3rpml7@pengutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= Cc: linux-pwm@vger.kernel.org, linux-fbdev@vger.kernel.org, kernel@pengutronix.de, Bartlomiej Zolnierkiewicz , Jingoo Han , Brian Norris , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Douglas Anderson , Matthias Kaehlcke , Thierry Reding , Jacek Anaszewski , Pavel Machek , Enric Balletbo i Serra , Lee Jones List-Id: linux-pwm@vger.kernel.org T24gTW9uLCBBdWcgMTksIDIwMTkgYXQgMDc6NDY6MjhBTSArMDIwMCwgVXdlIEtsZWluZS1Lw7Zu aWcgd3JvdGU6Cj4gSGVsbG8gTWF0dGhpYXMsCj4gCj4gT24gRnJpLCBBdWcgMTYsIDIwMTkgYXQg MDI6MTA6NTFQTSAtMDcwMCwgTWF0dGhpYXMgS2FlaGxja2Ugd3JvdGU6Cj4gPiBPbiBGcmksIEF1 ZyAxNiwgMjAxOSBhdCAwOTo0Nzo1NFBNICswMjAwLCBVd2UgS2xlaW5lLUvDtm5pZyB3cm90ZToK PiA+ID4gT24gRnJpLCBBdWcgMTYsIDIwMTkgYXQgMTA6NTE6NTdBTSAtMDcwMCwgTWF0dGhpYXMg S2FlaGxja2Ugd3JvdGU6Cj4gPiA+ID4gSGkgVXdlLAo+ID4gPiA+IAo+ID4gPiA+IE9uIEZyaSwg QXVnIDE2LCAyMDE5IGF0IDA2OjUxOjQ4UE0gKzAyMDAsIFV3ZSBLbGVpbmUtS8O2bmlnIHdyb3Rl Ogo+ID4gPiA+ID4gT24gVHVlLCBKdWwgMDksIDIwMTkgYXQgMTI6MDA6MDVQTSAtMDcwMCwgTWF0 dGhpYXMgS2FlaGxja2Ugd3JvdGU6Cj4gPiA+ID4gPiA+IEJhY2tsaWdodCBicmlnaHRuZXNzIGN1 cnZlcyBjYW4gaGF2ZSBkaWZmZXJlbnQgc2hhcGVzLiBUaGUgdHdvIG1haW4KPiA+ID4gPiA+ID4g dHlwZXMgYXJlIGxpbmVhciBhbmQgbm9uLWxpbmVhciBjdXJ2ZXMuIFRoZSBodW1hbiBleWUgZG9l c24ndAo+ID4gPiA+ID4gPiBwZXJjZWl2ZSBsaW5lYXJseSBpbmNyZWFzaW5nL2RlY3JlYXNpbmcg YnJpZ2h0bmVzcyBhcyBsaW5lYXIgKHNlZQo+ID4gPiA+ID4gPiBhbHNvIDg4YmE5NWJlZGI3OSAi YmFja2xpZ2h0OiBwd21fYmw6IENvbXB1dGUgYnJpZ2h0bmVzcyBvZiBMRUQKPiA+ID4gPiA+ID4g bGluZWFybHkgdG8gaHVtYW4gZXllIiksIGhlbmNlIG1hbnkgYmFja2xpZ2h0cyB1c2Ugbm9uLWxp bmVhciAob2Z0ZW4KPiA+ID4gPiA+ID4gbG9nYXJpdGhtaWMpIGJyaWdodG5lc3MgY3VydmVzLiBU aGUgdHlwZSBvZiBjdXJ2ZSBjdXJyZW50bHkgaXMgb3BhcXVlCj4gPiA+ID4gPiA+IHRvIHVzZXJz cGFjZSwgc28gdXNlcnNwYWNlIG9mdGVuIHVzZXMgbW9yZSBvciBsZXNzIHJlbGlhYmxlIGhldXJp c3RpY3MKPiA+ID4gPiA+ID4gKGxpa2UgdGhlIG51bWJlciBvZiBicmlnaHRuZXNzIGxldmVscykg dG8gZGVjaWRlIHdoZXRoZXIgdG8gdHJlYXQgYQo+ID4gPiA+ID4gPiBiYWNrbGlnaHQgZGV2aWNl IGFzIGxpbmVhciBvciBub24tbGluZWFyLgo+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gRXhwb3J0 IHRoZSB0eXBlIG9mIHRoZSBicmlnaHRuZXNzIGN1cnZlIHZpYSB0aGUgbmV3IHN5c2ZzIGF0dHJp YnV0ZQo+ID4gPiA+ID4gPiAnc2NhbGUnLiBUaGUgdmFsdWUgb2YgdGhlIGF0dHJpYnV0ZSBjYW4g YmUgJ2xpbmVhcicsICdub24tbGluZWFyJyBvcgo+ID4gPiA+ID4gPiAndW5rbm93bicuIEZvciBk ZXZpY2VzIHRoYXQgZG9uJ3QgcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc2NhbGUKPiA+ ID4gPiA+ID4gb2YgdGhlaXIgYnJpZ2h0bmVzcyBjdXJ2ZSB0aGUgdmFsdWUgb2YgdGhlICdzY2Fs ZScgYXR0cmlidXRlIGlzICd1bmtub3duJy4KPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+IFNpZ25l ZC1vZmYtYnk6IE1hdHRoaWFzIEthZWhsY2tlIDxta2FAY2hyb21pdW0ub3JnPgo+ID4gPiA+ID4g Cj4gPiA+ID4gPiBJIHdvbmRlciB3aGF0IGtpbmQgb2YgcHJvYmxlbSB5b3UgYXJlIHNvbHZpbmcg aGVyZS4gQ2FuIHlvdSBkZXNjcmliZQo+ID4gPiA+ID4gdGhhdCBpbiBhIGZldyB3b3Jkcz8KPiA+ ID4gPiAKPiA+ID4gPiBUaGUgaHVtYW4gZXllIHBlcmNlaXZlcyBicmlnaHRuZXNzIGluIGEgbG9n YXJpdGhtaWMgbWFubmVyLiBGb3IKPiA+ID4gPiBiYWNrbGlnaHRzIHdpdGggYSBsaW5lYXIgYnJp Z2h0bmVzcyBjdXJ2ZSBicmlnaHRuZXNzIGNvbnRyb2xzIGxpa2UKPiA+ID4gPiBzbGlkZXJzIG5l ZWQgdG8gdXNlIGEgbWFwcGluZyB0byBhY2hpZXZlIGEgYmVoYXZpb3IgdGhhdCBpcyBwZXJjZWl2 ZWQKPiA+ID4gPiBhcyBsaW5lYXItaXNoIChtb3JlIGRldGFpbHM6IGh0dHA6Ly93d3cucGF0aHdh eWxpZ2h0aW5nLmNvbS9wcm9kdWN0cy9kb3dubG9hZHMvYnJvY2h1cmUvdGVjaG5pY2FsX21hdGVy aWFsc18xNDY2Nzk3MDQ0X0xpbmVhcit2cytMb2dhcml0aG1pYytEaW1taW5nK1doaXRlK1BhcGVy LnBkZikKPiA+ID4gPiAKPiA+ID4gPiBBcyBvZiBub3cgdXNlcnNwYWNlIGRvZXNuJ3QgaGF2ZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgdHlwZSBvZiB0aGUKPiA+ID4gPiBicmlnaHRuZXNzIGN1cnZl LCBhbmQgb2Z0ZW4gdXNlcyBoZXVyaXN0aWNzIHRvIG1ha2UgYSBndWVzcywgd2hpY2ggbWF5Cj4g PiA+ID4gYmUgcmlnaHQgbW9zdCBvZiB0aGUgdGltZSwgYnV0IG5vdCBhbHdheXMuIFRoZSBuZXcg YXR0cmlidXRlIGVsaW1pbmF0ZXMKPiA+ID4gPiB0aGUgbmVlZCB0byBndWVzcy4KPiA+ID4gCj4g PiA+IFRoaXMgaXMgYWJvdXQgYmFja2xpZ2h0cyByaWdodD8gU28gdGhlIGtlcm5lbCBwcm92aWRl cyB0byB1c2Vyc3BhY2UgYW4KPiA+ID4gaW50ZXJ2YWwgWzAsIHhdIGZvciBzb21lIHggYW5kIGRl cGVuZGluZyBvbiB0aGUgcGh5c2ljcyBvZiB0aGUgdGhlCj4gPiA+IGJhY2tsaWdodCBjb25maWd1 cmluZyB4LzIgKHByb2JhYmx5PykgZWl0aGVyIG1lYW5zIDUwJSBtZWFzdXJlZCBsaWdodCBvcgo+ ID4gPiA1MCUgcGVyY2VpdmVkIGxpZ2h0LCByaWdodD8KPiA+IAo+ID4gY29ycmVjdAo+ID4gCj4g PiA+IEkgd29uZGVyIGlmIGl0IHdvdWxkIGJlIHBvc3NpYmxlIGluc3RlYWQgb2YgZ2l2aW5nIGRp ZmZlcmVudCBiYWNrbGlnaHQKPiA+ID4gaW1wbGVtZW50YXRpb25zIHRoZSBmcmVlZG9tIHRvIHVz ZSBlaXRoZXIgbGluZWFyIG9yIGxvZ2FyaXRobWljIChvcgo+ID4gPiBxdWFkcmF0aWM/KSBzY2Fs aW5nIGFuZCB0ZWxsIHVzZXJzcGFjZSB3aGljaCBvZiB0aGUgb3B0aW9ucyB3ZXJlIHBpY2tlZAo+ ID4gPiByZXF1aXJlIHRoZSBkcml2ZXJzIHRvIHByb3ZpZGUgYSAoc2F5KSBsaW5lYXIgc2NhbGlu ZyBhbmQgdGhlbiB1c2Vyc3BhY2UKPiA+ID4gd291bGRuJ3QgbmVlZCB0byBjYXJlIGFib3V0IHRo ZSBleGFjdCBwaHlzaWNzLgo+ID4gCj4gPiBJbiBhbiBpZGVhbCB3b3JsZCB0aGUgYmFja2xpZ2h0 IGludGVyZmFjZSB3b3VsZCBiZSBjb25zaXN0ZW50IGFzIHlvdQo+ID4gc3VnZ2VzdCwgaG93ZXZl ciB0aGVyZSBhcmUgcGxlbnR5IG9mIGV4aXN0aW5nIGRldmljZXMgd2hpY2ggdXNlIHRoZQo+ID4g J290aGVyJyBzY2FsaW5nIChyZWdhcmRsZXNzIG9mIHdoaWNoIGlzIGNob3NlbiBhcyB0aGUgJ2Nv cnJlY3QnCj4gPiBvbmUpLiBVc2Vyc3BhY2Ugc3RpbGwgaGFzIHRvIGRlYWwgd2l0aCB0aGVzZS4g QW5kIGNoYW5naW5nIHByZXZpb3VzbHkKPiA+ICdsb2dhcml0aG1pYycgZHJpdmVycyB0byBsaW5l YXIgKG9yIHZpY2V2ZXJzYSkgbWF5ICdicmVhaycgdXNlcnNwYWNlLAo+ID4gd2hlbiBpdCBrZWVw cyB1c2luZyBpdHMgJ29sZCcgc2NhbGluZywgd2hpY2ggbm93IGlzbid0IGNvcnJlY3QgYW55bW9y ZS4KPiAKPiBJdCBtaWdodCBiZSBzdWJqZWN0aXZlLCBvciBtYXliZSBJJ20ganVzdCB0b28gb3B0 aW1pc3RpYywgYnV0IEkgdGhpbmsgaWYKPiB0aGVyZSB3YXMgbm8gcG9saWN5IGJlZm9yZSBhYm91 dCB0aGUgbWVhbmluZyBvZgo+IAo+IAllY2hvIDE3ID4gYnJpZ2h0bmVzcwo+IAo+IG90aGVyIHRo YW4gImJyaWdodGVyIHRoYW4gbG93ZXIgdmFsdWVzIGFuZCBkYXJrZXIgdGhhbiBoaWdoZXIgb25l cyIKPiBpbnRyb2R1Y2luZyAoc2F5KSB0aGUgc2NhbGUgaXMgaW50ZW5kZWQgdG8gcmVwcmVzZW50 IGEgbGluZWFyIGJyaWdodG5lc3MKPiBjdXJ2ZSBpcyBvay4KPiAKPiBVbmxlc3MgdXNlcnNwYWNl IGp1bXBzIHRocm91Z2ggaG9vcHMgYW5kIHRyaWVzIHRvIGlkZW50aWZ5IHRoZSBhY3R1YWwKPiBk ZXZpY2UgaXQgaXMgcnVubmluZyBvbiBpdCBpcyB3cm9uZyBvbiBzb21lIG1hY2hpbmVzIGFueWhv dyBhbmQgd2UncmUKPiBvbmx5IHNoaWZ0aW5nIHRoZSBzZXQgb2YgYWZmZWN0ZWQgbWFjaGluZXMg d2l0aCBhIHRpZ2h0ZXIgcG9saWN5ICh1bnRpbAo+IHRoYXQgdXNlcnNwYWNlIGFwcGxpY2F0aW9u IGlzIGZpeGVkKS4KCkkgYmVsaWV2ZSB0aGF0IHRoZXJlIGFyZSB0d28gY29tbW9uIGFwcHJvYWNo ZXMgYnkgdXNlcnNwYWNlIGF0IHByZXNlbnQ6CgoxLiBBc3N1bWUgdGhlIHNjYWxlIGlzIHBlcmNl cHR1YWwgYW5kIHdlIGNhbiBkaXJlY3RseSBtYXAgYSBzbGlkZXIKICAgdG8gdGhlIGJhY2tsaWdo dCB2YWx1ZS4gVGhpcyBpcyBjb21tb24gc2ltcGx5IGJlY2F1c2UgbW9zdCBBQ1BJCiAgIGJhY2ts aWdodHMgYXJlIHBlcmNlcHR1YWwgYW5kIHRoZXJlZm9yZSB3aGVuIHRlc3RlZCBpbiBhIGxhcHRv cAogICBpdCB3b3JrcyBPSy4KCjIuIEFzc3VtZSB0aGF0IGlzIG1heCBicmlnaHRuZXNzIGlzIHNt YWxsIChlLmcuIEFDUEkpIHRoZW4gdGhlCiAgIHNjYWxlIGlzIHBlcmNlcHR1YWwgYW5kIGlmIHRo ZSBtYXggYnJpZ2h0bmVzcyBpcyBsYXJnZSAoZS5nLgogICBhIFBXTSkgdGhlbiB0aGUgc2NhbGUg aXMgbGluZWFyIGFuZCBhcHBseSBhIGNvcnJlY3Rpb24KICAgZnVuY3Rpb24gYmV0d2VlbiB0aGUg c2xpZGVyIGFuZCB0aGUgY29udHJvbC4KClRoYXQgaGlzdG9yaWMgYmFnZ2FnZSBtYWtlcyBpcyBk aWZmY3VsdCB0byAianVzdCBkZWZpbmUgYSBzdGFuZGFyZGl6ZWQKc2NhbGUiLi4uIGVzcGVjaWFs bHkgZ2l2ZW4gdGhhdCBpZiB3ZSBzZWxlY3RlZCBhIHN0YW5kYXJkaXplZCBzY2FsZSB3ZQp3b3Vs ZCBwcm9iYWJseSB3YW50IGEgcGVyY2VwdHVhbCBzY2FsZSB3aXRoIGxvdHMgb2Ygc3RlcHMgKGUu Zy4gYnJlYWsKdGhlIGhldXJpc3RpYykuCgoKPiBBbmQgdGhlIGJpZyB1cHNpZGUgaXMgdGhhdCBp biB0aGUgZW5kIChpLmUuIHdoZW4gYWxsIGtlcm5lbCBkcml2ZXJzIGFuZAo+IHVzZXJzcGFjZSBh cHBsaWNhdGlvbnMgYXJlIGFkYXB0ZWQgdG8gcHJvdmlkZS9jb25zdW1lIHRoZSAiY29ycmVjdCIK PiBjdXJ2ZSkgdGhlIHJlc3VsdCBpcyBzaW1wbGVyLgoKTXkgdmlldyBpcyB0aGF0IHRoaXMgY29u dmVyZ2VuY2Ugd2lsbCBldmVudHVhbGx5IGJlIGFjaGlldmVkIGJ1dCBpdCB3aWxsCmhhcHBlbiB0 aHJvdWdoIHRoZSBvYnNvbGVzY2VuY2Ugb2YgdGhlIGJhY2tsaWdodCBzeXNmcyBpbnRlcmZhY2Uu IFRoZQpzeXNmcyBpbnRlcmZhY2UgaGFzIG90aGVyIGZsYXdzLCBpbiBwYXJ0aWN1bGFyIG5vIGlu dGVncmF0aW9uIHdpdGggdGhlCkRSTSBjb25uZWN0b3IgQVBJLgoKVGh1cyBJIHdvdWxkIGV4cGVj dCBhbiBhbHRlcm5hdGl2ZSBpbnRlcmZhY2UgdG8gZW1lcmdlLCBtb3N0IGxpa2VseSBhcwpwYXJ0 IG9mIHRoZSBEUk0gY29ubmVjdG9yIEFQSS4gSSdkIGV4cGVjdCBzdWNoIGEgbmV3IEFQSSB0byBh CnBlcmNlcHR1YWwgc2NhbGUgYW5kIHRvIGhhdmUgYSBmaXhlZCBtYXggYnJpZ2h0bmVzcyB3aXRo IGVub3VnaApzdGVwcyB0byBzdXBwb3J0IGFuaW1hdGVkIGJhY2tsaWdodCBlZmZlY3RzIChJSVJD IDAuLjEwMCBoYXMgYmVlbgpwcm9wb3NlZCBpbiB0aGUgcGFzdCkgCgpJbiB0aGUgbWVhbiB0aW1l IGdldHRpbmcgdGhlIGV4aXN0aW5nIGNvbGxlY3Rpb24gb2YgYmFja2xpZ2h0IGRyaXZlcnMKbWFy a2VkIHVwIGFzIGxpbmVhci9sb2dhcml0aG1pYy9ldGMgd2lsbCBlYXNlIHRoZSBpbnRyb2R1Y3Rp b24gb2YgdGhhdApBUEkgYmVjYXVzZSwgd2l0aGluIHRoZSBrZXJuZWwsIHdlIG1pZ2h0IGhhdmUg Z2F0aGVyZWQgZW5vdWdoIGtub3dsZWRnZQp0byBoYXZlIHNvbWUgaG9wZSBvZiBjb3JyZWN0bHkg bWFwcGluZyBlYWNoIGJhY2tsaWdodCBvbnRvIGEKc3RhbmRhcmRpemVkIHNjYWxlLgoKCkRhbmll bC4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRl dmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8v bGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Thompson Date: Mon, 19 Aug 2019 09:50:37 +0000 Subject: Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs Message-Id: <20190819095037.h3gig3quyhnzshm7@holly.lan> 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> <20190819054628.asw3cxp46w3rpml7@pengutronix.de> In-Reply-To: <20190819054628.asw3cxp46w3rpml7@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= Cc: linux-pwm@vger.kernel.org, linux-fbdev@vger.kernel.org, kernel@pengutronix.de, Bartlomiej Zolnierkiewicz , Jingoo Han , Brian Norris , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, 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=F6nig wrote: > Hello Matthias, >=20 > 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=F6nig wrote: > > > On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote: > > > > Hi Uwe, > > > >=20 > > > > On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-K=F6nig 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 (s= ee > > > > > > 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 heu= ristics > > > > > > (like the number of brightness levels) to decide whether to tre= at a > > > > > > backlight device as linear or non-linear. > > > > > >=20 > > > > > > Export the type of the brightness curve via the new sysfs attri= bute > > > > > > 'scale'. The value of the attribute can be 'linear', 'non-linea= r' or > > > > > > 'unknown'. For devices that don't provide information about the= scale > > > > > > of their brightness curve the value of the 'scale' attribute is= 'unknown'. > > > > > >=20 > > > > > > Signed-off-by: Matthias Kaehlcke > > > > >=20 > > > > > I wonder what kind of problem you are solving here. Can you descr= ibe > > > > > that in a few words? > > > >=20 > > > > 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 perceiv= ed > > > > as linear-ish (more details: http://www.pathwaylighting.com/product= s/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+D= imming+White+Paper.pdf) > > > >=20 > > > > 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 elimin= ates > > > > the need to guess. > > >=20 > > > 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? > >=20 > > correct > >=20 > > > 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 pick= ed > > > require the drivers to provide a (say) linear scaling and then usersp= ace > > > wouldn't need to care about the exact physics. > >=20 > > 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. >=20 > It might be subjective, or maybe I'm just too optimistic, but I think if > there was no policy before about the meaning of >=20 > echo 17 > brightness >=20 > 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. >=20 > 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)=20 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.