Received: by 10.223.164.202 with SMTP id h10csp529354wrb; Thu, 30 Nov 2017 03:29:10 -0800 (PST) X-Google-Smtp-Source: AGs4zMYqe7GGF0nCfRt26oNex7n+C+SkHFYMFka/epuLGc5mVC00SS0VBammPLl+A4orDjGKATv7 X-Received: by 10.98.112.71 with SMTP id l68mr6353625pfc.11.1512041350620; Thu, 30 Nov 2017 03:29:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512041350; cv=none; d=google.com; s=arc-20160816; b=wkQzjLNbBiOTG9frdwGVFis/vTWcJn1rtu5UNc2U62dB03AG6Eeh9qyrQ6b6r1l6zT MMl5v8NlgPyMXsOswJiTZEA1D29Omm+R9G3twcpCq18kMYPBULp9jt49WMf/EsQnWGX4 +YAYxpm2Cz96sqJyks6KgeRJXixrzKj4Pyk0dkI1/B6HFZkWvee25pvOSy7t1WsJijUR MOtU5s6KtUkiO+GZ25xAoIbWuAu21deYRoZTxed23s0eotSzFcLParmyRwXH4cUd26Qm 0tIL2HYRxxO/2Rph8pw6BX21LRuC1oeRIsIO9e5gJ6kPUspXjiVd2WLwmEFhSEFI/MdJ OFqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=2VKnAMpekgJdh/qUpWgWMGV+rQC469+Yfkep51n3ZB4=; b=I1lyuOCymMS9Dp0/kbH1rtMIqgnHsmDCCrkwo8yc3ayWSjOqocRHMyVPLFdcsw48dh wd8nngSaBf7GpZAJJHvU/UjlYNwnba/Zr6jVnD/s/mssLlfPrARYPJb+qkY/khezYDFQ jYODhYD3jILD8i/YQ77wowr/hQA0f2BocedihMRrmNtRQZehIE1fKph3jmwZvzhCRwRC yVJUbFgkXpg/hnJPFWgbNHTezFq+G8ZOFhjyndH2OHLaVra+VwU7cUxRbGbqSeqZzCYc OwN10OveO/4ZDs6qLHrH93POlyxkmH89sHcKDE2lxABzkFIHmIvYaxrO6PtTD+FBXu2Z 3LIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=R+jq5Z9p; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v13si2825299plk.576.2017.11.30.03.28.56; Thu, 30 Nov 2017 03:29:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=R+jq5Z9p; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752312AbdK3L14 (ORCPT + 99 others); Thu, 30 Nov 2017 06:27:56 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:41788 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbdK3L1x (ORCPT ); Thu, 30 Nov 2017 06:27:53 -0500 Received: by mail-wm0-f42.google.com with SMTP id g75so12494080wme.0 for ; Thu, 30 Nov 2017 03:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2VKnAMpekgJdh/qUpWgWMGV+rQC469+Yfkep51n3ZB4=; b=R+jq5Z9pg2ARF8njSB9LsMsgg4rI/njYuXCcqymHCjTg6krifQqhvg9S+VMIA3h2Xt ITQkch4JTZRC+C95V59Tyqmt4M4M1Lkv7zgPrfyGX7SGRU4ESZJ+HTsbGNJV7Bbig1vK Dd6C0b/r45GL/wqMwsn2CuIQSFtjK2y9Y54QM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2VKnAMpekgJdh/qUpWgWMGV+rQC469+Yfkep51n3ZB4=; b=JmmB4fq+5b9h7I5SlKVZg4PussBeY30eEkdZo7sJxp7hgOauqVfkoyVjfigjRNYkbh s1ndwCOIoGFtyfTBLQgtpFwlTLLxWrHOULOsd+lbSd7m7ShzoGjyGbE2c5oGCc0oSIK5 ji7hN/42baS4DoJGVWkwhvOE70ZDpPrC1Vngzje9p5uE54yYPpyIO2vai7PWVtuuzua2 +HnD5s+F2ducCKG0HFFF8AiNhSaNBhESsv6LCSrXdcsys/OqbK0kz9pcSbLM+HUpDcmS FnEZS9nT4yc732bUuxKRt+JOHGqr2tBU7qhY2VtJTmwdYTRprv0p/H0Gpzsc1MMGmIPb vFHQ== X-Gm-Message-State: AJaThX7TLcqKr/UyE4YyuqJ51cb9pqbhT64Lpbr7m8QA+G0vm+HZeSxY nHJe60CHl0XDI8Y1v7R4xFdxqs50yeI= X-Received: by 10.28.128.214 with SMTP id b205mr1625903wmd.82.1512041272072; Thu, 30 Nov 2017 03:27:52 -0800 (PST) Received: from [192.168.1.24] (cpc87211-aztw31-2-0-cust196.18-1.cable.virginm.net. [82.46.60.197]) by smtp.gmail.com with ESMTPSA id t138sm6326365wme.16.2017.11.30.03.27.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 03:27:51 -0800 (PST) Subject: Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye. To: Doug Anderson , Enric Balletbo i Serra Cc: Jingoo Han , Richard Purdie , Jacek Anaszewski , Pavel Machek , Rob Herring , Brian Norris , Guenter Roeck , Lee Jones , Alexandru Stan , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, LKML References: <20171116141151.21171-1-enric.balletbo@collabora.com> <20171116141151.21171-3-enric.balletbo@collabora.com> From: Daniel Thompson Message-ID: Date: Thu, 30 Nov 2017 11:27:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/11/17 00:44, Doug Anderson wrote: > Hi, > > On Thu, Nov 16, 2017 at 6:11 AM, Enric Balletbo i Serra > wrote: >> When you want to change the brightness using a PWM signal, one thing you >> need to consider is how human perceive the brightness. Human perceive the >> brightness change non-linearly, we have better sensitivity at low >> luminance than high luminance, so to achieve perceived linear dimming, the >> brightness must be matches to the way our eyes behave. The CIE 1931 >> lightness formula is what actually describes how we perceive light. >> >> This patch adds support to compute the brightness levels based on a static >> table filled with the numbers provided by the CIE 1931 algorithm, for now >> it only supports PWM resolutions up to 65535 (16 bits) with 1024 steps. >> Lower PWM resolutions are implemented using the same curve but with less >> steps, e.g. For a PWM resolution of 256 (8 bits) we have 37 steps. > > Your patch assumes that the input to your formula (luminance, I think) > scales linearly with PWM duty cycle. I don't personally know this, > but has anyone confirmed it's common in reality, or at least is a > close enough approximation of reality? Isn't this the loop we went round for v1? We do know that its not linear, however the graphs from a couple of example devices didn't look too scary and nobody has proposed a better formula. At this point the linear interpolation code in patch 1 allows people with especially alinear devices to express suitable brightness curves. However we also know that many DT authors choose not to create good brightness tables for their devices... and we'd rather they used allowed the kernel to choose a model than to use no model at all. Daniel. Enric: BTW sorry I haven't replied so far. That's mostly because these looked more "real" and that I should pay them close attention (which requires time I haven't had spare to consume yet). >> The calculation of the duty cycle using the CIE 1931 algorithm is enabled by >> default when you do not define the 'brightness-levels' propriety in your >> device tree. > > One note is that you probably still want at least a "min" duty cycle. > I seem to remember some PWM backlights don't work well when the duty > cycle is too low and it would still be nice to be able to use your > table. > > >> Signed-off-by: Enric Balletbo i Serra >> --- >> drivers/video/backlight/pwm_bl.c | 160 +++++++++++++++++++++++++++++++++++---- >> include/linux/pwm_backlight.h | 1 + >> 2 files changed, 147 insertions(+), 14 deletions(-) > > Something I'd like to see in a patch somewhere in this series is a way > to expose the backlight "units" to userspace. As far as I know right > now the backlight exposed to userspace is "unitless", but it would be > nice for userspace to query that the backlight is now linear to human > perception. For old code, it could always expose the unit as > "unknown". > > >> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c >> index 59b1bfb..ea96358 100644 >> --- a/drivers/video/backlight/pwm_bl.c >> +++ b/drivers/video/backlight/pwm_bl.c >> @@ -26,6 +26,112 @@ >> >> #define NSTEPS 256 >> >> +/* >> + * CIE lightness to PWM conversion table. The CIE 1931 lightness formula is what >> + * actually describes how we perceive light: >> + * >> + * Y = (L* / 902.3) if L* ≤ 0.08856 >> + * Y = ((L* + 16) / 116)^3 if L* > 0.08856 >> + * >> + * Where Y is the luminance (output) between 0.0 and 1.0, and L* is the >> + * lightness (input) between 0 and 100. > > Just because I'm stupid and not 100% sure, I think: > > luminance = the amount of light coming out of the screen > lightness = how bright a human perceives the screen to be > > Is that right? If so could you add it to the comments? So "output" > here is the output to the PWM and "input" is the input from userspace > (and thus should be expressed in terms of human perception). > > >> + 0, 7, 14, 21, 28, 35, 43, 50, 57, 64, 71, 78, 85, 92, 99, 106, 114, 121, > > Seems like you could save space (and nicely use the previous patch) by > using the linear interpolation code from the previous patch, since > > 0 + 7 = 7 > + 7 = 14 > + 7 = 21 > + 7 = 28 > + 7 = 35 > > ...and it would likely be OK to keep going and be slight off, so: > > + 7 = 42 > + 7 = 49 > + 7 = 56 > + 7 = 63 > + 7 = 70 > ... > ... > > In other words it seems like you're just providing a default table... > > -Doug > From 1585449762741990596@xxx Thu Nov 30 00:45:18 +0000 2017 X-GM-THRID: 1584241125376833263 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread